I just received my Boron and Xenon modules along with the USB debugger module.
I can’t seem to find any tutorials on how to use this. I’ve downloaded the local IDE but there is nothing in there for using this.
Is there any online help on how to work with the debugger? I’d prefer this for code development instead of OTA flashing etc.
Have you read this tutorial for using the debugger on a photon?
I bet an updated tutorial will be published soon.
Thanks. That is quite a bit different and right now, I can’t find the firmware for this to download locally.
Looks like I need to wait until someone writes up a tutorial so will have to leave the modules on the shelf for now. Hope it won’t be long as I have a neat project for the BLE side of these although I see posts that this is not quite stable and fully implemented.
You can still upload firmware with dfu-util in the meantime.
You can build the firmware locally (IIRC even with Particle Workbench) and that should unblock you.
We’ve been waiting on the tutorials for using the debugger until support is added in Particle Workbench.
It’s way easier to set up in VS Code (Workbench) than it was for Eclipse and the ST-LINK, and there are a few posts on the forums with hints, but support isn’t fully in workbench yet, which is why there aren’t official tutorials yet.
Is there any tutorial for flashing firmware with the debugger yet? I've got a Boron here that I (foolishly) tried to update to rc.26 before setting up in the iOS app that is misbehaving now.
EDIT:
I've started a thread here:
Bit disappointing to wait so long to get the dev kit with the debugger module and find that I can’t yet use it to its full potential. I’ve no interest to do OTA or any other non-debug programming of this. I guess it’s back on the shelf until I can use it fully.
The debugger can be used for programming the bootloader and softdevice using the instructions in the JTAG FAQ.
There aren’t instructions for using the debugger as, well, a debugger, because Particle Workbench (VSCode) doesn’t fully have debugger support yet. Once that has support, you’ll be able to use the debugger easily.
@v8dave: Here is my guide to setting up Visual Studio Code and OpenOCD on Ubuntu Linux to do source code debugging with the Xenon/Argon and Particle debugger. It took a while, but it is now working!
To install OpenOCD on Ubuntu Linux:
sudo apt install openocd
Mine ends up in /usr/bin/openocd and /usr/share/openocd
Download the OpenOCD target file nrf52-var.cfg.
I put mine in /usr/share/openocd/scripts/target/
For your operating system, download Visual Studio Code.
Apply for and download the Particle Workbench, Themes, and Code Snippets extensions (currently 1.0.0-alpha.6) for VS Code Here.
In VS Code, press the Extensions button on the left, go up to the … (More Actions) menu and pick Install from VSIX… and one by one, install your previously downloaded Particle extensions, Workbench last, and follow the prompts. Make sure the Cortex-Debug extension is installed.
In VS Code, set up your Project and customize the YourProgram.code-workspace file to look similar to this:
{
"settings": {
"extensions.ignoreRecommendations": true,
"C_Cpp.default.configurationProvider": "particle.particle-vscode-core",
"particle.targetPlatform": "xenon",
"files.associations": {
"*.ino": "cpp"
},
"particle.firmwareVersion": "0.8.0-rc.27",
"particle.targetDevice": "Xen1Mesh",
"cortex-debug.armToolchainPath":
"/home/ron/.particle/toolchains/gcc-arm/5.3.1/bin/",
"cortex-debug.openocdPath": "/usr/bin/openocd"
},
"folders": [
{
"path": "."
}
]
}
{
"version": "0.1.0",
"configurations": [
{
"name": "Debug (OpenOCD)",
"cwd": "${workspaceRoot}",
"executable": "./target/Xen_BME280_Node.elf",
"interface":"swd",
"request": "attach",
"type": "cortex-debug",
"servertype": "openocd",
"configFiles": [
"interface/cmsis-dap.cfg",
"target/nrf52-var.cfg"
]
}
]
}
If you change "request": to "launch" type, it does not work properly, the Debugging session gets lost and corrupts the Particle Device OS. You will then have to re-flash the Particle Device OS !
Connect your Xenon to a usb port on your computer and place it in DFU mode (RGB LED blinking Yellow) for local flashing.
In VS Code, code your program, press Ctrl-shift-b to bring up the Particle Build commands and pick Particle: Flash application for debug (local). Place a couple of breakpoints in your program for testing.
Connect the Particle (mesh) Debugger cable to the Xenon SWD port and plug in the interface to another usb port. Remember not to use pin D7 (User LED) in your own programs because it will mess up SWD debugging!
In VS Code, press the Debug button on the left then the green arrow above it to start debugging. Your Particle Debugger board should be blinking blue frenetically. This is good! Now look at your source file. The debugger never made it to your breakpoints. Select the Debug Console and see that your program is paused. Now press on the floating Debugger panel Continue (F5) button and wait a long time for it to get to the first breakpoint. You are ready to debug when the breakpoint is highlighted in yellow. You made it!
At the bottom of the Debug Console is a prompt > to enter GDB commands like help and you can talk to the debugger interface with monitor commands like monitor help. This is the same as telnet localhost 4444 from a terminal to talk to the interface through OpenOCD.
Other useful consoles are Output with Adapter Output selected. Also press F1 and select Particle: Serial Monitor to see your program’s usb output on the Terminal.
When done debugging, select Stop Debugging from the Debug menu. Before you can debug another session, you will need to press reset on the Xenon board.
Some Gotchas: You only have 2 breakpoints. If you add more, it will only cycle through the first two! So, when the 2nd breakpoint is hit, remove the first, move it down below the last breakpoint and continue to slinky down as you debug! Even though the breakpoints might be close together in loop(), the debugger will cycle through setup() to get to that 2nd breakpoint! Doesn’t make a lot of sense, but that is the current behavior . . .
If you are having difficulties flashing locally with usb and accessing the usb port, you may have smacked up against the UDEV Wall! You should download 50-particle.rules and then
sudo cp 50-particle.rules /etc/udev/rules.d/
and restart your system.
I hope this info has saved you some time! Happy debugging . . .
Hi CaptIgmu,
Thanks for your debugging guide. Works great!
Regarding the number of breakpoints:
I can add six breakpoints without a problem. As soon as I add the seventh breakpoint I get the following warning:
Could not continue: Warning: Cannot insert hardware breakpoint 7. Could not insert hardware breakpoints: You may have requested too many hardware breakpoints/watchpoints…
I had a quick look at the nrf52840 datasheet:
4.8 Debug and trace
Debug and trace system offers a flexible and powerful mechanism for non-intrusive debugging.
The main features of the debug and trace system are:
• Two-pin serial wire debug (SWD) interface
• Flash patch and breakpoint (FPB) unit supports:
• Two literal comparators
• Six instruction comparators
• Data watchpoint and trace (DWT) unit
• Four comparators
• Instrumentation trace macrocell (ITM)
• Embedded trace macrocell (ETM)
• Trace port interface unit (TPIU)
• 4-bit parallel trace of ITM and ETM trace data
• Serial wire output (SWO) trace of ITM data
It looks like nrf52840 has only six hardware breakpoints (Six instruction comparators).
Excellent. I’ll have a go at this at the weekend and post if I have any issues. If this all works, we should post this information somewhere on the Particle website as I am sure others would benefit from it too.
Thanks for the guide Captlgmu!
I tried running it on Windows but I'm experiencing some problems.
I use the following workspace settings:
{
"settings": {
"extensions.ignoreRecommendations": true,
"C_Cpp.default.configurationProvider": "particle.particle-vscode-core",
"files.associations": {
"*.ino": "cpp",
},
"particle.firmwareVersion": "0.8.0-rc.27",
"particle.targetPlatform": "xenon",
"particle.targetDevice": "Xen1Mesh",
"cortex-debug.armToolchainPath":
"C:/Users/Sebastien/.particle/toolchains/gcc-arm/5.3.1/bin/",
"cortex-debug.openocdPath": "C:/openocd/bin-x64/openocd.exe"
},
"folders": [
{
"path": "."
}
]
}
And launch.json:
{
"version": "0.1.0",
"configurations": [
{
"name": "Debug (OpenOCD)",
"cwd": "${workspaceRoot}",
"executable": "./target/inose-iot-photon.elf",
"interface": "swd",
"request": "attach",
"type": "cortex-debug",
"servertype": "openocd",
"configFiles": [
"scripts/interface/cmsis-dap.cfg",
"scripts/target/nrf52-var.cfg"
]
}
]
}
But whenever I start the debug I get the following error after a few seconds:
Failed to launch OpenOCD GDB Server: Timeout.
If I run the following command from a prompt:
openocd.exe -f interface/cmsis-dap.cfg -f C:/openocd/bin-x64/scripts/target/nrf52-var.cfg
It seems to run fine:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
Info : auto-selecting first available session transport "swd". To override use 'transport select '.
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
bld_addr
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 : reduce speed request: 10000kHz to 5000kHz maximum
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
The Particle Debugger starts blinking like it should, but it's obviously not linked with the debugging session in my Visual Studio Code so not useful.
Any ideas?
Thanks!
Kind regards,
Sebastien
Solved! 
While typing my previous post I noticed that I used different paths in my prompt then in the launch.json. I had to play with the various paths before everything worked in the prompt as well.
When I used exactly the same paths in my launch.json everything worked! So obvious but I completely overlooked it… 
Anyhow, this is the working launch.json:
{
"version": "0.1.0",
"configurations": [
{
"name": "Debug (OpenOCD)",
"cwd": "${workspaceRoot}",
"executable": "./target/inose-iot-photon.elf",
"interface": "swd",
"request": "attach",
"type": "cortex-debug",
"servertype": "openocd",
"configFiles": [
"interface/cmsis-dap.cfg",
"C:/openocd/bin-x64/scripts/target/nrf52-var.cfg"
]
}
]
}
No idea why the paths have to be that way. I added C:/openocd/bin-x64 to my PATH in Windows but that’s it. Is VS Code using his own paths? And where can I find it?
Sebastien
I’m Still seeing the 'Failed to launch OpenOCD Server: Timeout errors. Here is my Launch,json:
{
"version": "0.1.0",
"configurations": [
{
"name": "Debug (OpenOCD)",
"cwd": "${workspaceRoot}",
"executable": "C:/Users/fenstej/remote_tech/Analog_voltage_measurement/Analog_Voltage_Measurement_Library\\target\\Analog_Voltage_Measurement_Library.elf" ,
"interface": "swd",
"request": "attach",
"type": "cortex-debug",
"servertype": "openocd",
"configFiles": [
"C:/Particle/openocd/bin-x64/scripts/interface/cmsis-dap.cfg",
"C:/Particle/openocd/bin-x64scripts/target/nrf52-var.cfg"
],
},
]
}
And my config:
{
"settings": {
"extensions.ignoreRecommendations": true,
"C_Cpp.default.configurationProvider": "particle.particle-vscode-core",
"particle.targetPlatform": "argon",
"files.associations": {
"*.ino": "cpp"
},
"particle.firmwareVersion": "0.8.0-rc.27",
"particle.targetDevice": "notDeadyet",
"cortex-debug.armToolchainPath": "C:/Users/fenstej/.particle/toolchains/gcc-arm/5.3.1/bin",
"cortex-debug.openocdPath": "C:/Particle/openocd/bin-x64/openocd.exe"
},
"folders": [
{
"path": "."
},
{
"path": "C:/Users/fenstej/remote_tech/Analog_voltage_measurement/Analog_Voltage_Measurement_Library/src"
},
{
"path": "C:/Users/fenstej/remote_tech/Analog_voltage_measurement/Analog_Voltage_Measurement_Library/src"
}
]
}
I’m running Visual Studio under Winows 7 with OpenOCD 7. When I run OpenOCD stand aloe it works - I get the frenetic LED, but I’m not connected to my project in Visual Studio.
John
You forgot a ‘/’ in the path of the configFiles: C:/Particle/openocd/bin-x64 / scripts/target/nrf52-var.cfg
Maybe that helps?
I’m also not sure if mixing / and \\ in the same path provided as executable is best practice 
Doh! Fixing the path fixed the issue. I’ve also cleaned up the paths, just in case.
Thanks!