Firmware updates with recovery and rollback

A firmware update reaches a device that has no display and no service connector the customer can use. The download finishes, the device restarts, and it never reconnects. A recovery design should answer what happens next before that update ships.

No bootloader configuration can guarantee that a device will never become unusable. Hardware faults, damaged storage and mistakes outside the update mechanism still matter. The practical goal is narrower: identify the failures the product must recover from, choose an update scheme that supports those recoveries, and demonstrate the expected behavior on the hardware and software actually shipped.

This is a planning checklist for that work. It distinguishes accepting an image, starting it, and deciding that it is suitable to keep running.

Name the failure before choosing a mechanism

A damaged download and a correctly signed application that crashes are different problems. A power interruption during an erase is different again. Write a short failure table with the required outcome for each case.

For an incomplete download, the outcome might be that the current firmware continues operating and the update can restart. For a candidate application that fails its startup diagnostics, it might be a return to the previous working image. For damaged update metadata, identify the mechanism that determines which image remains bootable. Avoid a generic requirement that simply says “support OTA.”

Separate image authenticity from application health. A signature can establish that an image was authorized by the holder of a trusted signing key; it does not prove that the application’s logic works. A recovery design has to address both.

Also identify the scope of the update. Replacing only an application is a different operation from changing a partition layout, bootloader, radio firmware or stored configuration. Do not assume a recovery claim for one operation covers all the others.

Choose a layout with a documented recovery path

The MCUboot design documentation describes multiple update strategies, including swapping images, overwrite-only updates and direct execution. Their constraints and recovery behavior differ. In particular, overwrite-only mode does not provide the same revert capability as a swap strategy configured for test and revert.

Use the documentation for the chosen port and release to determine the required slots, metadata, erase geometry and any working space. Budget for those areas before setting the application size limit. Inspect the resulting build configuration; the presence of a secondary partition alone is not proof that recovery is enabled.

For the product review, draw the actual flash map and label what is written at each phase. Show where the candidate arrives, what stays available during that write, how a boot choice changes, and how an interrupted operation is recognized at restart. If a step has no documented recovery behavior, it is a design question to resolve rather than an assumption to leave in the drawing.

The chosen mechanism also needs to fit the expected update lifecycle. Review flash endurance and the amount of writing involved against the relevant hardware documentation. There is no universal scratch-area size or update count that fits every device.

Decide what successful startup means

With an appropriate test-and-confirm scheme, starting a candidate image is provisional. Application confirmation marks a checkpoint after which the release is accepted. Decide what that checkpoint needs to establish for this product.

The ESP-IDF OTA documentation describes application-controlled confirmation and rollback after an unconfirmed application resets. The details depend on the enabled configuration and the availability of an eligible fallback image. It also distinguishes startup confirmation from diagnostics performed by application code. Check the actual framework version and settings instead of assuming a default provides the required checks.

Choose diagnostics that reveal important firmware failures without making normal external conditions look like a bad release. For example, requiring an internet connection before confirmation may reject working firmware when the customer’s router is offline. Conversely, confirming before the update client can initialize may accept firmware that cannot receive a repair. Define that tradeoff explicitly.

A hung application may need a reset mechanism before a bootloader can make another selection. Review watchdog operation and reset behavior with the recovery design. Do not describe a confirmation flag as protection against every possible hang or boot loop.

Keep persistent data compatible with recovery

Rolling back the executable is only part of returning to a usable product. Review settings, calibration, credentials and other persistent data that the new application can modify before confirmation.

If the old firmware cannot read a new data format, returning to its image may not restore operation. Plan when migrations occur, whether the old version can still read the data, and what happens if migration is interrupted. The right approach depends on the storage format and product requirements; it should be tested alongside the executable update.

Include backend compatibility in the same review. A recovered device still needs whatever services its operation and future updates require. A successful boot that cannot receive the next release is an incomplete recovery outcome.

Plan the security version and signing process

Recovery rollback and security anti-rollback solve different problems. The first restores a working image after a failed update. The second can prevent an attacker from installing an older vulnerable image. Their policies must agree about which fallback remains eligible.

MCUboot’s image tool documentation provides separate image-version and security-counter options. Those packaging options are not, by themselves, proof that a particular target enforces the intended security policy. Review the bootloader configuration and target’s trusted state together, especially before an irreversible counter or fuse change.

Keep signing permissions controlled and record which key and build produced each release artifact — the same record-keeping the EU’s Cyber Resilience Act now expects a connected product to have. Plan key replacement and recovery using the capabilities actually provisioned in the product. Avoid assuming the key configuration can be changed remotely just because application updates work.

Test the shipped combination

Keep the production bootloader binary and partition configuration with the release evidence. Espressif’s bootloader compatibility guidance specifically recommends testing an existing product’s OTA updates using its deployed bootloader binary. A current development board may have a different starting point from units already installed.

On qualification hardware, exercise the failure cases identified in the plan:

• Interrupt the download and confirm that a later attempt can recover.
• Present a truncated image and, where signature enforcement is configured, an image signed with an untrusted key.
• Reset a candidate before confirmation and observe the defined fallback behavior.
• Interrupt power at relevant erase, write, selection and confirmation phases.
• Check persistent-data behavior after both a successful update and a recovery.
• Verify that the recovered version can receive a subsequent valid update.

Record the starting firmware, bootloader, hardware revision, failure injection and observed result. A passing test supports that tested case; it is not a universal guarantee. Use staged deployment and observable version/recovery status to limit the impact of problems not found during qualification.

For an update-path review, bring the MCU, flash map, deployed bootloader, framework version, update transport and the recovery behavior the product needs. Those inputs turn “make updates reliable” into concrete design decisions and tests.