Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Every way an over-the-air update can fail

Interrupted, broken, malicious, incompatible with stored data, bad across the fleet, or failing with no evidence. Each failure has its own defence, and an update system needs them all.

Name the failure, then reach for its defence. None of them replaces another.

  • The download or the write is interrupted (power cut, lost link) → A/B app slots, so the running image is never overwritten, and atomic writes for anything stored.
  • The new image is broken (it crashes, hangs, or can't connect) → a trial boot with a health gate and a deadline, and the watchdog; the bootloader rolls back.
  • The image is malicious or old → a signature checked before it's accepted, and an anti-rollback counter against downgrades.
  • The image is fine but its data isn't (settings or messages in a new shape) → numbered settings migrations and expand-and-contract, so a rollback still finds what it needs.
  • It works on the bench and fails on 10 % of the fleet → a staged rollout with halt conditions written in advance.
  • It fails and you can't tell why → crash reports, breadcrumbs and the version in every status message.

The whole picture

The failure list this cluster organises.

Term

bricked

See section →
A device with no program it can boot and no way to fix it remotely.

Interrupted mid-update

Term

A/B update

See section →
Keeping two app slots and always writing the update into the one that isn't running.

Term

torn write

See section →
A write cut off by a power loss, leaving neither the old nor the new data.
See section →
Writing a new copy elsewhere, then switching one small pointer, so data is either all old or all new.

A broken image

The image proves itself before it's kept; the core's default marks it valid before setup().

Term

trial boot

See section →
A new image's first run, on probation until it marks itself valid.
See section →
The checks, with a deadline, a new image must pass before it is marked valid.

Term

rollback

See section →
Going back to the previous working firmware when a new one fails.

A malicious or outdated image

See section →
Tricking a device into installing an older, genuinely signed release that has a known hole.
See section →
A number burned into eFuse that only goes up; images older than it won't boot.

Data the new image can't share

See section →
A numbered step that converts stored settings to the next version's format.
See section →
Add the new setting first and remove the old one only in a later release.

Bad across the fleet

Section

Staged rollouts

Four clean canaries pass a bug that breaks 1 device in 10 two times in three.

See section →
Sending a change to a few devices first and only to the rest if those stay healthy.
See section →
A rule written in advance that stops a rollout when too many devices fail.

Failing with no evidence

See section →
A message sent at boot describing why the device last restarted.

Term

breadcrumb

See section →
A small marker in memory that survives a crash and says what the program was doing.

The version in the image and in every status message, so "which version is it running?" has an answer.