A firmware engineer returning to a board after a day away rarely starts with a blank editor. They start by rebuilding state: which image is on the board, which configuration was last known good, which errata workaround applies, and which experiment failed yesterday and why.
This article is about that rebuilding cost. It asks a different question from a stage-by-stage view of iteration: what does the next session have to re-learn?
The framing below is interpretation. We have not measured how much of a session goes to state reconstruction. You can check it against your own sessions.
State is the part that does not persist
Source code persists in version control. Much of what makes a firmware session productive does not. A board holds whatever image was last flashed, which may not match the repository. Serial console history scrolls away. The SDK patch level, the pin mux change that was tried, and the workaround applied for a silicon errata are often recorded only in someone’s memory or a chat log.
Four kinds of state that get lost
- Hardware state: the bootloader, image, and configuration actually running on the board.
- Environment state: the toolchain version, SDK revision, and build flags that produced the last working binary.
- Knowledge state: the datasheet section, errata item, or vendor note that the current change depends on.
- Experiment state: what was tried yesterday, what failed, and what was ruled out.
Each item is cheap to recreate alone. Together, they make the first hour of a session expensive.
Why the cost is easy to miss
Each reconstruction step is short. Reading the last log, checking the board, and rereading an errata entry do not look like large tasks. Because the work happens at the start of a session and spreads across several tools, it is often counted as ordinary setup rather than as lost time.
The cost recurs every session. It is likely to grow when a project spans several boards or several engineers touch the same platform, although we have not measured that.
The figure shows the sequence most sessions go through before the first productive change. The steps are ordered, not scaled to time.
Where the state should live
Teams can reduce restart cost by attaching state to the work: a recorded flash history for each board, build identifiers that map a binary to its toolchain and source revision, and a short log of rejected changes linked to the commits they affected. The goal is not documentation for its own sake. It is making the starting point of the next session readable by a tool or a colleague without asking anyone.
Questions to check against your own work
- Can you tell which image is running on each board without checking it physically?
- Can you rebuild the last working binary from its recorded toolchain and source revision?
- Is the reason a change was rejected recorded where a colleague could find it?
- Which errata or vendor notes does the current change depend on, and where are they recorded?
Where automation fits
FWAuto runs builds and checks over SSH or UART and returns the results to the workflow, which covers part of this state. Engineers still decide what the state means, including whether a failed experiment should be retried. For how this relates to hardware verification, see [INTERNAL LINK: Real Hardware Verification article].