Starting picoprobe debugging with VSCode not working

[mdrobot7]

OS: Windows 11 Pro 22H2 Installer version: 1.5.1 Picoprobe version: picoprobe-cmsis-v1.0.2 (used picoprobe.uf2) Both the picoprobe and target device are standard Raspberry Pi Picos.

Debugger profile: Pico Debug (Cortex-Debug) Kit: Pico ARM GCC

I have been using Pico for a while, but I recently did a fresh installation on a new system and used the updated instructions from the getting started guide (which included this installer).

I followed the steps in the getting started guide and the readme that opens after running the installer. Everything builds perfectly and the environment seems to be set up correctly.

I then followed the instructions for setting up Picoprobe from the getting started guide (Appendix A). I did a fresh installation of OpenOCD, gdb, and updated all of the MSYS packages. I also used the latest picoprobe prebuilt .uf2 from their repo. Everything installed cleanly, no issues. The picoprobe is picked up in device manager as "Picoprobe CMSIS-DAP v2". I'm using the installer's VSCode config files and the latest version of pico_sdk_import.cmake.

When I try to start the debugger in VSCode, it errors out. Console outputs are below. However, when I run OpenOCD and gdb from the command line, it seems to connect properly (I can't do any extensive testing since I don't know the command line versions at all). The program pointers are picked up for both cores, they are both initialized, and everything appears connected according to the OpenOCD output.

Any help?

VSCode Debugger Outputs:

Build Output:

[main] Building folder: pico-pwm-audio all
[build] Starting build
[proc] Executing command: "C:\Users\Michael\DATA\Projects\Raspberry Pi\Pico SDK v1.5.1\cmake\bin\cmake.EXE" --build c:/Users/Michael/DATA/Projects/pico-pwm-audio/build --config Debug --target all --
[build] ninja: no work to do.
[driver] Build completed: 00:00:00.170
[build] Build finished with exit code 0

Debug Console:

Cortex-Debug: VSCode debugger extension version 1.12.0 git(d7a405a). Usage info: https://github.com/Marus/cortex-debug#usage
Reading symbols from arm-none-eabi-objdump --syms -C -h -w C:/Users/Michael/DATA/Projects/pico-pwm-audio/build/pico-pwm-audio.elf
Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p C:/Users/Michael/DATA/Projects/pico-pwm-audio/build/pico-pwm-audio.elf
Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2
    IMPORTANT: Set "showDevDebugOutput": "raw" in "launch.json" to see verbose GDB transactions here. Very helpful to debug issues or report problems
Launching gdb-server: "C:/Users/Michael/DATA/Projects/openocd/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:\\Users\\Michael\\DATA\\Projects\\pico-pwm-audio" -f "c:/Users/Michael/.vscode/extensions/marus25.cortex-debug-1.12.0/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"
    Please check TERMINAL tab (gdb-server) for output from C:/Users/Michael/DATA/Projects/openocd/openocd.exe
Finished reading symbols from objdump: Time: 86 ms
Failed to launch OpenOCD GDB Server: Error: spawn C:/Users/Michael/DATA/Projects/openocd/openocd.exe ENOENT

Terminal:

[2023-06-17T00:12:40.276Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
"C:/Users/Michael/DATA/Projects/openocd/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:\\Users\\Michael\\DATA\\Projects\\pico-pwm-audio" -f "c:/Users/Michael/.vscode/extensions/marus25.cortex-debug-1.12.0/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"
[2023-06-17T00:12:42.510Z] SERVER CONSOLE DEBUG: GDBServerConsole: onBackendConnect: gdb-server program client error Error: read ECONNRESET
[2023-06-17T00:12:42.514Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

[ndabas]

It looks like you have another openocd.exe somewhere in your PATH or configuration which is being launched instead of the version included with the Pico SDK. The logs say this is the executable: "C:/Users/Michael/DATA/Projects/openocd/openocd.exe".

The pico-env.cmd script that sets up the PATH adds the OpenOCD path to the head of the list so it doesn't get over-ridden by another openocd.exe somewhere else. Do you perhaps have some VS Code configuration that you set up to use your own OpenOCD build?

[mdrobot7]

Yep, I built openocd from source following the setup guide instructions when I originally set up the pico sdk a few years ago. That's the version it's picking up. I didn't realize the setup script cloned and built its own version.

I moved my version of openocd to a different directory, so Powershell shouldn't be able to find it anymore. Running Get-Command openocd in terminal picks up the setup script's version of openocd, and running openocd in terminal gives the standard error output (it's running the setup script's exe). But when I hit F5 to start debugging it tries to launch my version. I checked through the config files in .vscode, nothing looks out of place. How do I force it to use the right path?

I checked PATH btw, my openocd isn't in the User or System path (the script's version is still in the dev environment PATH, checked using ${env:PATH}), so I don't know where it's pulling the path to my version from.

[ndabas]

Maybe the OpenOCD path is set in your VS Code user-level settings.json? The debugging is controlled by the cortex-debug extension which might have saved the path to your custom build.

[mdrobot7]

Yep, I found it in my user settings. Should I remove the user-level path altogether or change it?

[ndabas]

I think removing the user-level path will be a good idea; if you need to use a different OpenOCD build for a specific project, you can set that in your project-level settings.json: https://github.com/Marus/cortex-debug/blob/master/debug_attributes.md.

[mdrobot7]

Just tested it, it works now. Thanks! Maybe, for the future, warn the user during install that there is another build of openocd present on the system, or see if the project debug config can override the user one, if present?

[ndabas]

Great! Yes, we are working on a component which should be able to configure and validate these settings.