In this lesson, you will learn how to design a robust, secure handshake between your application and a bootloader to ensure in-field firmware updates never leave your device in an unrecoverable state.
The Dual-Slot Strategy
In mission-critical embedded systems, you cannot simply overwrite the running firmware. Instead, we use a dual-slot approach where the "active" slot runs the current application, and the "secondary" slot acts as a staging area for incoming images.
The challenge is orchestrating the transition. The bootloader needs a reliable way to know that a newly downloaded image is not only complete but also authentic. We achieve this by using a shared Update Metadata Header located at a fixed memory address accessible to both the application and the bootloader.
Designing the Secure Handshake
Your Rust application writes to this header once the download is verified via a cryptographic signature (like Ed25519). The bootloader, upon reset, checks this structure before deciding whether to jump to the new code.
#[repr(C)]
struct UpdateMetadata {
magic_number: u32, // Verification key
version: u32,
image_size: u32,
signature: [u8; 64], // Cryptographic proof
state: UpdateState, // e.g., Pending, Validated, Reverting
}
enum UpdateState {
ReadyToInstall = 0x5A5A,
Confirmed = 0xA5A5,
}
By defining this struct with #[repr(C)], you ensure a stable memory layout that the bootloader (often written in minimal C or assembly) can parse directly from the memory-mapped flash.
Avoiding the "Brick" Scenario
Crucially, your application should not set the state to ReadyToInstall until the entire image is verified in the secondary slot. Once the bootloader starts the update, it must implement a "rollback" mechanism. If the new firmware fails to clear a hardware watchdog (integrating what we learned in lesson 24) within the first 60 seconds of operation, the bootloader triggers a fallback to the previous, known-good firmware slot. This creates a fail-safe loop that ensures your device remains reachable even if the update logic contains a logical error.
Key Takeaway: Secure firmware upgrades rely on a shared, immutable metadata contract and a hardware-enforced rollback strategy to guarantee recovery from faulty updates.