Search topics...
Safety & SecurityOTA Updatesadvanced

How do you implement A/B firmware updates with rollback?

0 upvotes
Practice with AISoon

The A/B update scheme (also called ping-pong or dual-bank) maintains two complete firmware slots in flash memory — Slot A and Slot B. At any given time, one slot contains the active (running) firmware and the other contains either the previous version or a newly downloaded update. When an OTA update is available, the new firmware image is downloaded and written to the inactive slot while the current firmware continues running uninterrupted. Once the download is complete and the image is verified (CRC or cryptographic signature), the bootloader metadata is updated to mark the inactive slot as the "pending" boot target, and the device reboots.

The bootloader is the critical component that enables rollback. On reboot, the bootloader checks the metadata (stored in a dedicated flash sector or OTP area) and boots from the newly written slot. But it does not immediately mark the new firmware as "confirmed." Instead, the new firmware must explicitly call a confirmation function (e.g., boot_set_confirmed() in MCUboot) after it has successfully initialized, passed self-tests, and established connectivity. If the new firmware crashes before confirming — due to a bug, incompatible configuration, or corrupted image — the watchdog timer fires, the device resets, and the bootloader sees that the pending slot was never confirmed. It then rolls back to the previous slot, which is known-good. This mechanism ensures that a bad update can never permanently brick a device, even if the failure occurs during the first few seconds of boot.

The tradeoff of A/B updates is flash usage: you need at least 2x the firmware size in flash (plus bootloader and metadata sectors). For a 256 KB firmware image on a 1 MB flash, this is manageable. For a 2 MB firmware on a 4 MB flash, it consumes most of the available space. Alternatives include differential updates (delta patches that modify the active slot in-place, with a recovery partition for rollback) and single-slot with external flash (download to external SPI flash, verify, then copy to internal flash). MCUboot (used with Zephyr), ESP-IDF's OTA library, and STM32's SBSFU all implement A/B update schemes with minor variations. Key implementation details interviewers probe: how do you handle power loss during the flash write (answer: the inactive slot is being written, so the active slot remains intact), how do you prevent downgrade attacks (answer: include a version counter checked by the bootloader), and how do you verify integrity before rebooting (answer: compute SHA-256 over the entire image and verify the signature before marking it as pending).

Source: Safety & Security Q&A