Skip to main content
Use probe-rs to program a board attached to a remote hardware bridge and to capture RTT output from the firmware you just flashed. Embedder runs probe-rs on the bridge host whenever the bridge target has a known MCU. The installed probe-rs version must support the exact chip and debug probe. A board’s presence in the hardware catalog doesn’t establish that support. For a board attached to your own machine, put your probe-rs command in the project’s flash command instead; see Flashing firmware.

​
Prepare the hardware host

  1. Set up the remote hardware bridge, then run /bridge in chat and select it.
  2. Install probe-rs on the bridge host as your normal user, not as root, so the bridge can find it: The bridge must also have permission to access the USB probe.
  3. Connect the probe to the target’s reference voltage, ground, and the SWD or JTAG signals the board requires. Power the target as its board documentation describes.
  4. Identify the exact chip and probe. List probes with embedder bridge exec <name> probe-rs list, and check chip names with embedder bridge exec <name> probe-rs chip list.
  5. Build an ELF for that target and note its path in the project.
Check the bridge from your workstation:
The Flasher (probe-rs) line shows where probe-rs is installed, or not installed with a fix. Then ask Embedder to confirm the target:

​
Program and start the target

Replace the artifact path with your build output. Embedder asks you to approve the flash, unless your approval settings already allow it. It then uploads the artifact to the bridge, programs it with probe-rs, and resets the target to start the firmware. Serial connections in the Monitor pause during programming and reconnect afterward. Embedder picks the chip and probe like this: After a successful flash with a chip you named, Embedder saves the board on the bridge so later flash and RTT requests find it.
Programming replaces the firmware and changes the target’s execution state. Don’t substitute a similar MCU to get past an unsupported-chip error.
A successful download can still be followed by a failed reset. The result then ends with a warning that the firmware may not be running. Check it before you assume the application started. When a bridge board has no MCU but has an OpenOCD target and a supported debug interface, Embedder flashes it with OpenOCD instead. See Flashing firmware.

​
Capture RTT after programming

The firmware must include RTT output. On a bridge, Embedder reads RTT from the artifact you flashed through Embedder earlier in the same session, so flash the matching ELF first. Then request a bounded capture:
The capture ends at the time limit or when the stop text appears. The bridge manages probe speed on this path, so a frequency you give is ignored. If the current fault or RAM contents must be preserved, don’t flash only to use this workflow. Use an existing RTT connection instead, or review the debugger attachment precautions.

​
Choose debugging separately

For breakpoints, stepping, and memory inspection, use the J-Link or OpenOCD guide. Using probe-rs for bridge flashing doesn’t make it Embedder’s debugger.

​
Troubleshoot

  • probe-rs not installed: embedder bridge doctor reports Flasher (probe-rs) as not installed. Install probe-rs on the bridge host as your normal user, then run the check again.
  • Chip unsupported: compare the exact chip name with probe-rs chip list on the bridge host.
  • No auto-detectable target: the bridge has no saved board. Give the exact chip name in your request.
  • Multiple probes or multiple targets: give the intended probe as VID:PID:Serial, or name the board or chip.
  • Probe busy: Embedder retries briefly when a previous command still holds the probe. A device busy result means another operation on the bridge still holds that probe or board. Wait for it to finish, then retry.
  • Download succeeded but no boot: check the reset result, target power, and the firmware’s output transport.
  • RTT needs a flashed ELF: nothing was flashed to this bridge in the current session. Preserve any fault evidence before you decide to program.
See Flashing firmware for checking boot results and Hardware scripts for repeatable checks.
Last modified on October 13, 2026