openocd OpenOCD Fails to Connect to RP2040 via CMSIS-DAP Debug Probe

trafficstars

🔧 Setup Summary

Target: Raspberry Pi Pico (brand-new unit, tested multiple)
Probe: Raspberry Pi Debug Probe (CMSIS-DAP firmware v2.0.0)
Host OS: Windows 10/11 (tried on multiple machines)
OpenOCD Version: 0.12.0+dev-gebec950-dirty (bundled via Pico SDK in Visual Studio Code)
Invocation Command:

openocd -s C:\Users\amogl.pico-sdk\openocd\0.12.0+dev\scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 1000; init; shutdown"

The output error of executing the "Flash Project (SWD)" command of the Rasberry Pi Pico extension in Visual Studio Code is:

 *  Executing task: C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/openocd.exe -s C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c adapter speed 5000; program "c:/Users/amogl/OneDrive/Stash Win/Pico/code/Eurorack/NyX/NyX/build/NyX.elf" verify reset exit 

Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6647C740388492F
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Error: Failed to connect multidrop rp2040.dap0
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked


 *  The terminal process "C:\Users\amogl\.pico-sdk\openocd\0.12.0+dev\openocd.exe '-s', 'C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/scripts', '-f', 'interface/cmsis-dap.cfg', '-f', 'target/rp2040.cfg', '-c', 'adapter speed 5000; program "c:/Users/amogl/OneDrive/Stash Win/Pico/code/Eurorack/NyX/NyX/build/NyX.elf" verify reset exit'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

I’ve changed every single hardware variable:

New Pico boards (factory fresh)
Fresh Debug Probe (new out of box)
New JST-SH cables - what comes on the Debug Probe.
Different Windows machines Yet the error remains identical across all setups.

✅ Debugging and Sanity Checks

Bootsel mode confirmed on target (to avoid firmware interference)
Target successfully runs blink.uf2 (GPIO confirmed functional)
Debug Probe firmware is up-to-date (v2.0.0)
OpenOCD launched manually from CLI with correct script path
Lowered adapter speed to 100 kHz
Confirmed matching ground plane and USB power sourcing
Pico’s RUN pin toggled for reset-to-SWD access

🤔 Hypotheses

SWD multidrop support introduced in OpenOCD 0.12.0 may interfere with single-target RP2040
CMSIS-DAP handshake timing mismatch or USB HID driver conflict
Debug Probe firmware may be incompatible with latest OpenOCD version
Potential change in VSC Cortex-Debug extension or Pico SDK integration

🙏 Request

Would love insight from maintainers and community on:

Known issues with rp2040.dap0 connection failures
Ways to disable SWD multidrop and force single-target handshake
Recommended OpenOCD version or commit for Debug Probe compatibility
Any debugging flags that can provide deeper trace of DAP protocol traffic

Thanks in advance!

Jul 09 '25 16:07 bartola-valves

The latest version of the debugprobe firmware is not v2.0.0. Please ensure you are using the v2.2.3 release.

Jul 09 '25 16:07 P33M

The latest version of the debugprobe firmware is not v2.0.0. Please ensure you are using the v2.2.3 release.

It's the commercial debugprobe, how do I update the firmware if it doesn't have a bootsel switch?

Jul 09 '25 17:07 bartola-valves

https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html#updating-the-firmware-on-the-debug-probe

Jul 09 '25 17:07 P33M

Ignore. Downloaded from here and updated the probe: https://github.com/raspberrypi/debugprobe/releases/tag/debugprobe-v2.2.3

The file used is the debugprobe.uf2

However, it still shows 2.0.0, what am I doing wrong?:

 *  Executing task: C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/openocd.exe -s C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c adapter speed 5000; program "c:/Users/amogl/OneDrive/Stash Win/Pico/code/Eurorack/NyX/NyX/build/NyX.elf" verify reset exit 

Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6647C740388492F
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Error: Failed to connect multidrop rp2040.dap0
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked


 *  The terminal process "C:\Users\amogl\.pico-sdk\openocd\0.12.0+dev\openocd.exe '-s', 'C:\Users\amogl/.pico-sdk/openocd/0.12.0+dev/scripts', '-f', 'interface/cmsis-dap.cfg', '-f', 'target/rp2040.cfg', '-c', 'adapter speed 5000; program "c:/Users/amogl/OneDrive/Stash Win/Pico/code/Eurorack/NyX/NyX/build/NyX.elf" verify reset exit'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

Jul 09 '25 17:07 bartola-valves

That's the CMSIS DAP protocol version and not the probe firmware version. Unfortunate that they can collide. The probe version is reported in the bcdDevice field of the USB device descriptor but no matter.

What happens if you invoke rp2040-rescue.cfg and restart openocd afterwards with rp2040.cfg?

Jul 09 '25 17:07 P33M

Well, it seems there is no rescue config on the version bundled in VSC:

PS C:\Users\amogl\OneDrive\Stash Win\Pico\code\Eurorack\NyX\NyX> openocd -s C:\Users\amogl\.pico-sdk\openocd\0.12.0+dev\scripts -f interface/cmsis-dap.cfg -f target/rp2040-rescue.cfg
Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:28: Error: Can't find target/rp2040-rescue.cfg
in procedure 'script' 
at file "embedded:startup.tcl", line 28
PS C:\Users\amogl\OneDrive\Stash Win\Pico\code\Eurorack\NyX\NyX> openocd -s C:\Users\amogl\.pico-sdk\openocd\0.12.0+dev\scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg
Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at very low speed (100 kHz).
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6647C740388492F
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 100 kHz
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Error: Failed to connect multidrop rp2040.dap0

Jul 09 '25 17:07 bartola-valves

That's the CMSIS DAP protocol version and not the probe firmware version. Unfortunate that they can collide. The probe version is reported in the bcdDevice field of the USB device descriptor but no matter.

What happens if you invoke rp2040-rescue.cfg and restart openocd afterwards with rp2040.cfg?

I tried the rp2350-rescue instead as it is missing:

PS C:\Users\amogl\OneDrive\Stash Win\Pico\code\Eurorack\NyX\NyX> openocd -s C:\Users\amogl\.pico-sdk\openocd\0.12.0+dev\scripts -f interface/cmsis-dap.cfg -f target/rp2350-rescue.cfg
Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at very low speed (100 kHz).
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6647C740388492F
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 100 kHz
Error: Error connecting DP: cannot read IDR

Jul 09 '25 17:07 bartola-valves

I've replicated your setup with a Pico (in bootsel mode), Debugprobe and VScode but don't see your issue. However, I've spotted that the openocd build shipped with the extension is way out of date.

Jul 10 '25 10:07 P33M

Thank you. It was working before up until a few days ago and not sure what has changed as the extension wasn't updated recently. How can I replicate this to find where the issue is? Apologies I'm not an experienced in SW as you are, so hopefully am able to follow your instructions :) Thanks for the help.

Jul 10 '25 10:07 bartola-valves

However, I've spotted that the openocd build shipped with the extension is way out of date.

ping @will-v-pi (for when you'e feeling better)

Jul 10 '25 10:07 lurch

If it was previously working, and is no longer working, and you're sure the software environment hasn't changed, then hardware damage is more likely.

Check the pins inside the JST connector on the Debugprobe for damage or distortion, and swap the cable (if possible). Check that the Pico still enumerates as a USB drive in Bootsel mode.

Jul 10 '25 13:07 P33M

The detailed sequence of events as I recall where these:

I have been programming with SWD without a problem several raspberry pico powered externally via SWD.
Tried my own developed board and may have damaged the GPIO ports of the debugger. I ditched this one.
Bought a new debugger, Tried building my own debuggers with a Pico but started having this issue
Tried programming a Pico2, different brand new Picos without success
Tried on both Windows machines - same configuration VSC with Raspberry Pico extension. Same OpenOCD version
Bought 2 new programmers

Now, cables are new. Solder 2 different set of SWD pins on 2 new picos. Both picos can be programmed perfectly via USB - bootsel. Both picos provide +5V and +3v3 voltages when powered via USB. I could see SWD CLK on the target PICO with my scope. I don't think this is a hardware issue.

Is there a test we can carry out here?

Jul 10 '25 14:07 bartola-valves

I've replicated your setup with a Pico (in bootsel mode), Debugprobe and VScode but don't see your issue. However, I've spotted that the openocd build shipped with the extension is way out of date.

@P33M why did you say this? Is this not the latest version?

PS C:\Users\amogl> openocd --version
Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

Jul 12 '25 13:07 bartola-valves

It isn't, but it's immaterial - the error is the same in both cases. I can replicate the errors with a disconnected SWDIO line. You will also get this behaviour if the pad input is stuck-high or the SWDIO/SWCLK pad output drive is broken. As you have a scope, with SWDIO disconnected can you check:

swclk
swdio driven from the debug host
swdio driven from the debug target

It shouldn't be necessary to do protocol decode - you should see clean edge transitions on both SWDIO pins.

Jul 14 '25 10:07 P33M

Quick "Flash Project (SWD)" from a Mac (yes I installed VSC and same results yesterday). Using AD2 logic analyser connected in between SDWIO and SWDCLK. I can see the CLK but SWDIO is always high. I'm using a programmed debugger on a Pico 1 and taking GPIO3 and GPIO4 outputs. Easier this way as can use different cables and ensure there is no issue with them as the Pico debugger has a special connector.

S → AP → RD → A:3 DRW → Y:ERROR → P:1!

Is this an expected error message or is it the result of the SDWIO line being high all the time for a specific issue?

Jul 14 '25 11:07 bartola-valves

Are you using the debugprobe_on_pico.uf2 from https://github.com/raspberrypi/debugprobe/releases/tag/debugprobe-v2.2.3 ? Note that the default swd GPIO assignments on Pico are GPIO2 swclk and GPIO3 swdio and shown pictorially in https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf figure 9.

Even so, the swdio pin that's captured on DIO0 looks a bit glitchy, but without the corresponding clock I can't draw any conclusions.

Jul 15 '25 13:07 P33M

@P33M yes, I'm using the debug_on_pico. And sorry, yes the GPIO2 and GPIO3 are the outputs taken. It's anyoing as the target PICO can be programmed perfectly via USB so it's working.

Do you have a sample waveform of the SWD signals so I can see what I should expect to capture? I will then retake a new snapshot with the logic analyser. BTW: I installed freshly VSC on Ubuntu. Same results :(

Jul 15 '25 16:07 bartola-valves

Example trace of openocd when idle. Pico debugging a Pico 2. Adapter speed is 200kHz due to the lackluster performance of this Saleae Logic 4, but works fine at 1MHz as well.

Jul 16 '25 12:07 P33M

Apologies, I have not been able to take again the measurements with a working pico. I need to create a Y connection to plug in the logic analyser using SWD. I will do in a few weeks when back home.

I noticed there has been an update to the Pico extension updating OpenOCD. Unfortunately despite my initial excitement the results are still the same: here is another test in VSC running on Ubuntu:

 *  Executing task: /home/ale/.pico-sdk/openocd/0.12.0+dev/openocd.exe -s /home/ale/.pico-sdk/openocd/0.12.0+dev/scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c adapter speed 5000; program "/home/ale/Code/Eurorack/Dev/ST7789lib2/build/ST7789lib2.elf" verify reset exit 

Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:25)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6647C740388492F
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Warn : Too long SWD WAIT, issuing DAPABORT
Error: Failed to connect multidrop rp2040.dap0
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked


 *  The terminal process "/home/ale/.pico-sdk/openocd/0.12.0+dev/openocd.exe '-s', '/home/ale/.pico-sdk/openocd/0.12.0+dev/scripts', '-f', 'interface/cmsis-dap.cfg', '-f', 'target/rp2040.cfg', '-c', 'adapter speed 5000; program "/home/ale/Code/Eurorack/Dev/ST7789lib2/build/ST7789lib2.elf" verify reset exit'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 
 *

Aug 04 '25 18:08 bartola-valves

@P33M Apologies this took so long. I've been away and in the meantime I received the PCB needed to do the final test I needed. I design my own version of the PicoDebugger with the slight modification of adding input protection circuitry for the SWD lines and the UART. it worked first time round! Clearly I may have damaged the SWD lines of my debuggers and had no easy way of telling this. I think there is a lesson learned here and would be nice for Raspberry Pi to include these protection diodes as the device is intended to be used in a testing environment.

Also from a OpenOCD perspective, not sure if there is any way to add further verbose output to help diagnosing a failure in the SWD communication?

Attached is the schematic of what I built:

PicoDeb.pdf

Output from the debugger:

 *  Executing task: /home/ale/.pico-sdk/openocd/0.12.0+dev/openocd.exe -s /home/ale/.pico-sdk/openocd/0.12.0+dev/scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c adapter speed 5000; program "/home/ale/Code/Jokertest/build/Jokertest.elf" verify reset exit 

Open On-Chip Debugger 0.12.0+dev-gebec950-dirty (2024-09-27-16:25)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, 
serial=4250304B38353817
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core0] Examination succeed
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Examination succeed
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
[rp2040.core0] halted due to breakpoint, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
** Programming Started **
Warn : Function FUNC_BOOTROM_STATE_RESET not found in RP2xxx ROM. (probably an RP2040 or an RP2350 A0)
Warn : Function FUNC_FLASH_RESET_ADDRESS_TRANS not found in RP2xxx ROM. (probably an RP2040 or an RP2350 A0)
Info : RP2040 Flash Probe: 33554432 bytes @0x10000000, in 8192 sectors

Info : Padding image section 1 at 0x10018884 with 124 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x10018900 .. 0x10018fff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
 *  Terminal will be reused by tasks, press any key to close it. `

Sep 11 '25 10:09 bartola-valves

openocd openocd copied to clipboard

OpenOCD Fails to Connect to RP2040 via CMSIS-DAP Debug Probe

🔧 Setup Summary

openocd
openocd copied to clipboard