What happens if power fails during a firmware update?

Download, write and activation are different stages

Receiving the entire file is not a successful remote update. The image must target the correct hardware, be written completely, become bootable through a consistent transition and perform the application's actual job. Power can fail during any stage. Engineering must define the known state from which the device resumes after each interruption. A download-complete message cannot answer that question, nor establish that a remotely reachable device is operational.

Erasing the only working image before writing its replacement is hazardous. If the memory layout permits no alternative, recovery access and residual risk need explicit treatment. A/B is not available on every device: boot capabilities, erase geometry and trust in external storage constrain the options. Firmware, electronics and power behavior must be designed together; modifying application software alone may not create a recoverable update path.

The A/B invariant: preserve a verified recovery path

In a conceptual A/B arrangement, one slot retains the working image and another receives a candidate. The candidate is not eligible to execute until verification completes. Direct execution, copying and swapping have different requirements. Two slots alone do not make activation atomic: the design must specify sector erasure, persistent state and which marker is authoritative after an interruption. Recovery depends on those transitions, not simply on the labels A and B.

MCUboot provides a concrete reference for image slots, trial activation and confirmation. The simplified model in this article is not equivalent to all of its algorithms. A chosen bootloader still needs hardware-port and configuration review. Treating flash as an ordinary linear file can hide erase-size, alignment and write-order hazards. Recovery logic must be tested with the actual driver and power behavior before its hardware properties are considered demonstrated.

Section references: MCUboot · Bootloader design ↗

Digest, signature and target compatibility are separate checks

A digest checks content against an expected value; if an attacker can replace that expected value, it does not authenticate the publisher. A signature depends on a trusted key and verification chain. Hardware revision, memory layout and dependencies need independent checks. An authentically signed image can still target the wrong board. Key protection and rotation are operational responsibilities that cannot be replaced by checking whether a signature field exists.

Rollback does not mean permitting every historical version. A security-blocked release must be distinguished from the last healthy version. Persistent security counters and related mechanisms depend on the hardware and boot design. Application rollback must not contradict the security-version policy. Accepted versions, publication authority and lost-key recovery belong in the plan alongside file transfer, because an otherwise recoverable device can still accept an unauthorized downgrade.

Capacity planning includes more than two images

Take a wholly hypothetical 2,048 KiB flash: reserve 128 KiB for the bootloader, two 768 KiB slots, 64 KiB for transition metadata and 128 KiB for configuration. That totals 1,856 KiB, leaving 192 KiB. This coarse budget does not validate a real layout. Erase alignment, headers, signatures, logs and algorithm-specific overhead still matter. These figures describe an example, not the memory specification of a Gokbilge device.

Adding a second slot later may be difficult as the application grows. Build-time size checks should reject an oversized image before distribution. Endurance and write frequency also matter: persisting state to the same sector on every boot can concentrate wear. Corrupted transition metadata is a different failure class from a corrupted application image. A memory budget therefore covers capacity, endurance and recovery instead of reserving only enough bytes for today's executable.

When should the new application confirm itself?

Executing the first instruction is not sufficient health evidence. Trial confirmation may require access to essential storage, valid configuration and a working local data path. Conditions follow product requirements. A temporarily unavailable external service should not necessarily trigger rollback, so local health and network availability are separated. Confirming too early can make a broken release permanent; confirming too late can cause unnecessary reversions of otherwise healthy firmware.

The executable example below is only a logical state model. A verified-download event assumes verification happened elsewhere; the code implements neither cryptography nor flash writes. Power loss is represented as an event that leaves persistent logical state unchanged, not a simulation of RAM and hardware. It checks reversion after an unconfirmed trial and persistence after confirmation. A real implementation still has to prove that its persistent transitions survive interrupted physical writes.

const assert = require('node:assert/strict');
// Logical state model only: no flash driver or cryptographic verification.
function initial() {
  return { confirmed: 'A', candidate: null, trialStarted: false };
}
function apply(state, event) {
  const next = structuredClone(state);
  if (event === 'verified-download') next.candidate = 'B';
  if (event === 'power-loss') return next;
  if (event === 'boot') {
    if (next.candidate && next.trialStarted) {
      next.candidate = null; next.trialStarted = false;
    } else if (next.candidate) next.trialStarted = true;
  }
  if (event === 'confirm') {
    assert(next.candidate && next.trialStarted);
    next.confirmed = next.candidate;
    next.candidate = null; next.trialStarted = false;
  }
  return next;
}
let state = initial();
state = apply(state, 'power-loss');
assert.equal(state.confirmed, 'A');
state = apply(state, 'verified-download');
state = apply(state, 'boot');
state = apply(state, 'power-loss');
state = apply(state, 'boot');
assert.equal(state.confirmed, 'A');
assert.equal(state.candidate, null);
state = apply(state, 'verified-download');
state = apply(state, 'boot');
state = apply(state, 'confirm');
assert.equal(state.confirmed, 'B');
assert.throws(() => apply(initial(), 'confirm'));
const requiredKiB = 128 + 2 * 768 + 64 + 128;
assert.equal(requiredKiB, 1856);
assert.equal(2048 - requiredKiB, 192);
console.log('Trial, rollback and capacity examples pass');

Can configuration survive a firmware rollback?

If a new application irreversibly migrates configuration, the old image may boot but be unable to operate. Schema versions and migration strategy need explicit design. Options include preserving an old-readable copy or making compatible additions. Recovery defines a consistent combination of firmware, configuration and calibration. Replacing calibration with defaults may restore execution while invalidating measurement, so it cannot automatically count as a successful recovery.

Servers must tolerate a period with both old and new device versions. Command and record-schema changes need a compatibility window. Assuming simultaneous fleet upgrades can strand an offline unit when it reconnects. Desired version, actual running version and confirmation status are separate fields. A single up-to-date indicator cannot explain incomplete downloads, failed trials, deliberate holds or a recovered device still operating on its previous release.

Power-interruption testing needs a coverage plan

Tests target download, erase, write, transition metadata, first boot and confirmation boundaries. They record interruption duration and power restoration. Repeated trials at a vulnerable boundary can expose an intermittent inconsistency. A voltage dip can differ from complete power loss, so reset and brownout behavior matter. Evidence is tied to hardware revision and boot configuration and cannot simply be transferred to a different board or flash device.

After each interruption, checks cover image identity and data consistency, not boot success alone. Recovery should preserve device identity and required measurements. Failed recoveries remain visible even after a later pass. Acceptance reports state tested boundaries and repetitions. Observing no failures does not guarantee perfect updates under every untested electrical condition; remaining limitations and any required service recovery must be documented explicitly.

• Do interruptions preserve a working image and consistent transition state?
• Do confirmation conditions measure actual local functionality?
• Are configuration and calibration compatible with rollback?
• Were interruption tests performed on the actual board and flash?

Develop embedded software with board and operational knowledge

Gokbilge Tech considers embedded software alongside electronics, verification and the system lifecycle. Local board and firmware knowledge connects memory selection, power behavior, programming access and maintenance. That engineering contribution remains meaningful when the system uses globally sourced components. Adopting a particular bootloader does not automatically confer security certification, guarantee recovery from every failure or establish a specific device's production readiness.

An assessment can review board revision, memory map, update transport, communications and available service recovery. It can then define a feasible state model, image-acceptance rules and interruption experiments. This article does not claim that any current product already implements A/B updates. It explains how embedded-systems work can be scoped around concrete risks and verifiable acceptance evidence instead of a generic promise of remote updating.