OTA updates that cannot brick a device

An over-the-air update is the riskiest thing a deployed device does. It rewrites the code that runs the device, often over a poor link, and sometimes as the site loses power. If the design assumes the update will finish, one bad night produces a box that nobody can reach without a visit.

Two slots, one running

The basic design is A/B: flash holds two application slots, and the bootloader runs one of them. An update is always written to the slot that is not running. The working image is never touched while the new one is being written, so a failed download leaves the device exactly as it was.

On ESP32 this is the OTA partition scheme, with two app partitions and an otadata partition that records which one to boot. STM32 parts with dual-bank flash can swap banks in hardware. A single-bank part can still do it with a bootloader and a staging area, at the cost of flash size, so decide at MCU selection.

Verify before you switch

Before the bootloader is told to use the new slot, the firmware checks the image it just wrote:

• A length and a CRC32 or SHA-256 over the whole image, compared against a value sent separately from the download.
• A signature, if the product needs to refuse firmware it did not build. ECDSA P-256 or Ed25519 are common choices, and the public key that verifies it lives in the bootloader or in protected flash.
• A hardware and version check, so a build for one board cannot be installed on another, and an older image cannot be pushed on to block a security fix.

TLS protects the download. It does not replace verifying the stored image.

Boot confirmation and rollback

A new image that verifies can still be broken: it may boot and then fail to join the network. So the new slot starts as “pending”. The application must prove itself, for example by connecting to the broker and completing one successful publish, and only then mark the image valid. If it resets or hangs before that, the watchdog restarts the device, the bootloader sees an unconfirmed image and returns to the old slot.

Limit boot attempts to two or three, so the device does not loop on a bad image.

Power loss during an update

Cutting power in the middle of a write is a test we run on purpose: pull the supply at random points during download, during flash write and during the switch of the boot flag. The boot flag update should be a single small atomic write. Anything else should be recoverable from the old slot.

What this does not fix

A/B slots do not protect the bootloader itself, and they do not help with a new image that works but behaves wrongly, such as a changed sensor scale. They also halve usable flash. So keep the bootloader frozen and tiny, and roll updates out in stages, a few devices first.

---

If you are planning OTA for a product and want the flash layout and rollback logic reviewed early, book a discovery call, or read about our embedded firmware work.