Firmware debugging from evidence

• Construct a minimal reproducible firmware test, classify the failing layer, and use logs, assertions, and controlled substitutions to isolate one cause.

• programming-state
• communications-protocols
• experimental-method

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.

Problem

A 50 Hz sampling loop reports gaps. Logged timestamps are 0, 20, 40, 60, 140, 160 ms, and a bus-error counter rises at 60 ms. What can the trace establish?

Steps

1. Nominal interval is 1/50 s = 20 ms; the first three intervals match it.
2. The 60→140 ms interval is 80 ms, so three expected sample instants at 80, 100, and 120 ms are absent.
3. The bus-error counter provides correlation at the last normal timestamp, but does not alone prove the bus error caused the 80 ms gap.
4. Next isolate by substituting a fixed sample or adding start/end timestamps around the bounded bus call.

Result

The evidence confirms a single 80 ms scheduling gap and three missing nominal samples; it narrows the next test to the acquisition path without yet proving causation.

Sanity check

From 0 through 160 ms inclusive, a 20 ms grid has nine instants; the trace has six entries, exactly three fewer.

A robot resets only when the motor starts. Which first experiment best separates power integrity from motion-software logic?

A. Rewrite the entire state machine and increase every delay B. Run the same motor command with the mechanical load safely removed while logging reset cause and supply minimum, then compare with a no-motor dummy path C. Delete error handling so the reset is less visible D. Assume the motor driver is defective because resets correlate with motion

Your answer: ______________________________

Reasoning:

Goal

Diagnose a seeded firmware fault using a hypothesis table and boundary logs.

Equipment

• Microcontroller
• known low-voltage sensor or potentiometer
• serial console
• multimeter
• notebook or issue template

Procedure

1. Create a baseline program that samples at 10 Hz, range-checks the value, and prints sequence, timestamp, raw count, converted value, and error code.
2. Record firmware identifier, wiring, starting input, expected cadence, and actual baseline for 30 samples.
3. Introduce one deliberate fault: use the wrong reference value in conversion without changing acquisition.
4. List predictions for ADC/wiring, conversion, and scheduler hypotheses; compare raw counts and meter voltage to localize the mismatch.
5. Restore the reference, rerun the identical case, and retain before/after evidence plus one assertion that would catch recurrence.

What to observe

• Expected: the seeded conversion fault changes engineering units while raw counts and cadence remain comparable.
• Record actual raw counts, meter readings, timestamps, and converted values; label the nominal 10 Hz cadence as expected until measured.
• Expected diagnostic: stable raw evidence with systematically scaled output points to conversion rather than the electrical input.

Transfer challenge

Create a five-check fault-isolation plan for a small printer mechanism that homes correctly but stops accepting motion commands, without opening or probing any mains-powered section.

Cautions

• Seed only reversible software or low-voltage signal faults; never create shorts, defeat protection, stall a motor, or work inside energized appliances.

Learner: ____________________ Date: ____________________

Evidence artifact or file: ____________________________________________

Notes: