[ISSUE] Particle: Flash for debug fails and puts device in error state. Also related to Failed to launch OpenOCD GDB. Server: Timeout

Tags: #<Tag:0x00007fe21cbc4278> #<Tag:0x00007fe21cbc4048>


I have my Argon device running OS 1.4.4 attached to the debugger and usb. The debugger is 3de generation I think. I follewed the tutorial https://docs.particle.io/tutorials/developer-tools/workbench/#debugging-3rd-generation-

Particle: Flash for debug should

  • put device in dfu mode
  • flash a compiled version for debug that I already have onto device
  • restart the device
  • make it pussible for me to run the debugger

Instead this results in a success for the first 3 but after that device starts flashing red. Code not compiled for debug runs normal.

After that I have to

  • detach debugger
  • reset the argon with the buttons
  • device is put into dfu. Stuck in this mode evan
  • particle update
  • particle usb dfu argon
  • particle flash --usb argon.bin
  • attach debugger
  • run debug from workbench play button

This outputs another error

e check OUTPUT tab (Adapter Output) for output from /Users/stijnwillems/.particle/toolchains/openocd/0.11.2-adhoc6ea4372.0/bin/openocd
Launching server: "/Users/stijnwillems/.particle/toolchains/openocd/0.11.2-adhoc6ea4372.0/bin/openocd" "-c" "gdb_port 50001" "-s" "/Users/stijnwillems/.particle/toolchains/openocd/0.11.2-adhoc6ea4372.0/share/openocd/scripts" "-f" "interface/cmsis-dap.cfg" "-f" "target/nrf52-particle.cfg"

Afther that i do Particle: Flash application and DeviceOS

Just start it normally and look for serial logging. This is not ideal however.

Any help with this would be appreciated. Thanks


I run into the problem that is described here [ISSUE] Failed to launch OpenOCD GDB Server: Timeout

OpenOCD GDB timeout. But reverting to an olderversion 0.2.3, as suggested in the post, will not work for me.


For the red SoS, debugging mesh on Gen3 can be problematic because of some hard real-time constraints that the debugger interferes with and can cause a fault.


I don’t have personal experience but sounds like that may be part of what you are running into.

[ISSUE] SOS Debugging Tinker on Argon (MacOS). vscode/Particle workbench

Thanks I tried that now and disabled the mesh. However same result unfortunately …


This outputs another error

that’s actually not an error but rather the actual command being sent to openocd - they print it out in RED to… i don’t know, keep us on our toes or something? :sweat_smile::man_facepalming:

OpenOCD GDB timeout

this can happen for a couple of reasons: the compile & flash step (aka the preLaunchTask defined in your .vscode/launch.json file) failed, your device is in a funky state (busy or crashing), openocd failed to close cleanly or something is using the :6666 port.

for port usage, easiest thing to do is manually find and terminate the process - assuming macOS / Linux:

lsof -i :6666 # if the port is taken, you'll get a PID (and other info) back
kill <pid> # terminate the process using :6666

another place to check for error info is in VSCode’s “Output” panel where you’ll see logs like the following - if the target port is busy, you’ll see a note to that effect here:

Open On-Chip Debugger 0.10.0+dev-00920-g6ea43726 (2019-07-09-20:03)
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
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
Info : stm32f2x.cpu: external reset detected
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
target halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x08025d6c psp: 0x2000cf08
Info : device id = 0x200f6411
Info : flash size = 1024 kbytes
Info : flash size = 512 bytes
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08003768 msp: 0x20020000

For the red SoS, debugging mesh on Gen3 can be problematic

yep, this. have you previously configured this device to use mesh networking? it’s a bit of a pain, but you could also try doing a factory reset and clearing mesh credentials:


also, if you haven’t seen it already, we have a workshop dedicated to debugging over here:


couldn’t hurt to walk through that step by step and note where you run into issues.

finally, i see you were having problems compiling - were you able to resolve that? if so, can you share the fix and mark it resolved?


this workshop I glanced at. I followed the tutorials but the workshop is more recent. In this I read that both BLE and MESH are problematic for debugging. I did not know that. I was debugging BLE. It would be helpfull if this is mentionned in tutorials and docs more clear als it does not work at all and resetting is time consuming. Anyway I am glad for the help and can continue debugging now thank you!

For anybody with simular problems try everything that @m_m said and add following code at beginning of startup. Make sure to do factory reset to remove mesh credentials!

// DO factory reset if it was previously configured for mesh. 
 #if defined(DEBUG_BUILD)


The problems compiling are solved. The debugging remains. I assume it is because I cannot, for the moment, determoin if factory reset is done. It gets stuck at a white light that is alwas on. As I understand it it should be flashing. What I did then was is stall a backup with dfu util.

As I assume debugging will work when I remove mesh credentials I will work on that for now. If not I fall back to serial and wait for updated debugger. Thanks help is appreciated!


Not all of my problems where fixed. More detail on solution on issue on github https://github.com/Marus/cortex-debug/issues/216#issuecomment-564938202


sounds like you got it working more or less. i appreciate your patience and diligence with all these bumps. fwiw, i updated the Workbench docs:


manually put in dfu mode with buttons, particle debug command halts otherwise

i’d like to get this working for you if you haven’t resolved the issue but not in this thread. if it happens reliably (try running particle usb dfu <device name / id> directly), please open a new thread with troubleshooting info as described here

thanks for the feedback :pray: