Platform specifics

probe-rs supports multiple probes out of the box.

Most of them require little to no setup. For linux, udev rules are required for non admin access.

Linux: udev rules

By default, the debug probes are only accessible by users with root privileges on Linux based systems. It is recommend to use appropriate udev rules to allow users without root privileges access to the debug probes as well.

1. Download the rules file and place it in /etc/udev/rules.d.
2. Run udevadm control --reload to ensure the new rules are used.
3. Run udevadm trigger to ensure the new rules are applied to already added devices.

If you’re still unable to access the debug probes after following these steps, try adding your user to the plugdev group. This group needs to be a system group if you use systemd version higher than v258. In this case you can try the following commands to fix the udev rules :

sudo groupadd --system plugdev
sudo usermod -a -G plugdev $USER

If you are using WSL, you may need to enable the udev service. To check if the service is running, run service udev status. If the service is not started, edit /etc/wsl.conf (with sudo) and make sure the following is included:

[boot]
command="service udev start"

Windows: WinUSB drivers

Some of the probe implementations are implemented using nusb which uses the WinUSB drivers on Windows. For these devices you will need to download Zadig and select WinUSB as the driver for your probe. This will uninstall any official drivers, which means that the official tools will most likely not work anymore after this.

CMSIS-DAP

CMSIS-DAP is a standard for debug probes which is managed by ARM. All probes implementing this standard are supported by probe-rs.

Setup

Linux

No additional drivers are required to use CMSIS-DAP based probes on Linux systems. To ensure that users without root privileges can use the debug probe, it is recommended to configure udev as described in udev rules.

Windows, macOS

No driver installation required.

ST-Link

The ST-Link is a debug probe from ST Microelectronics. It is commonly found on their evaluation boards, such as the Discovery and Nucleo boards.

Supported Versions

The following versions of the ST-Link are supported:

• ST-Link V2, Firmware version 2.26 or higher
• ST-Link V3, Firmware version 3.2 or higher

If you get an error message indicating that the firmware is outdated, please use the official ST tools to update the firmware. The update tool can be found on the ST website.

Setup

Linux

No additional drivers are required to use a ST-Link debug probe on Linux systems. To ensure that users without root privileges can use the debug probe, it is recommended to configure udev as described in udev rules.

Windows

To use the ST-Link on Windows, you need to install the official drivers, which can be found on the ST website.

macOS

No driver installation required.

SEGGER J-Link

The J-Link is a debug probe from Segger. It is available as a stand-alone product, but also integrated into some evaluation boards directly.

Due to the proprietary nature of the J-Link, probe-rs will not achieve the same speed as the official J-Link tools.

Setup

Linux

No additional drivers are required to use a J-Link debug probe on Linux systems. To ensure that users without root privileges can use the debug probe, it is recommended to configure udev as described in udev rules.

Windows

Unfortunately, probe-rs doesn’t work with the official drivers on Windows. To use probe-rs it is necessary to install a generic WinUSB driver. The recommended way of doing this is by using the J-Link Configurator tool. To install the generic WinUSB driver with the J-Link Configurator tool:

• Download the J-Link Configurator tool
• Connect the J-Link probe you wish to update
• Start the J-Link Configurator tool
• Right click the entry in the overview where your probe is listed, and select Configure
• Under USB Driver (Windows) select WinUSB
• Click OK

Some J-Link probes will have the option to select WinUSB in the configuration dialog disabled. In this case, use Zadig to install the generic WinUSB driver for your probe.

macOS

No driver installation required.

FTDI

FTDI refers to a family of debug probes built using USB-JTAG bridges from FTDI. probe-rs supports the following chips:

• FT232H
• FT2232C, FT2232D, FT2232H
• FT4232H

Due to the configurable nature of these chips, not every probe may be picked up by probe-rs. If you have a probe that you know contains an FTDI chip, but probe-rs does not recognise it, please open a ticket on GitHub!

The following devices are known to work with probe-rs:

• esp-prog
• The debug interface of ESP32-Ethernet-Kit V1.2
• Adafruit FT232H Breakout
• Olimex ARM-USB devices:
  • ARM-USB-OCD
  • ARM-USB-OCD-H
  • ARM-USB-TINY
  • ARM-USB-TINY-H

Setup

Linux

No additional drivers are required to use a FTDI-based debug probe on Linux systems. To ensure that users without root privileges can use the debug probe, it is recommended to configure udev as described in udev rules.

Windows

Unfortunately, probe-rs doesn’t work with the official (VCP or D2xx) drivers on Windows. To use probe-rs it is necessary to install a generic WinUSB driver. The recommended way of doing this is by using Zadig.

macOS

No driver installation required.

ESP32 devices with built-in USB-JTAG interface

Some ESP32 devices come with built-in debug probes. The availability of this interface varies, but usually, if your device includes two USB ports, one labelled USB, the other UART, then there’s a good chance the one marked as USB can act as a debug probe.

Setup

Linux

No additional drivers are required to use an ESP32 built-in debug interface on Linux systems. To ensure that users without root privileges can use the debug probe, it is recommended to configure udev as described in udev rules.

Windows, macOS

No driver installation required.

Some ESP32 devices have an incorrect WinUSB Descriptor. If probe-rs list shows your device, but probe-rs info fails with Could not find DeviceInterfaceGUIDs in registry, you may need to reinstall the driver using Zadig. You can find more information in this GitHub discussion: https://github.com/probe-rs/probe-rs/discussions/3193

Glasgow Interface Explorer

No additional drivers are required on any OS, but the device must be first configured using the Python toolkit that comes with it. Refer to the installation instructions for further details.

Setup

Before running probe-rs, configure the target voltage and pinout using the glasgow CLI command. For example, if your target’s SWCLK is connected to pin “A0” and SWDIO is connected to pin “A1”, and it uses 3.3 V logic levels, use:

$ glasgow run probe-rs -V A=3.3 --swclk A0 --swdio A1

The terminal output of the glasgow command will include the arguments needed to run probe-rs.

Note that the “*V” (voltage) pins provide power to the target, and the “*S” (sense) pins measure the target’s logic voltage level. If your target provides a reference voltage level (Vtg or similar), for example, you could connect it to the “AS” pin and run the glasgow tool as:

$ glasgow run probe-rs -V A=SA --swclk A0 --swdio A1

Do not back-power the probe by connecting a power source to the “*V” pins.

It is also possible to use the debug probe functionality together with other applets, such as a serial terminal; for example, if your target’s transmit wire is connected to pin “A2” and receive wire to pin “A3”:

$ glasgow multi probe-rs -V A=3.3 --swclk A0 --swdio A1 ++ uart --rx A2 --tx A3 --auto-baud

Linux GPIO bit-bang (linuxgpiod)

Bit-bangs SWD over GPIO lines exposed by the Linux kernel’s character-device interface (/dev/gpiochipN). Useful when the host running probe-rs is itself a Linux SBC whose GPIOs are routed to a target SoC’s SWD pins (typically through level shifters), and you don’t want a separate USB debug probe in the picture.

Linux only. SWD only. Effective bit rate is bounded by gpio-cdev ioctl throughput — typically tens of kHz.

This driver lives in the probe-rs-linux plugin crate, which probe-rs-tools pulls in automatically on Linux — no Cargo features required.

Setup

Pin assignments are passed via the --probe selector with VID and PID both set to zero, and the SWD line offsets in the serial field:

$ probe-rs run \
    --probe '0:0:gpiochip1,swclk=26,swdio=25,srst=38' \
    --chip <CHIP> firmware.elf

<gpiochip> accepts gpiochipN, /dev/gpiochipN, or just the numeric index N. srst is optional — without it, target reset is software-only.

Permissions

/dev/gpiochipN is owned by root:gpio on most distributions. Add your user to the gpio group (or run probe-rs with sudo):

$ sudo usermod -aG gpio $USER

Auto-discovery (probe-rs list with no --probe) does not enumerate gpiod probes — pin assignments are board-specific and cannot be inferred. You must always supply an explicit selector.

For a worked end-to-end example on a real board, see the Arduino UNO Q knowledge-base entry.

Linux SPI bit-bang (linuxspidevswd)

Emulates SWD over a Linux spidev bus by tying the host’s PICO (MOSI) and POCI (MISO) lines together through a series resistor (~1 kΩ) and using that node as SWDIO. SCLK drives SWCLK. Useful when the host is a Linux SBC whose SPI peripheral is wired to a target’s SWD pins, and you want speeds well above what linuxgpiod can sustain — this driver has been tested up to 18 MHz.

Linux only. SWD only. Like linuxgpiod, this driver is part of the probe-rs-linux plugin crate and is registered automatically on Linux builds.

Wiring

   Host                     Target
+--------+     1K         +--------+
|    PICO|---/\/\/\---+   |        |
|        |            |   |        |
|    POCI|------------+---|SWDIO   |
|        |                |        |
|     SCK|----------------|SWDCLK  |
+--------+                +--------+

The exact resistor value depends on SWD clock speed and host/target drive strength; 1 kΩ is a good starting point.

Raspberry Pi pinout (SPI0)

Enable SPI with raspi-config and reboot; the bus will appear as /dev/spidev0.0.

Probe selection

Select the spidev device directly with a synthetic selector whose serial field carries the spidev path:

$ probe-rs info --probe '0:0:/dev/spidev0.0'

The VID:PID portion is ignored.

Auto-discovery and the spidev_swd udev rule

For safety, probe-rs list does not enumerate every SPI bus on the system — it only exposes spidev devices that are reachable through an explicit /dev/spidev_swd* symlink. To opt a bus into auto-discovery, create a udev rule:

$ sudo tee /etc/udev/rules.d/99-spidev-swd.rules <<EOF
SUBSYSTEM=="spi", KERNEL=="spidev*", SYMLINK+="spidev_swd%n"
EOF

Explicit --probe '0:0:/dev/spidevX.Y' selectors always work regardless of whether the symlink exists.

Cross-compiling for a Raspberry Pi host

# Pi 1 / Pi Zero
cross build -p probe-rs-tools --target arm-unknown-linux-gnueabihf --release --features remote

# Pi 3 / 4 / 5
cross build -p probe-rs-tools --target aarch64-unknown-linux-gnu --release --features remote

Copy the resulting binary onto the Pi and run it directly:

$ ./probe-rs info --protocol swd --probe '0:0:/dev/spidev0.0' --speed 1000

To drive the Pi remotely from a workstation, run probe-rs serve on the Pi (see the probe-rs tool docs for the server config) and point a remote client at it:

$ probe-rs --host ws://pi-zero-w.local:3000 --token "token" \
    info --protocol swd --speed 1000 --probe '0:0:/dev/spidev0.0'