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

[bartola-valves]

🔧 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!

[P33M]

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

[bartola-valves]

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?

[P33M]

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

[bartola-valves]

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. 

[P33M]

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?

[bartola-valves]

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

[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

[P33M]

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.

[bartola-valves]

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.

[lurch]

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)

[P33M]

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.

[bartola-valves]

The detailed sequence of events as I recall where these:

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

[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

[P33M]

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.

[bartola-valves]

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?