Prototyping · Study deck
Safe Over-the-Air Updates
Picture a weather sensor already fixed to a roof.
Voltage Vera is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Treat OTA as a controlled update path rather than a single firmware feature.
- Define update package records with version, target, compatibility, integrity, authenticity, and rollback expectations.
- Separate build, signing, distribution, rollout policy, device agent, health checks, and telemetry responsibilities.
- Plan staged rollout gates and handoff records that make a prototype update safe to repeat.
Major section
In 60 Seconds · Start With the Story
A bug must be repaired without taking the device down.
- An over-the-air update is a software change sent through a network.
- Firmware means the software stored inside the device.
- Every path needs a clear recovery state.
- The device starts on a known good image.
Major section
OTA as Controlled Device Path · Confirm Health Before Success
An OTA system is safe only when the team can control which package reaches which device and can prove what happened after installation.
- The download is only one step in that path.
- Reboot is not confirmation.
- Expansion depends on health, rollback, crash, battery, and support evidence at each gate.
Major section
Rollback Is Update Logic
Rollback must be designed into the update state machine.
- OTA evidence should make those partial failures visible before the rollout reaches the whole fleet.
- Under the hood, the update agent needs persistent state that survives reboot.
- If power fails during a write, the bootloader and agent should know whether to resume, reject, or keep the previous image.
Major section
Rollback Is Update Logic (continued)
The device update agent should check those facts before staging the package.
- It should record attempted package id, previous version, candidate version, slot or partition, verification result, reboot reason, health-check status, confirmation state, retry count, and rollback reason.
- Compatibility is also a firmware boundary.
- That bootloader selects and starts an application.
Major section
Rollback Is Update Logic (continued)
If the new image boots but never confirms health, the boot path should return to known-good behavior or hold the device in a controlled recovery state.
- A package built for a larger flash layout, different sensor board, changed calibration schema, incompatible radio stack, or new storage migration can boot and still be wrong for a device.
- The update record should state target product, hardware revision, current-version range, bootloader or partition scheme, configuration migration, and minimum power or storage conditions.
- A rollout dashboard or simple review table should distinguish rejected, downloaded, verified, staged, booted, confirmed, retried, rolled back, missing, and unresolved devices.
Major section
Rollback Is Update Logic (continued)
Without those states, a fleet can look quiet while some devices are stuck in retry loops, have reverted to an old image, or stopped reporting during a weak-network update window.
- On an ESP32-C3, a first-stage bootloader in ROM runs first and loads a second-stage bootloader from flash.
- During ESP-IDF app OTA, the running application writes a new image to an inactive app partition; the bootloader selects it on a later boot.
- A device in that state is unrecoverable over the air, and lost outright if it is physically inaccessible.
- Two established OTA architectures make different trade-offs with this risk.
Major section
OTA System Boundaries
A reviewable prototype names each boundary and records which evidence it owns.
- The build record binds source, target, and package; signing or approval establishes the trust decision.
- Distribution keeps the package available, while rollout policy chooses target devices and pause or abort gates.
- the OTA system boundaries diagram separates build identity, trust, rollout policy, and device health.
- A download log alone cannot prove that the right device received a trusted image or that local sensing recovered after reboot, so retain evidence across all six stages.
Major section
Prototype the Record Before the Platform · Package and Compatibility Records · Update Safety Controls
The prototype can start with a simple update server or local fixture, but the record should already name the package, target devices, expected safety controls, and health signals.
- Every update needs a package record that can be checked by both people and devices.
- That prevents the demo path from becoming an unreviewed production path.
- The record does not have to use a specific platform format, but it should make compatibility and rejection rules explicit.
- Safety controls make a bad update detectable and recoverable.
Major section
Do Not Hide Keys or Secrets in Firmware · Device Update State Machine
Public verification material can live on the device; private signing material should not.
- OTA failure handling is easier to review when the device has explicit update states.
- The state machine should make rejection and recovery as visible as success.
- Idle means the device is still running its current image.
Major section
Health Checks and Rollback Evidence
A health check is not "the device turned on." It is a small, targeted proof that the update did not break the prototype's essential behavior.
- Boot and scheduler: The system starts, exits recovery mode, initializes expected tasks, and does not immediately reset.
- Sensor and actuator boundary: Required hardware initializes, missing hardware becomes a visible fault, and safety states remain local.
- Configuration compatibility: Existing settings, calibration, credentials, and local records are readable or migrated deliberately.
Major section
Health Checks and Rollback Evidence (continued)
Communication path: The device can reach the required local gateway or service, report version, and publish health without blocking control.
- Storage and queue behavior: Queues, logs, and retained records survive the update or are migrated according to the record.
- Rollback evidence should record the failed check, previous version, attempted package, device state, and whether the device returned to service.
- A rollback without a reason is hard to distinguish from an ordinary reboot.
Major section
Rollout Gates · Make the Abort Path Ordinary
Rollout is a decision process, not a single button.
- Each gate should have a small enough blast radius that the team can learn, pause, and recover.
- Lab rigs come first, then staff devices, a pilot batch, and wider use.
- Each group supplies proof for install, boot, health, app use, and recovery before risk grows.
Major section
Cold-Room OTA Review
A team is preparing an update for a cold-room monitor prototype.
- The update changes retry behavior after gateway loss and adds a compact post-reset fault record.
- Interrupted download: Drops network during download and confirms sensing continues, retry state is visible, and the current image stays valid.
- The package is allowed into a canary batch only after the team can reproduce both a successful confirmation and a forced rollback.
Major section
Match OTA Record to Purpose · Order the OTA Review · Common Failure Patterns
Package target is vague: The update record does not name product, board revision, boot layout, configuration, or current-version range.
- Devices can accept an unsafe build.
- Health check is too shallow: The device confirms an update after boot, even though sensing, storage, gateway reporting, sleep, or local control has failed.
- Rollout has no stop rule: The team notices failures only after broad exposure because pause, abort, and retry criteria were not defined before rollout.
- Telemetry cannot explain failures: The fleet reports "update failed" without package id, state, reason, previous version, power context, or last successful checkpoint.
Deck summary
Key takeaways
A bug must be repaired without taking the device down.
- An OTA system is safe only when the team can control which package reaches which device and can prove what happened after installation.
- Rollback must be designed into the update state machine.
- The device update agent should check those facts before staging the package.
- If the new image boots but never confirms health, the boot path should return to known-good behavior or hold the device in a controlled recovery state.
Retrieval practice
Recall check 1 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q1Per this chapter's canary-batch rollout gate, what should cause the gate to pause rather than continue?
Show answer
Answer: D The chapter states: 'A canary batch might continue only if devices report package id, new version, successful sensor read, queue recovery, gateway publish, stable reset count, and battery or power state within the expected window.
Retrieval practice
Recall check 2 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q2Per this chapter's 'Rollback Is Update Logic' section, why can a firmware package pass boot and still be the wrong update for a device?
Show answer
Answer: B The chapter states: 'Compatibility is also a firmware boundary.
Retrieval practice
Recall check 3 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q3Per this chapter's OTA system boundaries, which boundary owns 'targeting, batches, pause and abort criteria, retry windows, operator approvals, and emergency rollback authority'?
Show answer
Answer: A see answers page
Retrieval practice
Recall check 4 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q4A prototype can download a new firmware image and reboot, but the team has not tested incompatible packages, interrupted downloads, post-update health checks, or rollback. What is the best next review action?
Show answer
Answer: C OTA evidence includes package identity, eligibility, verification, safe staging, health confirmation, rollback, and rollout status summaries.
Print reference
Answers 1 of 2
Answer key.
- D · It should pause if missing reports, repeated retries, unexpected resets, rollback reasons, or support tickets cross the threshold.
- B · A package built for a larger flash layout, different sensor board, changed calibration schema, incompatible radio stack, or new storage migration can boot and still be wrong for a device.
Print reference
Answers 2 of 2
Answer key.
- A · The chapter's OTA system boundaries list 'Rollout policy' as: 'Owns targeting, batches, pause and abort criteria, retry windows, operator approvals, and emergency rollback authority.' It is distinct from the device update agent, which executes eligibility, download, and rollback rather than setting the policy for them.
- C · OTA evidence includes package identity, eligibility, verification, safe staging, health confirmation, rollback, and rollout status summaries.