EDUCATION
Ask someone outside the field what firmware development looks like, and they’ll usually picture writing C, poking registers, and flashing a board. Engineers who’ve actually shipped firmware know better: writing code is a small slice of the job.
What actually determines whether a firmware project ships on time is everything around the code — reading requirements correctly, working through a few hundred pages of datasheet, and eventually proving the result on real hardware.
That end-to-end path is what we call Firmware Workflow.
01 Defining Firmware Workflow
Firmware Workflow is the full sequence an engineer moves through — often non-linearly, with loops back — to take a chip or a board from requirement to working product:
Coding is one stage out of ten. The other nine determine whether what gets written there actually works.
02 What each stage actually involves
Requirements Scope the task: which peripheral, which power mode, which protocol. Without a clear boundary here, every downstream step risks solving the wrong problem.
Datasheet Register maps, clock trees, and power domains live in documents that can run several hundred pages. Engineers need to extract the relevant subset and correctly understand the timing and dependencies between registers.
SDK Vendor SDKs ship with ready-made drivers and examples — but those examples are usually written for a specific board revision or use case. Deciding what’s reusable and what needs modification is its own skill.
Errata Errata are the defects a chip vendor publicly acknowledges. The same register described in the reference manual can behave differently on a specific silicon revision. Ignore errata, and code that looks correct on paper can still fail on a particular board batch.
Coding This is where the previous four stages converge into an actual driver or application logic — the stage most often mistaken for the entirety of firmware development.
Build Compiling across toolchains, resolving dependencies and linker scripts. Firmware build environments tend to be more fragmented than typical software stacks; a minor toolchain version difference can change behavior.
Flash Writing the build to physical memory. This is where code leaves the simulated world and enters the physical one.
Debug Tracing the real cause of a failure — which might be a timing issue three layers removed from its symptom, or an undocumented register behavior, uncovered with a logic analyzer, JTAG, or UART logs.
Validation Confirming the result meets spec, and confirming it repeatably on real hardware — not just that it happened to work once.
Deployment Producing a stable, traceable, maintainable release for the next stage of the pipeline.
03 Why Firmware Workflow is harder than a typical software workflow
Most software engineering rests on one assumption: code that runs in a dev environment will behave roughly the same in production. Firmware doesn’t get to make that assumption.
This is also why “an AI can write a UART driver” and “this driver runs reliably on this specific board” are separated by a distance nobody has fully automated yet.
04 Why Firmware Workflow has never been fully automated
It isn’t for lack of trying. Every stage is tied to a physical constraint:
- Physical world — the final result has to be verified on real hardware; simulation alone can’t substitute.
- Hardware diversity — the same MCU can behave differently across revisions and board layouts.
- Vendor SDK fragmentation — SDK structure, documentation quality, and update cadence vary by vendor.
- Toolchain fragmentation — cross-architecture, cross-vendor build environments resist standardization.
- Verification requires judgment — reading signals, logs, and register state usually still requires engineering experience.
Most past automation attempts focused on speeding up coding — the one stage out of ten — without touching the other nine. That’s a large part of why Firmware Workflow has stayed manual for this long.
05 What’s next: AI doing more than writing code
Over the past couple of years, AI’s progress on code generation has been visible — it can produce a compiling driver or init sequence quickly. But “can write it” and “can complete a firmware task” are separated by build, flash, debug, and validation — stages that live in the physical world.
The relevant question going forward isn’t whether AI can write code. It’s whether AI can carry a task through the entire workflow and produce verification evidence from real hardware. That’s also why Firmware Workflow is worth naming and discussing on its own terms — it was never a single step, but a full chain from requirement to production.
That’s the problem FWAuto is built around: connecting every stage of Firmware Workflow — research, implementation, build, flash, verification, and repair — into a single loop that closes on evidence from real hardware.