Particle debugger to recover electron?

electron
Tags: #<Tag:0x00007fe21b79ad88>

#1

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


#2

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-


#3

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.1

then

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

http://openocd.org/doc/doxygen/bugs.html

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.


#4

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.


#5

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

http://openocd.org/doc/doxygen/bugs.html

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

http://openocd.org/doc/doxygen/bugs.html

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


#6

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.