A firmware update that bricks a device in the field is not merely a technical failure, it is an operational and commercial event. For an automotive ECU, it means a vehicle that cannot be returned to service without a dealer visit. For an industrial controller managing a production line, it means unplanned downtime. For a field-deployed IoT device in a remote location, it means a service call that costs more than the device itself.
The A/B partition bootloader architecture, also known as dual-bank or dual-partition OTA, exists specifically to make this failure mode impossible. By maintaining two complete firmware image slots and only switching between them after a verified, confirmed successful update, A/B partitioning ensures that a failed update, an interrupted power supply, or a corrupt download always leaves the device running known-good firmware.
What A/B Partition Architecture Means
In a conventional single-partition flash layout, the application firmware occupies a single region of flash memory. An OTA update erases this region and writes the new firmware. If power fails during the write, the flash contains a partially written image and the device cannot boot.
A/B partition architecture divides the application flash region into two equally-sized slots, Slot A and Slot B, each large enough to hold a complete firmware image. A bootloader region at the base of flash lies outside both slots and is never modified during OTA operations. A bank descriptor in non-volatile memory records which slot is active and which is the update target. During an OTA update, new firmware is written entirely to the inactive slot while the device continues running from the active slot. The active slot is never touched during the update process.
Boot Confirmation: The Second Safety Layer
Successful write and verification of the new firmware image does not guarantee that the new firmware will run correctly. The new image may pass signature and CRC checks but crash on startup due to a configuration mismatch or a firmware bug in the new release.
The boot confirmation mechanism addresses this. After the bootloader performs the bank swap and boots the new firmware for the first time, it marks the new boot as unconfirmed and starts a confirmation timer. The application firmware must complete its startup self-test and call a bootloader API to confirm successful operation within the timeout window. If the confirmation window expires without a call, because the new firmware crashed or hung, the bootloader automatically rolls back to the previously active slot on the next reboot.
Golden Image: The Recovery Fallback
The Golden Image pattern maintains a third, write-protected firmware region containing a minimal but fully functional firmware version. The golden image is written at the factory, protected by hardware write-protect mechanisms, and invoked only when the bootloader cannot find a valid image in either A/B slot. The golden image provides basic network connectivity and OTA download capability, enabling recovery without requiring physical access.
Anti-Brick Design Principles
Beyond A/B partitioning and boot confirmation, robust anti-brick bootloader design includes bootloader self-protection preventing the bootloader flash region from being overwritten during application execution, watchdog integration ensuring the bootloader triggers a reset if it hangs during image verification, and minimum boot attempt limiting preventing a confirmed-bad image from consuming battery through repeated boot-crash-reboot cycles by counting failed boot attempts and falling back after a configurable threshold.
| Feature | Single Partition | A/B Partition | A/B + Golden Image |
|---|---|---|---|
| Power loss during write | Brick | Safe - active untouched | Safe |
| Bad firmware at runtime | Brick | Rollback via confirmation | Rollback or golden |
| Dual-slot flash cost | None | 2x app flash | 2x app + golden flash |
| Recovery without field access | No | Yes (if prev slot valid) | Yes (golden always valid) |
Implementing A/B Partition Bootloader with RAPIDSEA
RAPIDSEA's bootloader suite implements the complete A/B partition architecture with boot confirmation, golden image support, and anti-brick safeguards for automotive and industrial embedded platforms across Renesas, NXP, Infineon, and STMicroelectronics MCU families. Firmware image authentication using RSA or ECDSA asymmetric signature verification is applied to each slot independently before any bank switch is performed. Anti-rollback counters in OTP or secure NVM prevent downgrade attacks. OTA delivery over CAN, CAN-FD, LIN, Ethernet, UART, Wi-Fi, and LTE/5G is supported through protocol-specific download managers. The Flint IDE bootloader configurator provides graphical partition layout definition, rollback counter configuration, and security algorithm selection.
Conclusion
A/B partition bootloader architecture makes bricking through failed firmware updates architecturally impossible under normal fault conditions. By separating firmware delivery from firmware activation, maintaining boot confirmation as a runtime correctness gate, and providing golden image recovery for catastrophic scenarios, the architecture delivers the reliability that always-on automotive and industrial deployments demand.
RAPIDSEA's bootloader suite delivers production-validated A/B partitioning with all associated safety mechanisms, enabling embedded teams to deploy reliable OTA firmware management without building bootloader infrastructure from first principles.
Ready to implement A/B partition OTA? Contact our team to request an evaluation build or book a technical demo.