Crate probe_rs

source ·
Expand description

Debugging toolset for embedded devices


  • Udev rules
  • libusb


Halting the attached chip

use probe_rs::{Probe, Permissions};

// Get a list of all available debug probes.
let probes = Probe::list_all();

// Use the first probe found.
let mut probe = probes[0].open()?;

// Attach to a chip.
let mut session = probe.attach("nrf52", Permissions::default())?;

// Select a core.
let mut core = session.core(0)?;

// Halt the attached core.

Reading from RAM

use probe_rs::{Session, Permissions};
use probe_rs::MemoryInterface;

let mut session = Session::auto_attach("nrf52", Permissions::default())?;
let mut core = session.core(0)?;

// Read a block of 50 32 bit words.
let mut buff = [0u32;50];
core.read_32(0x2000_0000, &mut buff)?;

// Read a single 32 bit word.
let word = core.read_word_32(0x2000_0000)?;

// Writing is just as simple.
let buff = [0u32;50];
core.write_32(0x2000_0000, &buff)?;

// of course we can also write 8bit words.
let buff = [0u8;50];
core.write_8(0x2000_0000, &buff)?;

probe-rs is built around 4 main interfaces: the Probe, Target, Session and Core structs.


  • pub use crate::config::Target;


  • All the interface bits for the different architectures.
  • Target specific configuration
  • Debugging support for probe-rs
  • Flash programming operations.
  • Host side implementation of the RTT (Real-Time Transfer) I/O protocol over probe-rs



  • The id of a breakpoint.
  • Generic core handle representing a physical core on an MCU.
  • An struct for storing the current state of a core.
  • A generic core state which caches the generic parts of the core state.
  • Gathers some information about a debug probe which was found during a scan.
  • A struct to describe the way a probe should be selected.
  • This is a mock probe which can be used for mocking things in tests or for dry runs.
  • The Permissions struct represents what a Session is allowed to do with a target. Some operations can be irreversable, so need to be explicitly allowed by the user.
  • The Probe struct is a generic wrapper over the different probes supported.
  • Describes a register with its properties.
  • Register description for a core.
  • The location of a CPU \register. This is not an actual memory address, but a core specific location that represents a specific core register.
  • The Session struct represents an active debug session.


  • The architecture family of a specific CoreType.
  • The method that should be used for attaching.
  • When the core halts due to a breakpoint request, some architectures will allow us to distinguish between a software and hardware breakpoint.
  • The status of the core.
  • Type of a supported core.
  • This error occurs whenever the debug probe logic encounters an error while operating the relevant debug probe.
  • Denotes the type of a given DebugProbe.
  • The overarching error type which contains all possible errors as variants.
  • The reason why a core was halted.
  • Instruction set used by a core
  • An error during probe creation accured. This is almost always a sign of a bad USB setup. Check UDEV rules if you are on Linux and try installing Zadig (This will disable vendor specific drivers for your probe!) if you are on Windows.
  • A value of a core register
  • The architecture specific core state.
  • The protocol that is to be used by the probe when communicating with the target.


  • A generic interface to control a MCU core.
  • An abstraction over general debug probe functionality.
  • An interface to be implemented for drivers that allow target memory access.
  • A memory mapped register, for instance ARM debug registers (DHCSR, etc).