Platformio: Debugging doesn't start if no port is specified & zadig still required & debugging doesn't start at all

[LinusHeu]

I suspect this is since 3.5.0 but I can't be sure because I also switched PCs. There are three issues with debugging. I'm putting them into one issue because I think they might be related.

1. IIRC previously, I didn't have to specify a port for the picoprobe, now I have to. If no debug_port is specified debugging fails to start without any error message.

If in platformio.ini, only the debug_tool is defined:

debug_tool = cmsis-dap

1. Click on Start debugging
2. A loading animation appears in the debug window, compilation starts in the terminal
3. Compilation is successful
4. Shortly after, the loading animation stops and nothing happens. No error message anywhere. Debug console is empty. This is the same no matter if I have nothing, only the picoprobe, or picoprobe and Pico connected.

If in platformio.ini debug_port is defined:

debug_tool = cmsis-dap
debug_port = COM3

OpenOCD starts. It doesn't matter what debug_port I define. debug_port = COM3 does the same as debug_port = COM99 or even debug_port = YoThisSeemsLikeABug or debug_port = 😂.

2. Why do I still have to fiddle with Zadig to install the WinUSB driver for the picoprobe?

By default, it's usbser, but with that driver I get the Error: unable to find a matching CMSIS-DAP device error message in the Debug console. The changelog for Picoprobe 1.0.1 claims "Obviates the need to use Zadig to load WinUSB for the debug interface" and I'm using the latest 1.0.3 uf2. With Zadig and WinUSB I get one step further to problem 3.

3. With 1 and 2 worked around, debugging still doesn't start.

It compiles successfully, outputs the following in the debug console, the loading animation in the debug window ends and nothing more happens.

undefinedOpen On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-12-22-20:10)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
2
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605838836C142F
Info : CMSIS-DAP: SWD  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 1000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections

System type: windows_amd64
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/rpipico.html
PLATFORM: Raspberry Pi RP2040 (1.9.0+sha.f222d26) > Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (blackmagic, cmsis-dap, jlink, pico-debug, picoprobe, raspberrypi-swd)
PACKAGES:
 - framework-arduinopico @ 1.30500.0+sha.3950b94
 - tool-rp2040tools @ 1.0.2
 - toolchain-rp2040-earlephilhower @ 5.120300.230911 (12.3.0)

PlatformIO Core, version 6.1.11

VSCode: Version: 1.82.2 (user setup) Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d Date: 2023-09-14T05:55:25.390Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.22621

Windows 11 22H2

platformio.ini

[env:rpipico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = rpipico
framework = arduino
board_build.core = earlephilhower
build_flags = -Wall -Wextra -Os
debug_build_flags = -Og -ggdb3 -g3
debug_tool = cmsis-dap
debug_port = COM3
monitor_echo = true
monitor_filters = log2file

[maxgerhardt]

If no debug_port is specified debugging fails to start without any error message.

Then it might be possible that I have a bug in the platform-raspberrypi and that somehow the "automatically look for upload port" function is executed and fails. When you disconnect the Pico, do you still have COM ports in the device manager provided by e.g. the motherboard?

It doesn't matter what debug_port I define. debug_port = COM3 does the same as debug_port = COM99 or even debug_port = YoThisSeemsLikeABug or debug_port = 😂.

That's because the upload_port is not passed and evaluated to PlatformIO. Debugging happens with a USB "CMSIS-DAP" device, so there is no "COM" port to talk to, at all.

2. Why do I still have to fiddle with Zadig to install the WinUSB driver for the picoprobe?

With the CMSIS-DAP picoprobe firmware, that should not be needed anymore, but for the old Picoprobe firmware it was. I guess we need to make that clearer in the documentation or throw out the old Picoprobe debug probe possibility completely since it's been clearly obseleted by better, standardized firmware. In my recent testing, I actually had to remove all previous driver software in the Windows device manager to get properly set up.

It compiles successfully, outputs the following in the debug console, the loading animation in the debug window ends and nothing more happens.

Hm that's definitely not supposed to happen and contradicts what I've seen in https://github.com/earlephilhower/arduino-pico/issues/1681#issuecomment-1717984113. However, I think the "crux" is that you specify debug_port: This will be interpreted as the device to connect to via GDB for the debug server. Since somehow OpenOCD gets started on port 3333 and not in pipe mode, this ought to be debug_port = 127.0.0.1:3333

[LinusHeu]

When I have no pico and no picoprobe connected, then I don't see any com port in device manager.

In my recent testing, I actually had to remove all previous driver software in the Windows device manager to get properly set up.

I will try that if the drivers get messed up again. To my surprise, I've restarted my laptop and re-plugged the picoprobe a few times and the drivers are still correct.

I just tried debug_port = 127.0.0.1:3333 and it didn't change anything. Same with debug_port = 3333. However, debug_port = "3333" produces a different error:

undefinedOpen On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-12-22-20:10)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
2
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605838836C142F
Info : CMSIS-DAP: FW Version = 1
Info : CMSIS-DAP: Serial# = 2.0.0
Error: CMSIS-DAP: SWD not supported

[maxgerhardt]

Usually I'd expect either debug_port = 127.0.0.1:3333 or :3333 (but not 3333 on its own) to make PlatformIO connect to a pre-user-opened OpenOCD instance, but that does not seem to be happening here either. This should really just work without any debug_tool.

I'd suggest:

1. Remove the picoprobe device in the Windows device manager with the "delete driver software" checkbox checked, replug the device
2. Upgrade the picoprobe firmware to the latest picoprobe.uf2 in BOOTSEL mode as seen in https://github.com/raspberrypi/picoprobe/releases
3. Use this exact platformio.ini.

   [env:rpipico]
   platform = https://github.com/maxgerhardt/platform-raspberrypi.git
   board = rpipico
   framework = arduino
   board_build.core = earlephilhower
   upload_protocol = cmsis-dap
   debug_tool = cmsis-dap

4. Try debugging again

The critical thing might here the setting of upload_protocol.

[LinusHeu]

debug_port = "" and debug_port = "AnyTextHere" also produces this "CMSIS-DAP: SWD not supported" error.

[LinusHeu]

wait. no. Now, no matter what I write in serial_port = , I get that SWD not supported error. I didn't change anything and didn't even restart VS Code

[LinusHeu]

Just tried that from your latest message:

1. Windows installed "usbser" for CMSIS-DAP v2 Interface (Interface 0)
2. Same behaviour as my initial issue. It builds, then the Debug Console is empty and nothing happens.

[maxgerhardt]

Windows installed "usbser" for CMSIS-DAP v2 Interface (Interface 0)

Hm. Not sure why, but I have this in my Zadig. Maybe I misremember it, but after removing the drivers cleanly I seem to have installed WinUSB LibUSB again for Interface 0? Interface 1 is the USB serial.

[earlephilhower]

Open On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-12-22-20:10)

That is your problem, I think. You're not using the right toolchain. OpenOCD is now 0.12...

earle@amd:~/Arduino/hardware/pico/rp2040$ ./system/openocd/bin/openocd --version
Open On-Chip Debugger 0.12.0-g4d87f6dca (2023-09-11-23:12)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

[maxgerhardt]

Ah then my package selection for OpenOCD has a bug, the URL is not used.. But in fact it does work for me even with 0.11.0.

[LinusHeu]

Previously I did:

1. Right-Click the CMSIS-DAP in Device manager -> uninstall device -> check the "try to uninstall driver" checkbox -> uninstall
2. unplug picoprobe
3. Plug picoprobe back in while holding BL button
4. drag and drop the latest picoprobe uf2 onto the bootloader.

Now:

1. did the device manager uninstall again
2. replugged picoprobe => It's now listed in device manager under "libusb win32 devices" and zadig looks exactly like your screenshot. https://github.com/earlephilhower/arduino-pico/issues/1711?notification_referrer_id=NT_kwDOBxLM9bQ3NzM0MjAwNTc4OjExODY3MjYyOQ#issuecomment-1721906203 I think that one part of the issue might be fixed 🥳 Thank you!

[maxgerhardt]

Removing a conditional per https://github.com/maxgerhardt/platform-raspberrypi/commit/1bd794d0c5217de68e3e6f18b8f75de0d63b00a2 seems to have fixed the installation problem. Everything is still working for me.

Just for completeness sake: Can you remove C:\Users\<user>\.platformio\platforms\raspberrypi again and start debugging again to check if it now uses OpenOCD 0.12 properly for you and everything's still working?

[LinusHeu]

Just for completeness sake: Can you remove C:\Users\.platformio\platforms\raspberrypi again and start debugging again to check if it now uses OpenOCD 0.12 properly for you and everything's still working?

With this pio.ini

[env:rpipico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = rpipico
framework = arduino
board_build.core = earlephilhower
upload_protocol = cmsis-dap
debug_tool = cmsis-dap

It successfully builds, but then the Debug Console is completely empty and nothing happens. Like before.

Adding debug_port = 😂 or any other debug_port = gives this output in Debug Console: No picoprobe connected:

No picoprobe connected

``` undefinedOpen On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-20:49) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 2 Info : Hardware thread awareness created adapter speed: 1000 kHz Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Error: unable to find a matching CMSIS-DAP device ```

Picoprobe connected but no pico connected

``` undefinedOpen On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-20:49) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 2 Info : Hardware thread awareness created adapter speed: 1000 kHz Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605838836C142F 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 1000 kHz Error: Failed to connect multidrop rp2040.dap0 ```

Both Pico and Picoprobe connected

``` undefinedOpen On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-20:49) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 2 Info : Hardware thread awareness created adapter speed: 1000 kHz Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605838836C142F 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 1000 kHz Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001 Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 3333 Info : Listening on port 3333 for gdb connections ```

so pretty much the same behavior as before.

Maybe off-topic: But why was the download so fast? I remember it previously taking like 15 minutes and now it was done in a few seconds. :D

[LinusHeu]

just clicking upload (with upload_protocol = cmsis-dap) does work. Debugging still doesn't start

[maxgerhardt]

Strange that I cannot reproduce that behavior where it's not workign until something is given for debug_port. If it is the non-existance of a COM port at the time of upload (which still makes no sense since the Picoprobe should provide a COM port), I'll have to test that in a virtual Windows 11 machine. I'm testing this on Windows 10.

[LinusHeu]

I can't make any sense of this. :/ And the thing is, it looks to me like the CMSIS-DAP (Interface 0) of the Picoprobe doesn't have a COM port. The COM7 is only for the CDC-ACM UART (Interface 1)

More detailed windows specs: Edition Windows 11 Pro Version 22H2 Installiert am ‎06.‎10.‎2022 Betriebssystembuild 22621.2283 Leistung Windows Feature Experience Pack 1000.22662.1000.0

Thank you for looking into this and all your work for this

[maxgerhardt]

If no debug_port is specified debugging fails to start without any error message.

I have downloaded the official Window 11 eval VM from Microsoft, installed VSCode, Git, PlatformIO in it, forwarded my Picoprobe (with no driver modifications done by Zadig) and I can actually reproduce this. The only COM ports I have is COM3 from the Picoprobe. Starting debugging quickly terminates itself with no message in the debug console. Now onto debug this...

Edit: The addition of another COM port by forwarding another USB device does not do anything.

[maxgerhardt]

Maybe a red hering, but I put tons of prints into the PlatformIO core code and saw it did want to startup GDB but then.. I don't have the libstdc++-6.dll installed, huh? Is that MinGW library or some microsoft visual c/c++ runtime dll...

This is definitely a problem if that isn't static-compiled into the toolchain and we're expecting users to have this.

On my machine I just happen to have this because of other programs:

C:\Users\Max>where libstdc++-6.dll
C:\Program Files\Meld\libstdc++-6.dll
C:\Users\Max\Downloads\winlibs-x86_64-posix-seh-gcc-12.2.0-llvm-15.0.7-mingw-w64ucrt-10.0.0-r4\mingw64\bin\libstdc++-6.dll

Thereafer it also needs libgcc_s_seh-1.dll and libwinpthread-1.dll.

[maxgerhardt]

Hmpf. Even wit Winlibs GCC installed, it does find the binaries, but it just does not startup at all. Just return value -0x3ffffc8c. It really did need those dlls from the Meld program.

I installed Meld, restarted the computer and the problem fixed itself. Debugging does work now for me even after uninstall Meld (but putting the missing DLLs in the directory directly). Can you download + put these DLLs into C:\Users\<user>\.platformio\packages\toolchain-rp2040-earlephilhower\bin, reboot the computer and see if it magically works?

dlls_v2.zip

[LinusHeu]

Can you download + put these DLLs into C:\Users\.platformio\packages\toolchain-rp2040-earlephilhower\bin, reboot the computer and see if it magically works?

Magic confirmed. That makes it work! Thank you so much!

[LinusHeu]

Looks like everything is working like before! 🥳 Just noticed a small thing, not sure if it's relevant or new, but it literally tells me to file a bug report :D

warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report.

full Debug console output

``` Reading symbols from C:\Users\linus\Projekte\RandomTests_Pico\OperatorGleich\.pio\build\rpipico\firmware.elf... Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated. Use 'set mi-async'. PlatformIO Unified Debugger -> https://bit.ly/pio-debug PlatformIO: debug_tool = cmsis-dap PlatformIO: Initializing remote target... Open On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-20:49) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 2 Info : Hardware thread awareness created adapter speed: 1000 kHz Info : tcl server disabled Info : telnet server disabled Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605838836C142F 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 1000 kHz Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001 Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on pipe Info : accepting 'gdb' connection from pipe Info : Found flash device 'win w25q16jv' (ID 0x001540ef) Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors Info : New GDB Connection: 1, Target rp2040.core0, state: halted [rp2040.core0] halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x1000450c msp: 0x20041fa8 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread CoreMutex::CoreMutex (this=this@entry=0x20041fc4, mutex=0x20001b2c <__usb_mutex>, option=option@entry=0 '\000') at C:\Users\linus\.platformio\packages\framework-arduinopico\cores\rp2040\CoreMutex.cpp:31 31 _pxHigherPriorityTaskWoken = 0; // pdFALSE [rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 Loading section .boot2, size 0x100 lma 0x10000000 Loading section .ota, size 0x24e4 lma 0x10000100 Loading section .partition, size 0xa1c lma 0x100025e4 Loading section .text, size 0xd2b0 lma 0x10003000 Loading section .rodata, size 0xa8c lma 0x100102b0 Loading section .data, size 0x16e0 lma 0x10010d3c Info : Padding image section 0 at 0x1001241c with 228 bytes (bank write end alignment) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (3923 ms). Workaround: increase "set remotetimeout" in GDB [rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 Start address 0x100030d4, load size 74780 Transfer rate: 14 KB/sec, 8308 bytes/write. [rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report. Temporary breakpoint 1 at 0x10004294: file C:\Users\linus\.platformio\packages\framework-arduinopico\cores\rp2040\main.cpp, line 78. Note: automatically using hardware breakpoints for read-only addresses. PlatformIO: Initialization completed PlatformIO: Resume the execution to `debug_init_break = tbreak main` PlatformIO: More configuration options -> https://bit.ly/pio-debug [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 Thread 1 "rp2040.core0" hit Temporary breakpoint 1, main () at C:\Users\linus\.platformio\packages\framework-arduinopico\cores\rp2040\main.cpp:78 78 extern "C" int main() {

[maxgerhardt]

Okay then it it was absolute pure luck that I was testing the Windows toolchain download in my Windows installation with all these other programs reinstalled that filled in the missing DLLs with working versions. That's not good for reproducability.

I've opened https://github.com/earlephilhower/pico-quick-toolchain/issues/30 so that we can solve this issue at the source.

warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report.

Strangely I noticed this too but it did not seem to have any effect because it still hit the breakpoint in main(), so I chose to close my eyes to this one. Hitting breakpoints in other functions worked fine too.

[earlephilhower]

@maxgerhardt @LinusHeu can you try the new files listed in the update (the old filename + "-v2" in the pico-quick-toolchain repo)? I individually ran them and it seemed OK, but it was on my personal machine and not a clean VM or anything so I might still have a dependency installed locally but missing in the zip.

[earlephilhower]

Note that I did not bump the revision number because this was a hand-edited run. So you will probably need to delete your old toolchain and any cached downloads, and re-download/install from scratch to grab the new file.