This is driving me nuts now. I have done clean install of VS Code and particle workbench.
I am attempting to run through the debugging using the Tinker code detailed in the documentation for workbench. Want to move forwards on my own work but blocked by this at the moment.
Anyway, I am running a brand new Argon with a brand new Series 3 debugger. Have connected both ports to usb and connected the argon to the debugger with the supplied cable.
Debugging builds (albeit a little bit slow) and deploys tinker to the Argon and all is well. As soon as i fire the div command with any number > 0 divHandler is hit and the break activates in VSCode all good so far, loving it.
But then the fly, in that ointment, as soon as i step over the command it throws into red panic on the Argon and vs code lists the following, not very useful information:
Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint
1, divHandler (command=…) at /Users/craigperera/Development/Particle_Testing/TinkerBreak//src/TinkerBreak.cpp:53
53 int div = (int) command.toInt();
[
Remote target] #1 stopped.
divHandler (command=…) at /Users/craigperera/Development/Particle_Testing/TinkerBreak//src/TinkerBreak.cpp:53
53 int div = (int) command.toInt();
target not halted
target nrf52.cpu was not halted when step was requested
Wondering if anyone else has encountered this or what i can do to get debugging working. I tried on an also brand new Xenon but got the same.
Any help will be appreciated as a great professional tool, but just need to get over that last hurdle to make progress on my project work
sorry for the bumps i'm not sure what's up - i know it's not super-comforting but fwiw i just walked through the tutorial in the docs and it's working as expected. i'm able to break in the divHandler() fn and step-over all lines without issue. i set a watch for the result variable and see it's value update in the watch panel at the far-left.
I am running a brand new Argon with a brand new Series 3 debugger
by "Series 3 debugger" i assume you mean the new Particle Debugger hardware?
couple things you can try:
clean all the things - run the Particle: Clean application for debug (local) and the Particle: Clean application & DeviceOS (local) tasks (docs)
delete the ./target directory in your project
confirm your project is set to use argon and deviceOS@1.4.0 (see screenshot below)
within the tinker app's setup() fn, add Mesh.off(); as the first line and save
make sure both the Argon and Particle Debugger hw are plugged in via USB (each should have its own connection) w/ the debugger's jtag cable properly connected to the Argon
in the debug configuration drop-down, select Particle Debugger (argon, boron / bsom, xenon) and click the green "start debugging" button
once your device is flashed, you'll see the debug toolbar in the "paused" state - click the blue "continue" button to proceed
try to reproduce your error
here's where you can update your project settings:
I followed your instructions and by jimminy it worked.
I had previously followed the guide to the letter ensuring all the correct options were selected and got the red sos.
As i had it working i decided to try and see what it could be so when i remove Mesh.off() it crashes into red sos, with it Mesh.off() uncommented it works.
So hopefully anyone else hitting this issue will be able to get around it, might be worth adding to the docs for others.
Whelp, that was my problem as well (although I’m using Qt Creator attaching to a remote openocd server so it manifested with a slightly different error message. It’s all GDB, anyhoo…) Thanks for getting the word out!
[ISSUE] Particle: Flash for debug fails and puts device in error state. Also related to Failed to launch OpenOCD GDB. Server: Timeout drops a hint about why this might be. @m_m, is there anything more you could add to describe the issue? I’m developing asynchronous mesh applications and having to choose between serial output debugging with mesh and introspection via hardware debugger is definitely painful! It would be nice if there are certain things we could do (disable/reenable interrupts, for instance?) which could allow for a more robust and predictable debugging experience.
I’m guessing the lengthy pattern of Mesh.off(); BLE.off(); // My code here; BLE.on(); Mesh.on(); will protect from a timing fault, and if that’s the best solution then it is what it is.
i'm not sure what's up - i know it's not super-comforting but fwiw i just walked through the tutorial in the 
