5

I am trying to debug a Raspberry Pi Pico with the debug probe and am following the Raspberry Pi Debug Probe tutorial.

When I try and upload my first program to the pico I get the following error.

$ sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program blink.elf verify reset exit" 
Open On-Chip Debugger 0.12.0-g4257276 (2023-01-27-10:19) 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 adapter speed: 5000 kHz Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E32D4229 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 Error: Failed to connect multidrop rp2040.dap0 in procedure 'program' ** OpenOCD init failed ** shutdown command invoked
Improve this question
1
  • I had the same problem - I was expecting the Pico to be powered by the Debug Probe. They are only connected via serial connections though - no power - so we need to connect the Pico to a USB power supply as well (or provide a different external power source) Commented Dec 12, 2023 at 19:42

4 Answers 4

Reset to default
4

Your output indicates that your computer successfully connected to the debugger but not the pico. Check that the Pi Pico is:

  • Powered
  • Is actually connected

I had an issue where the case overhangs the connectors too much and with just my fingers I am able to get the JST connector to appear to be secure however it's not making contact. Removing the debugger from its case and plugging in the JST connector again fixes the problem.

Improve this answer
1
  • Nailed it. Those dinky connectors are very fussy, and even after taking the probe board out I had to apply a lot of force to get them seated. Commented Dec 4, 2024 at 21:42
0

I had the same issue, in my case the Picoprob was the one to blame (the GPIO most likely). The computer could see the Picoprob fine but the pin from the Picoprobe were damaged somehow.

I just dropped the debugger UF2 file into a brand new pico and I manage to debug first try after that.

Improve this answer
0

I experienced a similar issue. In my instance I had incorrectly installed the wrong firmware on the pico from the github repository. The required firmware in my case was debugprobe_on_pico.uf2. All working as per guide after correct firmware installation.

Improve this answer
0

I faced the same issue but I was still able to use openocd after resetting the device in BOOTSEL mode using the dedicated button.

It was related to my development using the watchdog API. It depends on the pause_on_debug parameter of the void watchdog_enable(uint32_t delay_ms, bool pause_on_debug) function

watchdog_enable(100, false); // Cannot use openocd watchdog_enable(100, true); // Openocd working
Improve this answer
2
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. Commented Sep 24 at 18:33
  • @jsotola does it make more sens to you now ? Commented Oct 23 at 14:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.