Designing Atomic Firmware Update Mechanisms

In this lesson, you will learn how to design a dual-bank flash memory architecture to guarantee that your device always has a valid, bootable firmware image, even if an update is interrupted.

The Problem: The "Bricked" Device

In simple, single-bank update systems, the device erases its active firmware to write the new version. If power is lost or the connection drops during this window, the device is left with a corrupted image, rendering it unresponsive (bricked). To achieve an "atomic" update—where the firmware is either fully present and valid, or the device remains on the previous known-good version—we use a dual-bank strategy.

Dual-Bank Flash Architecture

In this design, we divide the internal (or external) flash into two partitions: Slot A (Active) and Slot B (Secondary).

1. Operation: The application runs solely from Slot A.
2. Update: While the system is operational, the firmware installer writes the new binary into Slot B. Because Slot A is still running the original firmware, an interrupted download simply results in an invalid Slot B, leaving the device functional.
3. Verification: Once the download is complete, a bootloader performs a cryptographic integrity check on Slot B.
4. The Atomic Switch: Only after the integrity check passes does the bootloader update a "boot flag" in non-volatile memory (e.g., a dedicated flash sector or a specific register). On the next reset, the bootloader reads the flag, sees the new update is verified, and executes a jump to Slot B.

Implementation Logic

The bootloader's primary responsibility is to check this swap condition during the reset sequence:

void bootloader_entry() {
    if (is_valid_image(SLOT_B) && boot_flag == BOOT_FROM_B) {
        jump_to_address(SLOT_B_ADDR);
    } else {
        // Fallback to active/known-good bank
        jump_to_address(SLOT_A_ADDR);
    }
}

By ensuring that the switch occurs via a single flag update after a full verification, you create an atomic transaction. If the system crashes while updating Slot B, the bootloader never toggles the flag, and the device continues to boot the existing, trusted image in Slot A.

Key Takeaway: By utilizing a dual-bank memory strategy, you decouple the firmware acquisition process from the execution state, ensuring the device remains resilient against corruption through a verified, atomic commit point.