Crate probe_rs

source ·
Expand description

§Debugging toolset for embedded devices


  • Udev rules


§Halting the attached chip

use probe_rs::probe::{list::Lister, Probe};
use probe_rs::Permissions;

// Get a list of all available debug probes.
let lister = Lister::new();

let probes = lister.list_all();

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

// 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, 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.
  • Helper functions for integration tests in your application using probe-rs.
  • Probe drivers
  • Host side implementation of the RTT (Real-Time Transfer) I/O protocol over probe-rs



  • Generic core handle representing a physical core on an MCU.
  • A snapshot representation of a core state.
  • An struct for storing the current state of a core.
  • Describes a core (or CPU / hardware) register with its properties. Each architecture will have a set of general purpose registers, and potentially some special purpose registers. It also happens that some general purpose registers can be used for special purposes. For instance, some ARM variants allows the LR (link register / return address) to be used as general purpose register R14.“
  • A static array of all the registers (CoreRegister) that apply to a specific architecture.
  • A generic core state which caches the generic parts of the core state.
  • The Permissions struct represents what a Session is allowed to do with a target. Some operations can be irreversible, so need to be explicitly allowed by the user.
  • 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.
  • When the core halts due to a breakpoint request, some architectures will allow us to distinguish between a software and hardware breakpoint.
  • The overarching error type which contains all possible errors as variants.
  • The status of the core.
  • Type of a supported core.
  • The overarching error type which contains all possible errors as variants.
  • The reason why a core was halted.
  • Instruction set used by a core
  • This is used to label the register with a specific role that it plays during program execution and exception handling. This denotes the purpose of a register (e.g. return address), while the CoreRegister::name will contain the architecture specific label of the register.
  • A value of a core register
  • Indicates the operation the target would like the debugger to perform.
  • The architecture specific core state.
  • When a core hits an exception, we halt the core.