The challenge
A Wi-Fi controller could accept an update command, but the actual firmware download failed. Limited memory, competing network services, and update-partition selection made this a whole-system problem. A successful command response did not mean the device had successfully updated.
The engineering
- Designed bounded downloads with validated byte ranges and transfer offsets, so the device did not need to hold a complete image in memory.
- Staged the signed image in the correct external-flash update partition and connected the flow to the bootloader.
- Coordinated network-service ownership during the update to avoid retaining competing TLS and socket resources.
- Aligned retry, watchdog, and persistent-state behavior with the real network and boot process.
What was verified
A recorded physical-board test downloaded and staged the image, recovered from server connection closures without restarting the download, completed the bootloader installation, and booted the new firmware. The device then restored its saved state and rejoined Wi-Fi.
This describes the recorded hardware validation, not a guarantee against every power-loss condition or a claim about long-term fleet availability. Each product needs its own interruption, rollback, and release acceptance checks.
The takeaway
An OTA feature is complete only when the device runs the intended image and recovers its useful state. Measure the whole update lifecycle, including the handoff between the application, storage, transport, and bootloader.
This anonymized example draws on prior engineering work to illustrate our technical approach. It is not presented as a Tethrio Technologies client engagement.