Blog · August 7, 2026
When the firmware update breaks off mid-transfer
We have built firmware updates into the field twice — in series production over cellular, and in clinical use via a dedicated base station. The most important design question was the same both times, and it sounds pessimistic: what happens when the transfer breaks off halfway?
The abort is the normal case, not the exception
A battery-powered device in the field updates itself under conditions no desk test reproduces: the device sits at the edge of the cell, the connection changes cells mid-transfer, the battery is half empty and sags under the transmit load, or somebody simply switches the device off — it is theirs, after all. Across a fleet in the field, the question is not whether this happens during an update, but how often. An update path that treats the abort as an edge case will sooner or later hand out devices that no longer start — and every one of them is then a service case at the customer's site.
The three questions the update path must answer
1. Does the device keep running after every conceivable abort? The iron rule: the old, working state is only given up once the new one has arrived completely and passed its checks. A firmware that overwrites itself in place becomes a paperweight at the first power loss in the wrong moment — receiving belongs separated from activating.
2. How does the device know the image is genuine and complete? Arrived does not mean sound. Before activating, the device checks: is the image complete, is it intact — and does it come from us? In the series device, the unit verifies the signature before it installs; an update path without that check is a vulnerability in itself, because it will install anything from anyone who can imitate the transfer.
3. How does it continue after the abort — without a technician? After the drop, the device reports back at the next contact and picks up again — in our series device not from the beginning, but at the last complete block. That saves data volume and energy, and it spends the time windows in which the device has reception on the blocks that are still missing — instead of wasting them on blocks already transferred. What matters in the end: no state may exist from which only a service visit or a return shipment leads out. That is what the update path is built for in the first place.
What this additionally means for battery devices
A firmware update is the most expensive radio operation in the life of a battery device: it is orders of magnitude more data than a measurement report. So the image comes in blocks, the transfer is charged against the energy budget like any other radio time — and the moment wants choosing: a device whose battery is running low is the wrong candidate for the next rollout.
And in your case?
Does your device in the field have an update path — and do you know what it does when the connection drops at eighty per cent? Write to us — we are curious how your devices get new firmware today: over the air, through a service port in the field, or not at all.
Transparency note: This article was written with the help of artificial intelligence and reviewed by the author before publication. The review applies to the German original; this English version is a translation.