Hardware-in-the-Loop Testing

In this lesson, you will learn how to orchestrate Hardware-in-the-Loop (HiL) testing by integrating physical hardware validation directly into your Rust CI/CD pipeline.

The Challenge of Firmware Reliability

When developing embedded systems, simulation—even with robust WASM-based sandboxes—only takes you so far. HiL testing bridges the gap by executing your firmware on actual target microcontrollers during the CI/CD process. This prevents "it worked on my machine" regressions where compiler-specific optimizations or hardware-level race conditions manifest only on the silicon.

Orchestrating the Hardware Loop

To integrate this into a pipeline (like GitHub Actions or GitLab CI), your runner must act as an orchestrator that bridges the cloud environment and the physical lab bench. The process generally follows three steps:

1. Deployment: Using a runner connected to a local hardware interface (like an ST-Link or J-Link), the CI environment flashes the binary onto the target.
2. Execution: The runner triggers the firmware. Because you are testing real hardware, you cannot use standard unit tests; you must use a host-side test runner (often a separate Rust binary) that communicates with the target via Serial (UART) or RTT (Real Time Transfer).
3. Verification: The test runner monitors the target’s output and asserts against expected behavior.

Concrete Example

Using probe-rs, a powerful library for interacting with embedded chips, your CI test suite might look like this:

#[test]
fn test_hardware_sensor_reading() {
    let mut session = connect_to_target()?; // Connect via J-Link
    flash_binary(&mut session, "firmware.bin")?;
    session.run()?;

    // Interact with the device via RTT to get logs/data
    let output = session.read_rtt_data()?; 
    assert!(output.contains("Sensor Ready: OK"));
}

By adding a self-hosted runner with the physical device attached, your CI/CD pipeline becomes a gatekeeper for hardware stability. If a PR changes memory-mapped register access, the CI will flash the chip, observe the hardware’s response to that specific code change, and fail if the physical device crashes or sends an invalid signal. This creates a high-fidelity feedback loop that catches hardware-specific bugs long before they reach production firmware binaries.

Key Takeaway: Hardware-in-the-Loop testing turns your CI/CD pipeline into a physical test rig, using tools like probe-rs to flash, execute, and verify firmware changes on real silicon to ensure hardware-level stability.