Pico debug issue with PICO_CXX_ENABLE_EXCEPTIONS enabled

GuySMowbray commented

2025-09-26 15:03:31 -05:00

(Migrated from github.com)

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

> 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](https://github.com/raspberrypi/pico-sdk/issues/1952#issuecomment-3340205986)_

lurch commented

2025-09-27 10:56:24 -05:00

(Migrated from github.com)

@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 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 commented

2025-09-28 06:33:45 -05:00

(Migrated from github.com)

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.

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 commented

2025-09-29 02:57:50 -05:00

(Migrated from github.com)

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?

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 commented

2025-10-02 19:52:19 -05:00

(Migrated from github.com)

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.

Hello - chiming in here, I have read through the [previous issue where this was discussed](https://github.com/raspberrypi/pico-sdk/issues/1952). 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.

will-v-pi commented

2025-10-07 03:33:01 -05:00

(Migrated from github.com)

@GuySMowbray Here's the clear explanation of the workaround:

When enabling PICO_CXX_ENABLE_EXCEPTIONS debugging doesn't stop at breakpoints correctly
The workaround is to delete your build directory and do a full rebuild before debugging each time

@GuySMowbray Here's the clear explanation of the workaround: - When enabling `PICO_CXX_ENABLE_EXCEPTIONS` debugging doesn't stop at breakpoints correctly - The workaround is to delete your build directory and do a full rebuild before debugging each time

slammers67 commented

2025-11-17 15:25:50 -06:00

(Migrated from github.com)

I have the same issue where I have to delete the build folder, but I do not think it has anything to do with PICO_CXX_ENABLE_EXCEPTIONS.

I think it may be something to do with file caching. The reason I say this is that on the PC where I do not have issue, the debug console shows that after the symbols are read, a line outs that shows the file and location of main

man() at ...\main.cpp::33 as an example

on a PC where I have to delete the build folder, if I don't delete it and make a change and debug, then after the elf file is loaded you get a line saying

.....elf' has changed; re-reading symbols.

and then after this it displays a random .cpp file and some of its contents

0x1000758c in stdio_usb_init () at C:\WorkTemp\RP2040\pico-sdk\src\rp2_common\pico_stdio_usb\stdio_usb.c:228 228 if (rc) {

Its almost like something detects that the elf file is different and then re-reads a different file where all the location data in wrong so it displays incorrect information

And then it can no longer find main , flash never gets loaded, an so on

I have the same issue where I have to delete the build folder, but I do not think it has anything to do with PICO_CXX_ENABLE_EXCEPTIONS. I think it may be something to do with file caching. The reason I say this is that on the PC where I do not have issue, the debug console shows that after the symbols are read, a line outs that shows the file and location of main `man() at ...\main.cpp::33` as an example on a PC where I have to delete the build folder, if I don't delete it and make a change and debug, then after the elf file is loaded you get a line saying `.....elf' has changed; re-reading symbols.` and then after this it displays a random .cpp file and some of its contents `0x1000758c in stdio_usb_init () at C:\WorkTemp\RP2040\pico-sdk\src\rp2_common\pico_stdio_usb\stdio_usb.c:228 228 if (rc) { ` Its almost like something detects that the elf file is different and then re-reads a different file where all the location data in wrong so it displays incorrect information And then it can no longer find main , flash never gets loaded, an so on

GuySMowbray commented

2025-11-19 17:24:04 -06:00

(Migrated from github.com)

sound slightly different to my issue, which although ive been too busy to
dig into it in detail is probably around the debug not correctly
identifying changed files.
adding "overrideLaunchCommands": [
"monitor reset init",
"load "${command:raspberry-pi-pico.launchTargetPath}""
], to launch.json
reduced the issues frequency but doesnt always work, even when i do a clean
rebuild from cmake. I'm begining to suspect the openOCD interface.
My workaround :
I just check to see if the flash upload appears in the log if it does i'll
get a clean debug break at main, if not it just restarts with stale code so
i do the crude work around of deleting the whole build to force the issue.
Ive seen this is causing a lot of pain for some people, i bet there are
many more who just putup with it.

On Mon, 17 Nov 2025, 21:26 Shawn Lammers, @.***> wrote:

slammers67 left a comment (raspberrypi/pico-sdk#2685)
https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-3543904272

I have the same issue where I have to delete the build folder, but I do
not think it has anything to do with PICO_CXX_ENABLE_EXCEPTIONS.

I think it may be something to do with file caching. The reason I say this
is that on the PC where I do not have issue, the debug console shows that
after the symbols are read, a line outs that shows the file and location of
main

man() at ...\main.cpp::33 as an example

on a PC where I have to delete the build folder, if I don't delete it and
make a change and debug, then after the elf file is loaded you get a line
saying

.....elf' has changed; re-reading symbols.

and then after this it displays a random .cpp file and some of its contents

0x1000758c in stdio_usb_init () at
C:\WorkTemp\RP2040\pico-sdk\src\rp2_common\pico_stdio_usb\stdio_usb.c:228
228 if (rc) {

Its almost like something detects that the elf file is different and then
re-reads a different file where all the location data in wrong so it
displays incorrect information

And then it can no longer find main , flash never gets loaded, an so on

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-3543904272,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAUQCCWT3BWMARC7WGEEGYD35I4PJAVCNFSM6AAAAACHT25GX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBTHEYDIMRXGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

sound slightly different to my issue, which although ive been too busy to dig into it in detail is probably around the debug not correctly identifying changed files. adding "overrideLaunchCommands": [ "monitor reset init", "load \"${command:raspberry-pi-pico.launchTargetPath}\"" ], to launch.json reduced the issues frequency but doesnt always work, even when i do a clean rebuild from cmake. I'm begining to suspect the openOCD interface. My workaround : I just check to see if the flash upload appears in the log if it does i'll get a clean debug break at main, if not it just restarts with stale code so i do the crude work around of deleting the whole build to force the issue. Ive seen this is causing a lot of pain for some people, i bet there are many more who just putup with it. On Mon, 17 Nov 2025, 21:26 Shawn Lammers, ***@***.***> wrote: > *slammers67* left a comment (raspberrypi/pico-sdk#2685) > <https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-3543904272> > > I have the same issue where I have to delete the build folder, but I do > not think it has anything to do with PICO_CXX_ENABLE_EXCEPTIONS. > > I think it may be something to do with file caching. The reason I say this > is that on the PC where I do not have issue, the debug console shows that > after the symbols are read, a line outs that shows the file and location of > main > > man() at ...\main.cpp::33 as an example > > on a PC where I have to delete the build folder, if I don't delete it and > make a change and debug, then after the elf file is loaded you get a line > saying > > .....elf' has changed; re-reading symbols. > > and then after this it displays a random .cpp file and some of its contents > > 0x1000758c in stdio_usb_init () at > C:\WorkTemp\RP2040\pico-sdk\src\rp2_common\pico_stdio_usb\stdio_usb.c:228 > 228 if (rc) { > > Its almost like something detects that the elf file is different and then > re-reads a different file where all the location data in wrong so it > displays incorrect information > > And then it can no longer find main , flash never gets loaded, an so on > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-3543904272>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BAUQCCWT3BWMARC7WGEEGYD35I4PJAVCNFSM6AAAAACHT25GX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBTHEYDIMRXGI> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

the-jade-rabbitt commented

2025-12-12 09:27:23 -06:00

(Migrated from github.com)

I'm seeing this problem on my project too.

I'm on a windows 11 laptop using the pi debug probe (connected to a Pico 2040 on a W board).
sdk 2.2.0
Probe CMSIS-DAP: FW Version = 2.0.0 (issue was still happening for me with older probe fw)
Raspberry Pi Pico Visual Studio Code extension Version 0.19.0

The problem still occurs for me with:
set(PICO_CXX_ENABLE_EXCEPTIONS 0)
set(PICO_CXX_ENABLE_RTTI 1)
The only combination that works for me is to have both options turned off.

The one difference in the debug console output is this line appears when it goes wrong:
`c:\Users\me\my-pico-project\build\my-pico-project.elf' has changed; re-reading symbols.

When I pause the debugger after it fails to honor my breakpoints I get the following (bad?) values for rp2040.core0 callstack:
sp=0x20041f00
pc=0x127372c0

The work around (deleting the build folder) works but I'm disabling both of the faulty options until a fix is found.
If I try debugging a stock example project (hello_usb) with both options turned on there's no problems.

My launch script:

"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"
        ]
    },

I'm seeing this problem on my project too. I'm on a windows 11 laptop using the pi debug probe (connected to a Pico 2040 on a W board). sdk 2.2.0 Probe CMSIS-DAP: FW Version = 2.0.0 (issue was still happening for me with older probe fw) Raspberry Pi Pico Visual Studio Code extension Version 0.19.0 The problem still occurs for me with: set(PICO_CXX_ENABLE_EXCEPTIONS 0) set(PICO_CXX_ENABLE_RTTI 1) The only combination that works for me is to have both options turned off. The one difference in the debug console output is this line appears when it goes wrong: `c:\Users\me\my-pico-project\build\my-pico-project.elf' has changed; re-reading symbols. When I pause the debugger after it fails to honor my breakpoints I get the following (bad?) values for rp2040.core0 callstack: sp=0x20041f00 pc=0x127372c0 The work around (deleting the build folder) works but I'm disabling both of the faulty options until a fix is found. If I try debugging a stock example project (hello_usb) with both options turned on there's no problems. My launch script: "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" ] },

kilograham commented

2026-01-05 16:52:44 -06:00

(Migrated from github.com)

is this a VS code only issue; if so probably worth labeling it as such @will-v-pi

Lars31415 commented

2026-01-16 16:05:35 -06:00

(Migrated from github.com)

I have some success up till now using this, even with exceptions enabled
lauch.json

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Pico Debug (rp2350)",
			"type": "cortex-debug",
			"request": "launch",
			"servertype": "openocd",
			"cwd": "${workspaceFolder}",
			"executable": "${command:cmake.launchTargetPath}",
			"device": "RP2350",
			"runToEntryPoint": "main",
			"serverArgs": [
				"-c",
				"adapter speed 5000"
			],
			"openOCDLaunchCommands": [
				"adapter speed 5000"
			],
			"configFiles": [
				"interface/cmsis-dap.cfg",
				"target/rp2350.cfg"
			],
			"svdFile": "${env:PICO_SDK_PATH}/src/rp2350/hardware_regs/rp2350.svd",
			"postLaunchCommands": [
				"interrupt",
				"start",
				"load",
				"starti"
			],
			"postRestartCommands": [
				"break main",
				"continue"
			]
		},
		{
			"name": "Pico Debug (RP2040)",
			"type": "cortex-debug",
			"request": "launch",
			"servertype": "openocd",
			"cwd": "${workspaceFolder}",
			"executable": "${command:cmake.launchTargetPath}",
			"device": "RP2040",
			"serverArgs": [
				"-c",
				"adapter speed 5000"
			],
			"configFiles": [
				"interface/cmsis-dap.cfg",
				"target/rp2040.cfg"
			],
			"svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
			"runToEntryPoint": "main",
			"postLaunchCommands": [
				"interrupt",
				"start",
				"load",
				"starti"
			],
			"postRestartCommands": [
				"break main",
				"continue"
			]
		}
	]
}

I have some success up till now using this, even with exceptions enabled lauch.json ``` { "version": "0.2.0", "configurations": [ { "name": "Pico Debug (rp2350)", "type": "cortex-debug", "request": "launch", "servertype": "openocd", "cwd": "${workspaceFolder}", "executable": "${command:cmake.launchTargetPath}", "device": "RP2350", "runToEntryPoint": "main", "serverArgs": [ "-c", "adapter speed 5000" ], "openOCDLaunchCommands": [ "adapter speed 5000" ], "configFiles": [ "interface/cmsis-dap.cfg", "target/rp2350.cfg" ], "svdFile": "${env:PICO_SDK_PATH}/src/rp2350/hardware_regs/rp2350.svd", "postLaunchCommands": [ "interrupt", "start", "load", "starti" ], "postRestartCommands": [ "break main", "continue" ] }, { "name": "Pico Debug (RP2040)", "type": "cortex-debug", "request": "launch", "servertype": "openocd", "cwd": "${workspaceFolder}", "executable": "${command:cmake.launchTargetPath}", "device": "RP2040", "serverArgs": [ "-c", "adapter speed 5000" ], "configFiles": [ "interface/cmsis-dap.cfg", "target/rp2040.cfg" ], "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd", "runToEntryPoint": "main", "postLaunchCommands": [ "interrupt", "start", "load", "starti" ], "postRestartCommands": [ "break main", "continue" ] } ] } ```

will-v-pi commented

2026-04-01 04:46:03 -05:00

(Migrated from github.com)

I believe I have a fix for this issue - could you try changing your toolchain to 14.3.Rel1 and see if you still see your issue? To do that, click "Pico SDK: 2.2.0" in the bottom right, select "v2.2.0" then "Yes" to configure advanced options, and select the "14.3.Rel1" toolchain (select "Default" for everything else)

GuySMowbray commented

2026-04-17 09:55:33 -05:00

(Migrated from github.com)

Early days, but it does appear to be behaving for me:)

On Wed, 1 Apr 2026 at 10:46, will-v-pi @.***> wrote:

will-v-pi left a comment (raspberrypi/pico-sdk#2685)
https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-4168862598

I believe I have a fix for this issue - could you try changing your
toolchain to 14.3.Rel1 and see if you still see your issue? To do that,
click "Pico SDK: 2.2.0" in the bottom right, select "v2.2.0" then "Yes" to
configure advanced options, and select the "14.3.Rel1" toolchain (select
"Default" for everything else)

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/2685?email_source=notifications&email_token=BAUQCCVMKAWDKITUNSA4CG34TTQPDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJWHA4DMMRVHE4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4168862598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAUQCCTJYOHZQQD6QYV2A434TTQPDAVCNFSM6AAAAACHT25GX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNRYHA3DENJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Early days, but it does appear to be behaving for me:) On Wed, 1 Apr 2026 at 10:46, will-v-pi ***@***.***> wrote: > *will-v-pi* left a comment (raspberrypi/pico-sdk#2685) > <https://github.com/raspberrypi/pico-sdk/issues/2685#issuecomment-4168862598> > > I believe I have a fix for this issue - could you try changing your > toolchain to 14.3.Rel1 and see if you still see your issue? To do that, > click "Pico SDK: 2.2.0" in the bottom right, select "v2.2.0" then "Yes" to > configure advanced options, and select the "14.3.Rel1" toolchain (select > "Default" for everything else) > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/2685?email_source=notifications&email_token=BAUQCCVMKAWDKITUNSA4CG34TTQPDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJWHA4DMMRVHE4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4168862598>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BAUQCCTJYOHZQQD6QYV2A434TTQPDAVCNFSM6AAAAACHT25GX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNRYHA3DENJZHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

will-v-pi commented

2026-04-29 14:11:00 -05:00

(Migrated from github.com)

Great - this should now be fixed for new installs of Pico VSCode, and will be completely fixed with the next SDK version

Rows
Columns

Pico debug issue with PICO_CXX_ENABLE_EXCEPTIONS enabled #2685