Hi,
I have 2 electrons that died in the field due to low voltage issue, they exhibit the dim D7 with no RGB illumination when plugged in to power.
I’ve tried the fix using a photon to reprogram, to no avail.
Is there a way I can use the Particle debugger that I got for my Mesh devices to reprogram the bootloader?
Fingers crossed…
Thx
J
Yes. You need to connect pins D6, D7, and GND as described in this page. Using the openocd installed by Workbench is usually the easiest. Then use the commands here to program the bootloader:
https://docs.particle.io/support/particle-tools-faq/jtag/#openocd-commands-2nd-generation-
OK, I've been giving this a try, and getting a little further, but am getting stuck.
I have the debugger connected to the Dim blue D7 electron with ground, D6 and D7, and both are connected to my laptop (Mac) by USB.
The directions say to put the device into DFU mode, but of course the the device is unresponsive, and I'm unable to do that.
Is this because I cannot get to DFU mode? I'm very confused about what to try next.
below is what I put into the terminal and the response...
I do the following:
cd ~/.particle/toolchains/openocd/
cd 0.10.0-particle.1then
bin/openocd -f interface/cmsis-dap.cfg -f target/stm32f2x.cfg \
-c "adapter_khz 1000" \
-c "transport select swd" \
-c "init" \
-c "reset halt" \
-c "flash protect 0 0 0 off" \
-c "program /Users/myuser/Downloads/bootloader-1.0.1-electron.bin verify 0x08000000" \
-c "flash protect 0 0 0 on"
-c "exit"
I then get the following response:
Open On-Chip Debugger 0.10.0 (2019-01-29-17:30)
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
-c "adapter_khz 1000" \
-c "transport select swd" \
-c "init" \
-c "reset halt" \
-c "flash protect 0 0 0 off" \
-c "program /Users/jimlivingston/Downloads/bootloader-1.0.1-electron.bin verify 0x08000000" \
-c "flash protect 0 0 0 on" \
-c "exit"
Polling target stm32f2x.cpu failed, trying to reexamine
Error: Could not initialize the debug port
Examination failed, GDB will be halted. Polling again in 100ms
Polling target stm32f2x.cpu failed, trying to reexamine
Error: Could not initialize the debug port
Examination failed, GDB will be halted. Polling again in 300ms
Error: error writing data: (null)
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: (null)
Error: CMSIS-DAP command CMD_CONNECT failed.
Error: error writing data: (null)
Polling target stm32f2x.cpu failed, trying to reexamine
Error: error writing data: (null)
Error: CMSIS-DAP command CMD_DISCONNECT failed.
Error: error writing data: (null)
Error: CMSIS-DAP command CMD_CONNECT failed.
You only need to go into DFU mode if the device can still boot into normal operating mode. If it’s in Dim D7 it should respond to JTAG/SWD.
The debugger isn’t able to communicate with the Electron, but it’s not obvious why from the log. It’s possible that the device is actually not functioning at all, or it could be a configuration issue.
One thing you could do is try with a working Electron. Only include the part of the command up to reset halt so you don’t overwrite anything on it. And for a working Electron you’ll have to put it in DFU mode. But that will at least verify that your debugger configuration is correct.
OK, maybe it's just completely bricked..
I tried it with an electron in DFU mode and with my dim D7 electron, both had the exact same setup except the DFU mode, the results follow:
Working Electron in DFU:
Open On-Chip Debugger 0.10.0 (2019-01-29-17:30)
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
Dim D7 Electron:
Open On-Chip Debugger 0.10.0 (2019-01-29-17:30)
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: stm32f2x.cpu -- clearing lockup after double fault
Polling target stm32f2x.cpu failed, trying to reexamine
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
I guess I two electrons that both are completely bricked. I can’t get them to talk to the Particle Debugger, but I can get another unit in DFU to talk to the debugger with the same physical setup.
I also have two Particle Electrons with dim D7 with no RGB. (Both failed when my power source went out temporarily, and didn’t keep the battery charged.). Am using the Particle debugger and trying to follow the docs. No success.
Has anyone succeed in recovering from a power outage resulting in the dim D7 failure?
Were you ever able to resolve your issue? I’m basically in the same position as you.
No, I never did get that to work. I had the same cause as you did.
I gave the details of one failed unit to particle support and they sent me a new unit.
J
The problem is old but still relevant, so I thought I would write the way I solved the “blue death” on an Electron using “Particle debugger” in Windows10:
C:\Users\<myname>\.particle\toolchains\openocd\0.11.2-adhoc6ea4372.0\bin
openocd -f interface/cmsis-dap.cfg -f target/stm32f2x.cfg -c "adapter_khz 1000" -c "transport select swd" -c "init" -c "reset halt" -c "stm32f2x unlock 0" -c "reset halt" -c "exit"
openocd -f interface/cmsis-dap.cfg -f target/stm32f2x.cfg -c "adapter_khz 1000" -c "transport select swd" -c "init" -c "reset halt" -c "flash protect 0 0 0 off" -c "program /Users/<myname>/Downloads/electron-bootloader_2.2.0_lto.bin verify 0x08000000" -c "flash protect 0 0 0 on" -c "exit"
openocd -f interface/cmsis-dap.cfg -f target/stm32f2x.cfg -c "adapter_khz 1000" -c "transport select swd" -c "init" -c "reset halt" -c "flash protect 0 5 8 off" -c "program /Users/<myname>/Downloads/electron-system-part1_2.2.0.bin verify 0x08060000" -c "program /Users/<myname>/Downloads/electron-system-part2_2.2.0.bin verify 0x08020000" -c "program /Users/<myname>/Downloads/electron-system-part3_2.2.0.bin verify 0x08040000" -c "flash protect 0 5 8 on" -c "exit"
particle flash --usb firmware.bin
openocd -f interface/cmsis-dap.cfg -f target/stm32f2x.cfg -c "adapter_khz 1000" -c "transport select swd" -c "init" -c "reset halt" -c "flash erase_sector 0 1 2"
particle keys doctor <device ID>
Great effort! You’ve just saved another 3!
Notes for others:
Take the \bin off the first and add bin/ to the rest. eg bin/opencd
The bootloader and firmware filenames have changed slightly, worth checking.