Testing The Raspberry Pi Debug Probe

We mentioned the Raspberry Pi Debug Probe when it was launched, a little RP2040-based board that provides both a USB-to-UART and an ARM SWD debug interface. [Jeff Geerling] was lucky enough to snag one, and he’s put it through its paces in a handy blog post.

The first question he poses is: why buy the Pi offering when cheaper boards can be found on AliExpress and the like? It’s easily answered by pointing to the ease of setting up, good documentation and support, as well as the device’s reasonable price compared to other commercial probes. It also answered a personal question here as he hooked it up to a Pico, why it has three jumpers and not the more usual multi-way header we’ve seen on other ARM platforms. We should have looked at a Pico more closely of course, because it matched neatly to the Pi product. On the Pico they’re at the edge, while on the Pico W they’re in the center.

No doubt if the latest addition to the Pi stable has any further revelations we’ll bring them to you. But it’s worth a quick look at this piece to see a real experience with their latest. Meanwhile, take a quick look at our launch coverage.

14 thoughts on “Testing The Raspberry Pi Debug Probe

  1. I always wondered why they didn’t release this alongside the Pi Pico. It’s such an obvious gizmo!

    Yes yes i know, just flash a picoprobe, it takes 2 seconds. but the *aesthetics* aren’t there. I want my debug probe to be visually a debug probe, its own entity. otherwise my adhd kicks in and i get irrationally angry.

  2. I like it that cables are included. Didn’t realize that. Nice touch. As for the micro USB port, I think is a plus. I have lots of those around working with other pi’s and Arduino boards. Not a big deal and the cable is included anyway. So not annoying at all (reference blog) :) . I’ll have to pick up one of these probes. Looks useful. Oh, and … I’ve never bought anything from China’s AliExpress.

  3. Does anyone know whether this debug probe offers better (or any) ESD protection versus just using a picoprobe? I use a picoprobe fairly regularly to program boards with RP2040 processors via SWD. I’ve probably programmed 300-400 over the past few months, but I’ve found that any static shock to the picoprobe will kill it. (Even customizing the image and switching to other GPIO pins doesn’t help.) My “workaround” has been to keep a few extra picoprobes pre-programmed and wired and ready to go, which is fine, but generally speaking the picoprobe does not have the same protection as an ICE programmer. (Which, considering they’re $5 versus $150, I’m not complaining.)

    But, a picoprobe with more protection would be great. Is that what this device is?

    1. Thankfully, sticking scare quotes in doesn’t magically invalidate a legal entity.

      Oh no! They’re making a product to fill a niche at a reasonable price point that isn’t a clone board with a fake chip and zero QA! How dare they!

        1. Cool, now go get a board made, buy all the other components, populate the board, buy/build the wires, and don’t forget to track your time. It’s $12 for all that, not too bad honestly.

  4. For an review testing a debug probe I think it would have been appropriate to spend more time on the debug aspects rather than the UART aspects. As discussed in the article there are already a number of UART to USB solutions out there, for the debug side previously this would have needed a second Pico or development on a Raspberry Pi. On the debug side of things there are two main uses, obviously the debugging of a running process but also the flashing of new firmware.

    I am not sure if there would have been low demand but one item I would have found useful would have been the option to power the target Pico from the debug probe, for early development / debugging cycles this would mean they can all be powered from a single USB port but in it’s current form I believe the second Pico will always need it’s own power source.

  5. In case it helps, this is for blinky.c example. I use VSCode and have the following add-ins:

    C/C++ (Microsoft)
    C/C++ Extension Pack (Microsoft)
    C/C++ Themes (Microsoft)
    CMake (Microsoft)
    CMake Tools (Microsoft)
    Cortex Debug (marus25)

    I cloned the following with git into the specified directories

    https://github.com/raspberrypi/pico-sdk is in /etc/embedded/pico-sdk
    https://github.com/raspberrypi/pico-extras is in /etc/embedded/pico-extras
    https://github.com/raspberrypi/pico-examples is in /etc/embedded/pico-examples

    Latest ARM (none-eabi) compiler is in /etc/embedded/arm-none-eabi

    To debug blinky.c with VSCode, I need the following files:

    1) pi-pico.sh in /etc/profile.d
    PICO_SDK_PATH=/opt/embedded/pico-sdk
    PICO_EXTRAS_PATH=/opt/embedded/pico-extras
    ARM_NONE_EABI=/opt/embedded/gcc-arm-none-eabi
    PATH=$PATH:$ARM_NONE_EABI/bin:$ARM_NONE_EABI/arm-none-eabi/bin
    export PATH PICO_SDK_PATH PICO_EXTRAS_PATH ARM_NONE_EABI

    2) 60-openocd.rules in /etc/udev/rules.d
    # /etc/udev/rules.d/60-openocd.rules
    # Raspberry Pi Debug Probe
    ATTRS{idVendor}==”2e8a”, ATTRS{idProduct}==”000c”, TAG+=”uaccess”

    3) launch.json (in project .vscode) – you need the Cortex debugging add-in for VSCode
    {
    “version”: “0.2.0”,
    “configurations”: [
    {
    “name”: “Pico Debug”,
    “type”: “cortex-debug”,
    “cwd”: “${workspaceRoot}”,
    “armToolchainPath”: “${env:ARM_NONE_EABI}/bin”,
    “executable”: “${command:cmake.launchTargetPath}”,
    “request”: “launch”,
    “servertype”: “openocd”,
    “openOCDLaunchCommands”: [ “adapter speed 5000” ],
    “configFiles”: [
    “interface/cmsis-dap.cfg”,
    “target/rp2040.cfg”
    ],
    “gdbPath”: “gdb-multiarch”,
    “device”: “RP2040”,
    “svdFile”: “${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd”,
    // “showDevDebugOutput”: “raw”,
    “postRestartCommands”: [
    “break main”,
    “continue”
    ],
    }
    ]
    }

    4) CMakeLists.txt in project directory
    cmake_minimum_required(VERSION 3.12)

    # Pull in SDK (must be before project)
    include(pico_sdk_import.cmake)

    project(pico_examples C CXX ASM)
    set(CMAKE_C_STANDARD 11)
    set(CMAKE_CXX_STANDARD 17)

    if (PICO_SDK_VERSION_STRING VERSION_LESS “1.3.0”)
    message(FATAL_ERROR “Raspberry Pi Pico SDK version 1.3.0 (or later) required. Your version is ${PICO_SDK_VERSION_STRING}”)
    endif()

    # Initialize the SDK
    pico_sdk_init()

    add_compile_options(-Wall
    -Wno-format # int != int32_t as far as the compiler is concerned because gcc has int32_t as long int
    -Wno-unused-function # we have some for the docs that aren’t called
    -Wno-maybe-uninitialized
    )

    add_executable(blinky blinky.c)

    # pull in common dependencies
    target_link_libraries(blinky pico_stdlib)

    # create map/bin/hex file etc.
    pico_add_extra_outputs(blinky)

    6) Extra files copied into to project directory
    /opt/embedded/pico-sdk/pico_sdk_init.cmake
    /opt/embedded/pico-sdk/external/pico_sdk_import.cmake
    /opt/embedded/pico-extras/external/pico_extras_import.cmake
    /opt/embedded//pico-extras/post_init.cmake

    7) blinky.c source file (generates morse)
    /opt/embedded/pico-examples/picoboard/blinky/blinky.c

    Pi Pico is connected as per this article. Don’t forget you still need to power the Pico from external power or from the USB lead!

    blinky.c will auto-compile and you can single step through using F10 (step-into) or F11 (step over).

    Works for me. These instruction (or similar ones) should be on the Raspberry Pi site I think.

    Next step is getting W5500-EVB-Pico (Pi Pico with Ethernet) working with FreeRTOS and the debug probe!

Leave a Reply to zoobabCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

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