Guide
Design the Update Path First and Every Later Firmware Release Is Safer to Ship
The update mechanism is the one part of a connected product that cannot repair itself. We design it to survive power loss and a bad image, with your engineers reviewing every step.
4-minute read5 November 2026
In Brief
- A device that loses power while writing its flash may need a technician or a return, so a bad update costs far more than a bad web release and cannot be rolled back from a console.
- We see four actions: write the update path first, keep a first stage that cannot be overwritten, let a new image prove itself on trial, and run rollouts in small cohorts.
- Thinqmesh engineers join your team and repositories, review the architecture and pipeline, and ship a first feature with your engineers within four weeks.
A firmware update is the one software release that can disable the product it was meant to improve. A web service that takes a bad release can be rolled back from a console. A device that loses power while writing its flash may need a technician. Many hardware teams still treat the update mechanism as a feature to finish shortly before launch. We take the opposite view: it is the first firmware written and the last to change, because it is the only route by which the product can be repaired in the field.
The Update Path Has to Survive the Worst Day
A sound design keeps a small first stage that cannot be overwritten in the field, writes new images to an inactive slot, and lets a new image prove its own health before the old one is retired. A power cut, a dropped link or a battery that fails early should each leave the device able to boot.
Safety and security meet at rollback. Falling back while a new image is on trial should be automatic. Once the image has proved itself, the version floor moves up, and going below it needs explicit authorisation. Teams that settle this while the memory map is still open avoid the returns and site visits that follow a bad release.
Four Actions That Make an Update Safe to Ship
The first two are settled while the memory map is still open, so they cost far less before the first unit leaves the factory.
Keep a First Stage That Cannot Be Overwritten
A small boot stage that the field cannot change verifies whatever runs next, and it should do very little.
A defect in this stage lives for the life of the product, so its job is limited to checking the signature of the next image and starting it. We agree what it contains with your engineers, review it line by line and test it on real units before anything else is built on top.
Get started
- Write down what your current boot stage does beyond verifying and starting the next image.
- Check whether any field update can overwrite it.
Write New Images to an Inactive Slot
The running image is never the one being overwritten, and the device switches only after the complete new image has been verified.
A power cut, a dropped link or a battery that fails sooner than its gauge predicted should each leave the device able to boot. We lay out the memory map for two slots, test interrupted writes at every stage, and record what the device does after each interruption.
Get started
- Draw your flash layout and mark where a second image would fit.
- Interrupt a test update at five different points and note what boots.
Let a New Image Prove Itself on Trial
A new image starts on probation and must confirm that it can reach its network, read its sensors and accept the next update.
If it fails within a set number of attempts, the boot stage returns to the previous image, and the fleet records that it happened. Once the new image has confirmed its health, the version floor moves up, and going below it needs explicit authorisation. Stored data is migrated only after the trial has ended.
Get started
- Define the three checks a healthy image must pass.
- Decide how many failed attempts trigger a return to the previous image.
Roll Out in Small Cohorts, With a Written Stop Condition
Signing keys, build coverage and rollout rules belong to operations, and they decide whether a sound design stays sound.
Keep signing keys in a hardware security module with a rehearsed rotation plan, build for every hardware revision still in the field, and test on real units of each. Release to a small cohort first, with an agreed fallback rate that halts distribution without anyone convening a meeting.
Get started
- List the hardware revisions in the field and the units you test on.
- Write the fallback rate that would halt a rollout.
How Thinqmesh Solves This
Our engineers work in your repositories and to your standards, on a defined piece of your roadmap, with the exit planned from the start. The full engagement runs to eight weeks.
- Week 1
Architecture and Pipeline Review
We assess the architecture, the delivery pipeline and the quality of the product, starting with the boot stage and the update path.
- Week 2
Working With Your Team
Our engineers join your planning and your repositories, and agree how firmware changes are reviewed and released.
- Week 3
Quality and Release
The tests and release steps the first feature depends on are put in place before it is built on further, including interrupted-update tests.
- Week 4
First Feature Shipped
Your first feature ships with our team, and the review's findings set the plan for the remaining weeks.
You finish with a first feature shipped, automated tests and deployment for what we built, and documentation reviewed by your engineers. The code is in your repositories and you can continue without us.
