The gap between “it compiles” and “it works”
A firmware build that compiles without errors has passed exactly one check: the syntax is valid and the toolchain could produce a binary. It has not confirmed that the binary does what the engineer intended once it’s running on the actual chip. That second confirmation, real hardware verification, is a separate step, and skipping it is one of the most common reasons firmware bring-up takes longer than expected.
Why compiling isn’t enough
Most of the bugs that show up during bring-up aren’t syntax errors. They’re the kind of problem a compiler has no way to catch:
- Register initialization order. Some peripherals only behave correctly if registers are configured in a specific sequence. Code can be syntactically correct and still misconfigure the peripheral if that order is wrong.
- Errata-triggered failures. Silicon revisions frequently ship with known hardware bugs, documented in errata sheets, that have nothing to do with how the code is written. Code that ignores a documented errata can compile perfectly and still fail on the actual part.
- Timing and electrical behavior. Bus timing, clock configuration, and pin-level signal behavior are physical properties of the board. Static analysis of source code can’t reveal whether a UART line is actually toggling at the expected voltage and frequency.
- Peripheral state that only exists on the real part. A simulator can model a chip’s documented behavior. It generally can’t model every undocumented quirk of the specific revision on the bench, which is exactly what errata sheets exist to capture.
None of these show up in a build log. They show up when the firmware is actually flashed and run.
What real hardware verification actually checks
Real hardware verification means connecting to the physical board, running the firmware, and reading back what the board actually reports, not what the code was expected to do. For Linux-capable targets, that connection is typically SSH, which allows checking whether a driver loaded, whether a service started, or whether a test binary returns the expected result. For MCU-class targets without a Linux userspace, that connection is UART, reading the firmware’s log output directly off the serial line.
The important distinction is between three states that are easy to conflate: the code compiles, the firmware flashes onto the board, and the firmware runs correctly. Each is a separate gate. Passing the first two says nothing about the third.
Why this is where AI coding tools tend to stop
A general-purpose coding assistant can generate firmware source code and confirm it compiles. Getting from there to a binary running correctly on physical silicon requires connecting to hardware, reading real output, and interpreting failures well enough to fix them, which is a different problem than generating code. This is the layer most AI coding tools don’t reach, not because the code generation is weak, but because closing the loop against real hardware is a separate capability, not a byproduct of a smarter model.
What happens when verification fails
A meaningful verification step has to do more than report pass or fail. When a check fails, the useful information is what the board actually returned: a log line, a missing device, a driver that didn’t load, and using that specific output to make a targeted correction rather than regenerating the code from scratch. Verification that only reports success or failure without preserving that output isn’t giving an engineer, or an automated system, enough to act on.
The takeaway
Compiling is a necessary step in firmware development. It is not the step that confirms the firmware works. Real hardware verification is what closes that gap, and it’s the difference between “the code looks right” and “the code is proven right, on the board that will actually ship.”