Firmware debugging from evidence

Debugging is the work of shrinking uncertainty. When a sensor-driven screen freezes, “the firmware is broken” is too broad to test. Divide the system into claims: power is present, the loop still advances, bus transactions complete, received bytes pass validation, converted values stay in range, and display updates occur. Add observations at boundaries until one claim first stops being true.

A reproducible case specifies initial state, inputs, software version, timing, and expected versus actual behavior. A timestamped structured log can record event, state, and key values, but logging changes timing and finite buffers overflow. Assertions turn assumptions into visible failures: length <= 16, state is valid, sample interval is positive. In deployed builds an assertion policy must lead to a defined safe response and retained reset cause, not an uncontrolled motor state.

Controlled substitution is powerful. Replace a live sensor with a fixed known value to test the display path; replace the display update with a serial print to test acquisition. Change one factor and predict what each hypothesis says. If fixed data still freezes the display, the sensor is less likely to be causal. This is a build decision about diagnostic seams: preserving a raw-message counter, last-error code, and firmware version may cost a few bytes but saves hours.

A common misconception is that the last line printed caused the crash. It only proves execution reached approximately that point, and buffered output may lag. Another failure is “shotgun debugging”: changing timing, wiring, and parsing together, then accepting a disappearance as proof. Heisenbugs can move when logging changes load. Keep a baseline, capture exact changes, and restore variables. Distinguish compile errors, startup/reset faults, timing failures, electrical faults, corrupt data, and incorrect requirements before choosing an instrument.