Pico debug issue is still manifesting. Need to fix or clearly explain work around

[GuySMowbray]

This should still be a live issue, debug is a nightmare. Keeps loosing sync and failing to upload new builds to pico. Fed up with having to reset and rebuild to get around this

Originally posted by @GuySMowbray in #1952

[lurch]

@GuySMowbray That issue you've linked to is from over a year ago, and various parts of the software-stack (pico-sdk, openocd, debugprobe, VS Code extension, etc,) have all been updated since then.
Please provide details of exactly what hardware you're using, what OS you're running, what software versions you have installed, what it is you're trying to do, and where exactly it goes wrong. The more detail that you'e able to provide, the easier it'll be for us to try and reproduce your problem. Thanks.

[GuySMowbray]

Pico W with UFT bootloader V3.0
Pi Debug probe
SDK 2.2.0 on VS code
Version: 1.104.2 (user setup)
Commit: e3a5acfb517a443235981655413d566533107e92
Date: 2025-09-24T11:21:37.073Z
Electron: 37.3.1
ElectronBuildId: 12404162
Chromium: 138.0.7204.235
Node.js: 22.18.0
V8: 13.8.258.31-electron.0
OS: Windows_NT x64 10.0.26100

running debug as

 "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug (Cortex-Debug)",
            "cwd": "${userHome}/.pico-sdk/openocd/0.12.0+dev/scripts",
            "executable": "${command:raspberry-pi-pico.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "serverpath": "${userHome}/.pico-sdk/openocd/0.12.0+dev/openocd.exe",
            "gdbPath": "${command:raspberry-pi-pico.getGDBPath}",
            "device": "${command:raspberry-pi-pico.getChipUppercase}",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/${command:raspberry-pi-pico.getTarget}.cfg"
            ],
            "svdFile": "${userHome}/.pico-sdk/sdk/2.2.0/src/${command:raspberry-pi-pico.getChip}/hardware_regs/${command:raspberry-pi-pico.getChipUppercase}.svd",
            "runToEntryPoint": "main",
            // Fix for no_flash binaries, where monitor reset halt doesn't do what is expected
            // Also works fine for flash binaries
            "overrideLaunchCommands": [
                "monitor reset init",
                "load \"${command:raspberry-pi-pico.launchTargetPath}\""
            ],
            "openOCDLaunchCommands": [
                "adapter speed 5000"
            ]
        },

Clean build on Cmake debugs ok, with two error
reset init failed args[i] option value ('CX') in not valid
cannot convert main from CP1252 to utf_32
I believe these are both reported fairly frequently and are not critical.

While debugging, if I stop the debugger, sometimes it does not stop, sometimes it reports stopped but the control panel stays and wont do anything . On occasion it will stick on the spinlock or another timer. Sometimes the code the debugger is running is different to the code I am seeing (sync loss). On most of these occasions, I cannot get the debug to reset and allow a restart without cleaning Cmaker again.

[will-v-pi]

Have you got PICO_CXX_ENABLE_EXCEPTIONS enabled like in that issue? We have been unable to get to the bottom of why that flag makes debugging so flaky, as you can see from that issue. If not then could you provide your full code so we can reproduce the issue.

You mention that from a clean build debugging works fine, which is the current workaround for this - what do you think needs to be more clearly explained about that workaround?

[Beparnas]

Hello - chiming in here, I have read through the previous issue where this was discussed. I am encountering this same bug - I am using a debug probe with a vanilla Pico and have the the set(PICO_CXX_ENABLE_EXCEPTIONS 1) in my cmakelists.txt file. I am using SDK 2.2.0, but it also occurred in SDK 2.1.1. When I try to debug through the VScode extension (VScode is up to date as are extensions, and I'm on Windows), the result is slightly different (my app runs to completion, ignoring all breakpoints) but the enable/disable of exceptions flips behavior. I also found the fix of deleting the build folder and rebuilding everything to fix the issue, but as soon as you need to re-compile, the new upload fails and the issue persists.
launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug (Cortex-Debug)",
            "cwd": "${userHome}/.pico-sdk/openocd/0.12.0+dev/scripts",
            "executable": "${command:raspberry-pi-pico.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "serverpath": "${userHome}/.pico-sdk/openocd/0.12.0+dev/openocd.exe",
            "gdbPath": "${command:raspberry-pi-pico.getGDBPath}",
            "device": "${command:raspberry-pi-pico.getChipUppercase}",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/${command:raspberry-pi-pico.getTarget}.cfg"
            ],
            "svdFile": "${userHome}/.pico-sdk/sdk/2.2.0/src/${command:raspberry-pi-pico.getChip}/hardware_regs/${command:raspberry-pi-pico.getChipUppercase}.svd",
            "runToEntryPoint": "main",
            // Fix for no_flash binaries, where monitor reset halt doesn't do what is expected
            // Also works fine for flash binaries
            "overrideLaunchCommands": [
                "monitor reset halt",
                "load \"${command:raspberry-pi-pico.launchTargetPath}\""
            ],
            "openOCDLaunchCommands": [
                "adapter speed 5000"
            ]
        },

my app is simply this:

#include "pico/stdlib.h"
#include <cstdio>
int main(){
    stdio_init_all();  // Important: initializes USB stdio
    sleep_ms(1000);//wait for gdb
    printf("IO libraries regression testing:start\n");
    printf("IO libraries regression testing:complete!\n");
}

and my cmakelists.txt is this:

# Generated Cmake Pico project file
cmake_minimum_required(VERSION 3.13)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(PICO_CXX_ENABLE_EXCEPTIONS 1)
# Initialise pico_sdk from installed location
# (note this can come from environment, CMake cache etc)
# == DO NOT EDIT THE FOLLOWING LINES for the Raspberry Pi Pico VS Code Extension to work ==
if(WIN32)
    set(USERHOME $ENV{USERPROFILE})
else()
    set(USERHOME $ENV{HOME})
endif()
set(sdkVersion 2.2.0)
set(toolchainVersion 14_2_Rel1)
set(picotoolVersion 2.2.0)
set(picoVscode ${USERHOME}/.pico-sdk/cmake/pico-vscode.cmake)
if (EXISTS ${picoVscode})
    include(${picoVscode})
endif()
# ====================================================================================
set(PICO_BOARD pico CACHE STRING "Board type")
# Pull in Raspberry Pi Pico SDK (must be before project)
include(pico_sdk_import.cmake)
project(io_control_libraries C CXX ASM)
# Initialise the Raspberry Pi Pico SDK
pico_sdk_init()
# Add executable. Default name is the project name, version 0.1
add_executable(myproject  test/test_main.cpp)
# Modify the below lines to enable/disable output over UART/USB
pico_enable_stdio_uart(io_control_libraries 1)
pico_enable_stdio_usb(io_control_libraries 0)
# Add the standard library to the build
target_link_libraries(myproject pico_stdlib)
pico_add_extra_outputs(io_control_libraries)

if helpful, my stacktrace when the debugger does halt looks like this. the event logged

_exit@0x10003c70 (c:\Users\Admin\.pico-sdk\sdk\2.2.0\src\rp2_common\pico_clib_interface\newlib_interface.c:45)
exit@0x10003c86 (c:\Users\Admin\.pico-sdk\sdk\2.2.0\src\rp2_common\pico_clib_interface\newlib_interface.c:162)
platform_entry@0x1000022a (c:\Users\Admin\.pico-sdk\sdk\2.2.0\src\rp2_common\pico_crt0\crt0.S:517) 

my server logs look typical, with two breakpoints I see this:

[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00

but in debug console the output shows us not stopping at breakpoints, only the end:

Thread 
1 "rp2040.core0" received signal SIGTRAP, Trace/breakpoint trap.
_exit (status=0) at C:/Users/Admin/.pico-sdk/sdk/2.2.0/src/rp2_common/pico_clib_interface/newlib_interface.c:45
45	        __breakpoint();

Hope that is helpful! I'll follow this thread and can test things as needed.