Adding Bus Pirate/..-style debugging & probing features to regular MCU boards such as the Raspberry Pi Pico
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5.7 KiB

Dragon Probe

This project attempts to add Bus Pirate/...-like functionality to a number of MCUs, mainly the Raspberry Pi Pico. It was originally based on Dapper Mime, an SWD debugger probe implementation, with the goal of adding JTAG support as well. However, more and more features got added over time.


Most support and development effort goes to the RP2040/Pico, but, due to the projects' structure still being based on Dapper Mime's, it is relatively easy to add support for another MCU/board. Any MCU supported by TinyUSB should work. Features can also be disabled per MCU.

Adding support for another MCU is a matter of adding another subfolder in the ./bsp folder, implementing the functionality (which only concerns itself with sending commands to the hardware, protocol parsing is done by shared code), and handling it in the CMakeFiles.txt file.


After initially downloading this project's code, issue the following command to download TinyUSB and CMSIS 5 code:

git submodule update --init --recursive

Compilation is done using CMake:

mkdir cmake-build && cd cmake-build
cmake -DBOARD=raspberry_pi_pico -DFAMILY=rp2040 -DCMAKE_BUILD_TYPE=RelWithDebInfo ..

BOARD and FAMILY should correspond to those used in the TinyUSB hw folder, and with the folders used in ./bsp as well.

A non-exhaustive list of possible BOARD/FAMILY combinations:

FAMILY BOARD description notes
rp2040 raspberry_pi_pico Raspberry Pi Pico default

Notes on compiling for the RP2040 Pico

If you have the Pico SDK installed on your system, and the PICO_SDK_PATH environment variable is specified properly, you can omit the --recursive flag in the git submodule invocation (to avoid many many git clones), and pass the -DUSE_SYSTEMWIDE_PICOSDK=On flag to CMake, too.

Other options are:

  • -DPICO_NO_FLASH=[On|Off]: store the binary in RAM only, useful for development.
  • -DPICO_COPY_TO_RAM=[On|Off]: write to flash, but always run from RAM
  • -DUSE_USBCDC_FOR_STDIO=[On|Off]: export an extra USB-CDC interface for debugging


For detailed usage notes, please visit the wiki.


The code of this project itself is licensed under the GPL v3.

TinyUSB is licensed under the MIT license.

ARM's CMSIS 5 code is licensed under the Apache 2.0 license.

libco is licensed under the ISC license.

Some code has been incorporated from the DapperMime, picoprobe-sump, JTAGenum, SWDscan and the Raspberry Pico examples projects. These respective licenses can be found in this, this, this, this and this file.


  • A (VID and) PID
  • GPL license headers on every file
  • Debug interface to send printf stuff directly to USB, instead of having to use the UART interface as a loopback thing.
    • Second UART port for when stdio UART is disabled?
  • I2C support by emulating the I2C Tiny USB
    • Expose RP2040-internal temperature ADC on I2C-over-USB bus?
    • Does SMBus stuff need special treatment here? No. Actually, some parts do, but, laziness.
    • 10-bit I2C address support (Needs poking at the Pico SDK, as it only supports 7-bit ones).
  • 1-wire
  • make modes persistent?
  • FT2232 emulation mode?
    • watch out, still need a vnd cfg interface! libftdi expects the following stuff: (TODO: acquire detailed protocol description)
      • interface 0 ("A"): index 1, epin 0x02, epout 0x81
      • interface 1 ("B"): index 2, epin 0x04, epout 0x83
      • interface 2 ("C"): index 3, epin 0x06, epout 0x85
      • interface 3 ("D"): index 4, epin 0x08, epout 0x87
  • "Complex Trigger" mode for aiding with glitching triggers, by turning UART/SPI/I2C/eMMC/... sequences into a GPIO toggle
  • Mode where you can define custom PIO stuff for custom pinouts/protocols??????
    • Maybe also with code that auto-reacts to stuff from the environment?
  • Facedancer implementation by connecting two picos via GPIO, one doing host stuff, the other device, commands being sent over GPIO to do stuff
  • Maybe use the ADCs for something?
  • SD/MMC/SDIO (will be a pain)
  • MSP430 programming
  • AVR programming (USBavr emulation?)
  • PIC programming
  • iCE40 programming??
  • Renesas E7-{0,1,2} programming thing????
  • Maybe steal other features from the Bus Pirate, HydraBus or Glasgow or so
    • 3-wire? Never seen this one in the wild
    • CAN? LIN? MOD? If I'd first be able to find a CAN device to test it with, sure