OSFTC.014 — MCUboot Test Upgrades, Image Confirmation and Recovery Validation. A firmware update is not finished when a new image first starts running. On systems that support a trial upgrade, the new firmware may remain provisional until it confirms successful operation. If it crashes, resets or fails to confirm, a properly configured bootloader can restore the previous application. A technician must distinguish a successful file transfer, a successful boot, an image-confirmation event and a verified recovery. They are separate milestones.
This lesson follows OSFTC.013 on firmware image integrity and extends the earlier firmware backup and recovery and update security lessons. It uses the open-source MCUboot and Zephyr/MCUmgr ecosystem as a concrete example; exact menus, slot layouts, supported rollback modes and commands differ across hardware and firmware configurations.
What a trial firmware upgrade does
In a dual-slot MCUboot configuration, the device normally has a primary image slot containing the running application and a secondary slot used to stage an upgrade. After a compatible, appropriately signed update has been uploaded, the update system can request a test upgrade. On reboot, MCUboot starts the candidate firmware. If the image remains unconfirmed, the bootloader’s next compatible restart can revert to the prior image. The capability depends on the configured boot mode and retention of a usable previous image—not merely the existence of two named flash partitions.
MCUboot’s design documentation distinguishes test, permanent and revert swap types. The Zephyr MCUboot image-control API exposes functions to request an upgrade, query confirmation and confirm a running image. Some other configurations, including overwrite-only updating, do not preserve a straightforward automatic rollback path. Never assume automatic revert is present without inspecting the actual firmware build and device instructions.
Why signed firmware is not the same as healthy firmware
A signature helps the bootloader decide whether an image is authentic under the configured trust keys and whether its protected bytes have been altered. It does not prove that the application can initialize a sensor, communicate on its network, load valid persistent settings or complete its normal duties. The update may verify cryptographically and then fail during the operating-system startup or peripheral initialization stage.
The image-integrity lesson explains hashes, signed images and hardware compatibility. In the trial-upgrade model, confirmation represents a second decision: the newly running software reports that it is suitable to retain, ideally after whatever health checks the product requires. Confirmation itself can be automatic application behavior or an authorized management action, depending on the software and release policy.
Image states and what the technician should observe
An image-management client can report whether firmware is active, pending, confirmed or permanent. Those terms describe bootloader image state; they do not independently establish that the whole product passed its operational acceptance test. The Zephyr image-management API reference documents these flags, while the MCUmgr SMP server sample describes how clients list, test and confirm upgrade images.
A normal trial sequence often looks like this in plain language: the old image is active and confirmed; a valid candidate is staged; the candidate is marked pending for test; the device restarts; the new image runs but remains unconfirmed; health checks are performed; the application or authorized operator confirms it; and a further controlled restart proves the confirmed version persists. If the image is not confirmed and the configured revert mechanism works, the next restart should restore the prior application.
Video: how MCUboot moves images
The following developer presentation explains the MCUboot swap-scratch algorithm. Nordic Semiconductor’s DFU curriculum links to this demonstration as background for how a bootloader preserves a prior image during a trial update. It is useful for understanding why storage layout and interrupted-swap recovery matter.
A technician does not need to redesign the swap engine, but must know which behavior the actual device uses. An interrupted transfer, failed signature check, failed image swap, application crash and successful revert are distinct failure states. Record the point of failure before deciding whether to retry an upgrade, revert using the supported mechanism, or escalate for engineering review.
How test, permanent and revert differ
Test: the next boot attempts the candidate application without immediately establishing it as the durable version. Under the configured rollback mechanism, a subsequent boot reverts unless the image is confirmed. Permanent: an update is selected for continuing use without the same unconfirmed trial window. Revert: MCUboot returns to a previously retained image after an unconfirmed test. These terms refer to MCUboot behavior; another bootloader may use different names and safeguards.
In Zephyr, boot_request_upgrade(BOOT_UPGRADE_TEST) requests a test upgrade when that API and configuration apply. The application may call boot_is_img_confirmed() to check current state and boot_write_img_confirmed() to mark the currently running image confirmed. These are application APIs, not commands for a technician to type into an arbitrary device. Field work should use the device’s supported management interface and approved release instructions.
Confirmation should follow meaningful application health checks—not merely the passage of a few milliseconds after reset. Tests might include critical peripheral initialization, expected service availability, application version, persistent configuration loading, network attachment, watchdog stability and any product-specific safety conditions. On a live or safety-critical system, testing and resets must occur only in an authorized maintenance environment or change window.
Video: the MCUboot swap-move process
The second developer presentation covers the swap-move approach, in which the bootloader uses a different flash movement strategy. Understanding this distinction prevents technicians from assuming that a scratch-area layout, memory-size limit or recovery procedure applies identically to every MCUboot build. This video is also referenced by Nordic’s firmware-update course.
The swap mechanism is relevant to recovery planning because some strategies require extra flash space, sufficient sector geometry or a particular placement of image trailers. Exact capacity and wear behavior depend on the selected algorithm and hardware. Read the actual flash partition map and build manifest; do not infer them from another development board.
Read-only verification before changing firmware
Before approving an update on a device, gather its model, hardware revision, bootloader version, active firmware version, candidate version, image hashes and available recovery interface. Record whether an earlier working image remains available and whether trial rollback is supported by the device’s current boot configuration. Consult firmware recovery basics and the flashing-interface lesson before using any programming port.
Use the authorized management console’s read-only image-list operation, when supported, to identify active, pending and confirmed states. Record the current application version and compare the device’s reported hardware ID with the release manifest. On supported MCUmgr-enabled targets, a client can retrieve image metadata without immediately altering image state. Do not press test, confirm, erase or reset while merely auditing an unknown production unit.
Testing the unconfirmed upgrade
In a dedicated test device or approved change window, the planned release process first uploads and verifies the candidate according to the product instructions, requests a trial boot and collects a timestamped startup record. Check the version reported by the application rather than relying only on the file name. Establish that critical functions operate normally and that the firmware has not already self-confirmed prematurely.
One important limitation is that a device which reboots because of a watchdog may revert automatically only if its update mechanism is designed and configured for that behavior. Some systems have no rollback state; others confirm immediately or use a different boot policy. The watchdog and reset-loop lesson shows why the reset reason must be captured along with the firmware version. A reboot alone is not evidence that a recovery mechanism was tested.
After health checks, the candidate can be confirmed by the approved mechanism. The technician then verifies that the reported state is confirmed and that the same version remains active through the specified follow-up restart. Record any abnormal device reboot, configuration reset, missing peripheral or change in version as a failure requiring diagnosis—not a success that can be dismissed because the flashing tool printed “done.”
Proving the rollback path
A controlled revert test belongs on a test bench or under an explicitly approved maintenance procedure. The negative test must avoid creating a safety hazard or disconnecting production services. In a compatible test configuration, a candidate is staged for trial, deliberately left unconfirmed under the prescribed test plan, and the device is reset to observe whether the expected prior image returns. Success requires proving the known-good version is active, the relevant functions work, and the event log records the expected sequence.
A failed revert may indicate a permanently selected image, invalid previous slot, corrupted trailer, unsupported boot mode, inadequate partition sizing or an unexpected reset path. Preserve the logs and build identifiers. Do not repeatedly issue recovery or erase commands on production equipment: escalation is preferable to destroying the last available image or configuration. Firmware Crash Logs and Fault Recovery gives the incident documentation needed when a rollback fails.
When serial recovery is different from automatic rollback
MCUboot serial recovery is a separate service mechanism: on supported builds, the bootloader enters a management mode and accepts a replacement image over an approved transport. It can help when the running application is unavailable, but it requires configuration and a physically or logically accessible entry path. Nordic’s serial-recovery documentation explains a device-specific workflow using MCUmgr. A technician must not assume an enabled recovery port, command set or image-slot mapping across different vendors.
Serial recovery is not proof that automatic rollback worked. A device requiring manual reflash after a bad candidate did not demonstrate an autonomous test-and-revert sequence. Both methods can be legitimate maintenance capabilities, but they have different recovery-time, operator-access and outage implications.
Worked example: a network sensor that fails its trial
A hypothetical field sensor is running version 1.8.2 with that image confirmed. A signed and compatible 1.9.0 candidate is uploaded into its secondary slot and selected for a test boot. The device starts 1.9.0 but loses its network interface during application initialization. The image remains unconfirmed. After an authorized reset, a correctly configured MCUboot swap-based rollback restores 1.8.2, and the sensor resumes reporting. The event log now contains evidence that the candidate booted, failed a service check and reverted.
The technician records the last successful boot stage, both image versions and hashes, swap/confirmation state before and after, reset cause, service failure and recovery confirmation. The result is a failed upgrade with successful rollback—not a successful release. If 1.9.0 was accidentally confirmed before the failure, this specific test might not revert as expected; the corrective action belongs to the product’s authorized recovery plan.
Service record and acceptance
A complete firmware maintenance handoff identifies the exact device and board revision; source and target versions; trusted release package and verification results; whether the update was test or permanent; image-state snapshots; critical health checks; reset history; successful or unsuccessful confirmation; and final operating version. Preserve raw logs with timestamps and note any recovery intervention. Do not write credentials, private signing keys or confidential device secrets into a broadly shared ticket.
The most useful technician question is not simply “Did the new firmware boot?” It is “Which image is active now, is that image confirmed, did the intended functions pass, and can the device recover according to its documented design?” The accompanying bootloader engineering lesson develops the architecture of A/B images and recovery, while OSFTC.014 concentrates on the operational evidence that makes a firmware service action auditable.
Knowledge check
What is the difference between a successfully verified image and an operationally healthy image? Why can a test upgrade revert after the next reboot? Which two checks distinguish a successful confirmation from a first successful boot? Why is recovery by manually uploading an image different from an automatic revert? What evidence would you preserve if a previously working application could not be restored?
Review: Cryptographic validation checks authenticity and integrity, not runtime health. A supported trial upgrade remains provisional until confirmation. Verify both image state and functional operation after a restart. Manual recovery requires an intervention, while automatic revert follows the configured boot-state mechanism. Preserve image identifiers, state flags, reset cause, logs, device details and the last known-good release.
References and further reading
Primary technical references include MCUboot design, Zephyr MCUboot image control, Zephyr MCUmgr SMP Server, Zephyr image-management states, Nordic Developer Academy on MCUboot and MCUmgr and Nordic serial recovery. Follow your actual product documentation and maintenance authorization before performing a firmware update.
BitcoinVersus.Tech
Read more at BitcoinVersus.Tech and follow the site’s technology reporting on X.
Editor’s Note: We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support our work and help further secure the integrity of our research initiatives, please scan the QR code below to donate 5,000 sats.
For best results, display the QR code on a laptop or larger screen and scan it with a compatible Bitcoin wallet on a second device. Confirm the destination address: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb.
BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.
Leave a Reply