Open Source picoLink: Raspberry Pi RP2040 CMSIS-DAP Debug Probe

One essential part of embedded development is the ability to debug the target application. The good thing with the Raspberry Pi Pico RP2040 Eco-system is: One can use another RP2040 Pico board as a debug probe to debug other ARM Cortex-M devices.

But instead using a Raspberry Pi Pico board with some wires, why not building a dedicated board? The result is a small, versatile and open source debugging probe which virtually can debug any ARM Cortex-M device as a standard ARM CMSIS-DAP probe:

picoLink Debug Probe debugging a Raspberry Pi Pico Board


As I wrote in “Picoprobe: Using the Raspberry Pi Pico as Debug Probe“, it is easy to use one RP2040 board as a debug probe, and this works great e.g. with a SEGGER J-Link EDU which we use a lot in our classes.

PicoProbe Wiring

But this requires some bread-boarding and wiring to make a standard debug connector.

All the needed design files are available on GitHub.

PicoProbe PCB Kits

The logical next step is to use a PCB in combination with the Raspberry Pi Pico board, for example the one from Pimoroni which features a standard ARM debug connector, but no target UART option.

PiMoroni PCB Kit (Source:

Another one is the tiny-picoprobe: This one includes a target UART plus the ability to provide power to the target:

tiny-picoprobe (Source:

Raspberry Pi Debug Probe

I was really excited when I saw that the Raspberry Pi foundation started to provide a dedicated debug probe based on the RP2040:

‘Official’ Raspberry Pi Debug Probe (Source: Raspberry Pi Foundation)

I have not been able to get one of those (yet), but it was not what I had expected:

  • It uses different pins according to the schematics information, so the current PicoProbe firmware won’t be compatible.
  • Instead of the standard ARM 2×10 pin SWD/JTAG connector, it uses the ‘Raspberry Pi’ ‘non-standard’ 3-pin cable connector.
  • It uses micro-USB instead of USB-C. Rather minor, but USB-C cables are getting more and more common.

The ‘official’ probe comes with a nice enclosure, is small and beautiful, plus has buffers on the UART pins, and costs around $15. I think that price point is appropriate for a debug probe.

Yet another Pico Probe Hardware: picoLink

Well, with this I ended up giving ‘yet another’ probe a chance, with the following features:

  • Small, around the size of the Pico board itself
  • Works with the ‘standard’ PicoProbe firmware
  • Standard ARM SWD 10 pin debug header to debug any standard boards
  • 3-pin Raspberry Pi debug header to debug Pico and Pico-W boards
  • UART connection (VCOM)
  • USB-C connector for power and debug the target
  • USB-C to debug the RP2040 on the PicoLink (ability to debug the probe firmware itself)
picoLink Board

I decided against the function to power the target with 3.3V or 5V: while this sounds nice, it easily can damage the host (without some protection circuit) or damage the target if powering a 3.3V one with 5V. And it would have increased the PCB size and BOM. The BOM costs of the picoLink (see link to GitHub at the end of the article) is ~$5.00 (single quantity, add ~$2 for cables), so around the costs of a Raspberry Pi Pico RP2040 board, but about half of the price for the Raspberry Pi Debug probe

Debugging the picoLink over USB-C Connector

What I really wanted to have on the picoLink board is the ability to debug the RP2040 on it running the debug firmware too. This allows students to develop their own debug firmware. One logical solution would have been to add a debug header on the picoLink itself.

: below I have a SEGGER J-Link EDU debugging the PicoProbe firmware on the PicoLink which is debugging the Pico board I have used in RP2040 with PIO and DMA to address WS2812B LEDs:

Debugging the PicoLink

💡 Instead using the J-Link EDU Mini, I could have used another picoLink. But as currently I have only one board, I used a J-Link instead.

This means that I don’t need a debug header on the probe itself to debug it if I need it :-).

The USB-C adapter board manages the USB cable and signals, which then get routed through the USB connector to the picoLink board:

picoLink Schematics

Target Debug Headers

The board has two debug connectors: the standard 10pin one plus a 3-pin one:

Target Debug Headers

J5 is an extra debug header, useful to connect to a Pico or Pico-W board having the 3-pin debug interface:

Power Supply, Target UART

Finally, the 3.3V supply from the 5V USB for the probe plus the target UART connection:

Power Supply and Target UART

The target UART connection provides a VCOM, useful to connect to the UART of another board, here shown using it as a ‘UART-2-USB CDC’ converter with a Raspberry Pi 4:


The final PCB has a size of 53.3×25.8 mm which is about the size of the Pico board itself (51.3x21mm).

picoLink Layout

Below a rendering of the PCB:

picoLink Rendering

And here the first populated board:

picoLink Board


To protect the hardware and have it ‘nice-looking’, a laser-cut PMMA enclosure has been designed in Inkscape:

picoLink Laser files

Below how it looks:

picoLink Enclosure (PMMA)

OpenOCD and Firmware

The debug probe does not only allow debugging the RP2040, but any device supported by OpenOCD.

The probe works with the special RP2040 OpenOCD as outlined in “Picoprobe: Using the Raspberry Pi Pico as Debug Probe” and the PicoProbe firmware: You will need the PicoProbe CMSIS V1.0.1 firmware, because the new ‘official’ Picoprobe uses different pins :-(.


Instead of the ‘normal’ PicoProbe firmware,I highly recommend the yapicoprope (‘Yet Another Picoprobe’) which is a fork of the ‘official’ pico probe github.

The firmware is actively developed and comes with tons of really cool features, including support for RTT, CMSIS-DAPv2 with WinUSB, extra CDC logging channel, level shifter support, MSD programming (copy/drag&drop a firmware file to the probe, and it will program the target device), even includes a sigrok probe/logic-analyzer interface, extra status LEDs and more. Plus it is faster (at least as fast as the original PicoProbe). I’m successfully using the rg-1.12 (yapicoprobe-0112-pico-3590ff9.uf2) release with OpenOCD v0.12.

OpenOCD v0.12

I recommend using the newer OpenOCD V0.12 provided by Liviu Ionescu here: And don’t worry: you don’t have to use ‘yet another package manager’: you can simply download the zip file and unpack it. Below are some settings to use OpenOCD v0.12.

Settings for RP2040:

-f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "$_TARGETNAME_0 configure -rtos FreeRTOS" -c "adapter speed 5000"

Or for debugging a NXP Kinetis K22FN512:

-f interface/cmsis-dap.cfg -f target/kx.cfg -c "$_TARGETNAME configure -rtos FreeRTOS"
OpenOCD Settings to debug K22FN512

With this I have full FreeRTOS debugging capabilities in that IDE:

Debugging with OpenOCD and Eclipse

Below the picoLink debugging the NXP FRDM-K22F board:

picoLink debugging FRDM-K22F board


The new probe works fine so far, and I’m going to produce more to cover the needs for the labs and ongoing projects. It is supported by the ‘yapicoprobe’ firmware too, and maybe I should consider a new version with all the extra features (LEDs, level shifter, sigrok), but for the moment: all what I need is an inexpensive and powerful open source probe for all the new and upcoming RP2040 projects. The BOM costs are around the normal Pico board, so apart of being a dedicated board and having USB-C, there is not that much of an advantage. But it can be easily extended in a next revision to support more features of the ‘yapicoprobe’, and that will be certainly a plus. It will not replace the J-Links I have in use, but with the challenging availability of J-Link EDU Mini and J-Link EDU on the market it is always good to have choices.

I think these new debug probes based on the RP2040 could be very successful in the market: they are inexpensive, the RP2040 and the RP2040 pico boards are available, and OpenOCD is (slowly) evolving. And a debug firmware like the yapicoprobe is adding useful features, and there are plenty of choices. I will still using commercial or vendor specific debug probes, as they have unique features and benefits. But for a classroom environment, education or hobby projects, an open source CMSIS-DAP debug probe certainly makes sense too.

If you are looking for an inexpensive debug probe, have a look at the MCU-Link which is priced around $13 which works with OpenOCD too.

So what do you think? What kind of debug probe based on the RP2040 do you prefer?

Happy Linking 🙂

And in case you don’t want to use a hardware debug probe: there is a really cool idea to use the second core on the RP2040 for debugging the first core. Of course with limitations, but still a very slick idea.



7 thoughts on “Open Source picoLink: Raspberry Pi RP2040 CMSIS-DAP Debug Probe

  1. A long time ago, I bought a ‘Black Magic Probe’.. however could never get swd to work with Cortex-M devices from other vendors (ex. Smartfusion2’s Cortex-M3, Microchip Cortex-M7 SAME70).

    In general, what needs to be modified in order for the picoprobe to debug non-pico devices. For example, is it just a matter of configuring the command-line parameters so that to openocd points to the desired device file (svd/cfg files).. or something more involved like modifying the picoprobe firmware changes and/or rebuilding openocd?

    And if the chip also has ITM’s SWO/TDO (for serial-wire-viewing) can pi-debug-probe + Eclipse/OpenOCD show this trace data? I would think a custom plugin would be needed in Eclipse, no?


    • Hi Ben,
      I had very similar results with the Black Magic Debug probe (see I think I still might have it around somewhere, but stopped using it about 3 years ago. It only worked with a very few and limited set of targets. Not sure what the state these days would be.
      As for using devices with OpenOCD: yes, it is pretty much a thing of having the correct configuration script for a given device and board. OpenOCD itself needs to have some knowledge too about the probe and the features used by the device, that’s why OpenOCD sometimes needs a specific build or feature set, which does not make it easy to use. Things are getting better with the evolution of CMSIS-DAP protocol, as it defines a standard set of commands between the host and the probe, making things hopefully easier in the future, to avoid that ‘device and board script hell’ in OpenOCD. On the plus side, if you build OpenOCD from the sources, the script approach is really flexible.
      As for OpenOCD and the PicoProbe firmware (or similar ones): with OpenOCD v0.12 and the CMSIS-DAP this can work out of the box, if you have a script file for your board/device. Things get difficult if the device has special memory areas and memory/flash programming needs, or if you are dealing with special fuses or security settings. Naturally, OpenOCD supports the ‘common’ parts, and with ‘special’ parts you might be out of luck. Here I recommend to stick with a commercial probe and commercial/vendor tools.
      SWO is yet another topic: CMSIS-DAP had added it a while ago, but debug servers and IDEs only started recently supporting it. This is a topic I might write about in a future article, if time permits. Most debug servers provide a SWO channel through a telnet port, which then can be used by a telnet client or if supported in the IDE. So yes, some kind of ‘plugin’ is required, or at least a telnet connection (which for example works with RTT too, see )


  2. Pingback: The open source picoLink: Raspberry Pi RP2040 CMSIS-DAP debug probe #PiDay @McuOnEclipse @Raspberry_Pi « Adafruit Industries – Makers, hackers, artists, designers and engineers!

  3. Hello Erich,
    thanks for mentioning my efforts. Your article is as always very inspiring.
    Question: is there any source where one can buy your probe hardware ready assembled?

    Liked by 1 person

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.