We’re scaling up our production of Electron devices and trying to simplify and automate the process as much as possible. JTAG seems to effectively do pretty much everything we need it to once it has established the connection, but to get it to connect I need to put the device into DFU mode, which seems like would be complex to attempt to automate.
In theory my understanding was that JTAG should work outside of DFU mode, assuming the pins were not being used for something else. A factory fresh electron seems to require the DFU mode though.
For those who have automated the flashing process, any tips on going about it with JTAG? I would love to be able to just stick it in a jig and not have any human interaction with it if I can get it there.
It’s possible to use JTAG/SWD in operating mode, but it requires system firmware built with USE_SWD_JTAG=y which is not the case for any production system firmware release. So basically you’d need custom system firmware in order to use SWD not in DFU mode.
Other options include:
You can enter DFU mode by USB serial by connecting at 14400 baud
You can enter DFU by user firmware that calls System.dfu()
Gotcha, thanks for the info. Bummer that it seems to require something physically interactive (though not unreasonable of course). Of course it’s not overly difficult to initiate DFU mode, but it becomes just one more thing to train someone to do.
Maybe if I can get a jig that will also make contact with the electron exposed D- and D+ testpoints I can use those to connect @ 14400 baud. If I do ultimately get something like that I’ll be sure to pass on how it goes.
Also @rickkas7 maybe you would know this:
I know that if I’m downgrading system firmware via DFU I have to flash the parts in reverse order. If I’m flashing via JTAG by writing to flash is that requirement still applicable? If I make a single binary (bootloader + System + Application) do I need to be concerned about the previous firmware version?
Actually, you only have to flash the parts in reverse order when doing OTA or --serial mode.
In DFU and JTAG you can flash them in any order as long as you do all of the parts without booting between them.
However, be careful when flashing the bootloader through all of the parts. You’ll overwrite the entire configuration flash, so the server and device keys will be erased. Make sure your image has the correct server key and address, but has FFs where the device key should be so it will be regenerated at next boot.
Also only do this for brand new devices. If you change the device private key after the device has been claimed it won’t be able to connect to the cloud again unless you do a particle keys doctor.
But yes, you can flash everything as one big image for upgrade or downgrade. That’s how the devices are flashed in the factory.
And it is possible to completely flash a device by USB by taking advantage of the special baud rates. Basically, 14400 to go into DFU then flash system part 1, part 2, part 3, and user firmware. Then 28800 to go into listening mode and flash the bootloader in —serial mode.
At the end of the day, I’m just looking to automate flashing user firmware and my target system firmware version (0.6.4), so assuming I can get jig-based access to the usb pins (and can automate the rest even now) then going in via USB works perfectly well for me. I’m not super concerned about the flashing speed as I run connectivity tests in the same position and those can take a while themselves. Serial access is also clutch so that I can parse out the SIM card ICCID (I need to activate the third party SIM). Primary concern is getting rid of finnicky button pressing (and eventually a human-initiated plugging in of the USB).
Regarding DFU and the order of flashing - I’ve had scenarios where flashing in DFU mode to downgrade the firmware with forward firmware part numbers broke the device until I used device doctor. Maybe it was a fluke - if I see it again I’ll maybe flag it as an issue. I’m not specifying memory addresses in DFU mode and remember seeing that as an option - would that be the issue? I can also use Particle Identify via Serial first to ID the current version and adjust the order if needed but of course I’d love to avoid that if possible.
I am the Head of Hardware for Amper Technologies - here's the elevator pitch blurb on our primary product:
Amper helps manufacturers improve the performance of their operations by tracking each machine's operations in real-time and giving insight to areas of improvement. Our first product is a machine monitoring system that translates realtime electrical current measurements into actionable machine metrics. Using our product, any kind of machine can be monitored without any IT or PLC integration, and the deployment only takes a few minutes. Our goal is to improve manufacturing performance and help build a predictable supply chain by using Amper to connect manufacturers to their customers and vendors, providing better visibility, automation, and traceability.
We have a daisy-chainable data collection box (using a Teensy device) that does A/D on some sensors along with some minor signal processing. We use a CAN Bus with a proprietary protocol to regularly send data to a cellular gateway. The gateway is an Electron-based device that receives, caches, and sends data to our servers as quickly as it can.
We started off with Photons in the gateway with a client that had a good WiFi network a while back, so it was neat to be able to transition (somewhat) easily to a cellular product with the Electron. Because of our need for both relatively realtime transmission and also minimize missing data, I run the Electron with System_Thread(ENABLED) and a handful of threads. It has been an interesting challenge to get that to work reliably (esp. with regards to connectivity stability and OTA updates), but I've been happy with how things are working for now!
Looking forward, excited to move to LTE with the next round of Particle products in the Fall. We send a lot of data and use a 3rd party sim, so the E-Series doesn't fit our application, unfortunately.
I found that "po-util" works wonders by abstracting all the above things for me. No need to futz with the weird serial stuff on linux, and nicely full featured. Once I'm plugged in to the USB I can just run:
po serial open
< parse result of particle identify, activate sim> po serial close po dfu open
< flash firmware> po dfu close
< let it connect>
< claim device, add to product>
< run tests>
So much better than pressing the buttons, even if you aren't automating anything else. Highly recommend!
Thanks for using po-util. I'm glad it has improved your workflow. If you need help with po-util or have a feature suggestion feel free to reach out to me. Is it okay if I quote you?
Fine by me! There’s some contextual info missing in the sentences by themselves - feel free to PM me with a slight edit if you find that necessary and I can give it my blessing haha.
What happens if you have broken the bootloader so that it can no longer go into DFU mode? I thought these devices where programmed out of the factory by a JTAG means to initially load the bootloader and hence the DFU capability?
If the bootloader is broken, the system firmware won’t get started which would (if it was) repurpose the JTAG pins, but since it isn’t the JTAG pins should stay in JTAG mode which will allow a JTAG flash.
DFU Mode isn’t required for JTAG mode, it’s just one way to make sure the JTAG pins won’t get repurposed by the system.
FYI, I finally found away to initiate JTAG/SWD without having to interact with USB. As mentioned in other posts, the system firmware is the thing that locks down JTAG. However, it’s possible to put the device into JTAG accessible mode while holding the RST pin low for <1s during the start of the JTAG process. The specific procedure is as follows:
The device will stay in JTAG accessible mode for future commands unless there is an error in your command or you add -c "resume" before you exit.
Example output with a J-Link that flashes user firmware over SWD and then lets the device run:
Justices-MBP-2:0.10.0-particle.1 justicereed$ openocd -f interface/jlink.cfg -f target/stm32f2x.cfg -c "init" -c "program ./firmware.bin verify 0x80A0000" -c "resume" -c "exit"
Open On-Chip Debugger 0.10.0+dev-00925-g08195413 (2019-09-05-17:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Info : J-Link EDU Mini V1 compiled Jul 24 2017 17:07:14
Info : Hardware version: 1.00
Info : VTarget = 3.266 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : stm32f2x.cpu: external reset detected
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08003700 msp: 0x20020000
** Programming Started **
Info : device id = 0x200f6411
Info : flash size = 1024 kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
