Debugging against the Pico Board

There are different ways to carry debugging against the Raspberry Pi Pico:

Using the second core of the same Pico,
Using a second Pico board,
Using a Raspberry Pi 4B,
Using a standard programmer-debugger like .

Using the second core of the same Pico

Since the RP2040 features two cores, why not using one core to debug the other? This is the interesting approach to get a first look at debugging.

Alas, I couldn't manage to run the debugger and debug the application at the same time. I may have missed one step in the procedure.

Using a second Pico board

As the Pico goes for USD4, why not using a second Pico as a programmer-debugger?

Called PicoProbe, this solution works very well. The first Pico is turned into a programmer-debugger after flashing an executable available as a UF2 file. Then it is connected to the second Pico, the target. The programmer-debugger also reroutes the serial port from pin 0 and 1 of the target.

The Serial port of the target is no longer Serial on the USB port, by Serial1 on pins 0 and 1.

Using a Raspberry Pi 4B

I haven't tested this solution.

Using a standard programmer-debugger

The standard tools include the openOCD server, the GDB client and a Segger J-Link programmer-debugger.

I faced various issues, but found fixes for all of them:

As a multi-core MCU, the RP2040 requires the SWD multi-drop feature, which is available on Segger J-Link probes starting version 10. My Segger J-Link probe was version 9, so it didn't support it. This was fixed by using a more recent Segger J-Link probe or the Segger J-Link Edu mini.

Similarly, the Arduino port relies on mbed, which is surprisingly not supported by Segger. Using the excellent arduino-pico by Earle F. Philhower, actually based on the RP2040 SDK, brought stability and allowed debugging.
The standard version of OpenOCD doesn't support the RP2040. A special branch on the Raspberry Pi fork of OpenOCD solves the issue.

As an extra benefit, debugging is launched right from Visual Studio Code.