PE1-4.5 Debugging Techniques & Applications

What this is and why it exists

Something does not work. That is the normal state of an embedded project, and the difference between a frustrating afternoon and a productive one is method.

The most useful fact in this topic is this. Most embedded faults are hardware. A loose wire, a missing common ground, a supply that sags when the motor starts. So the first move is to check the physical layer, not to re-read the code.

The vocabulary

• Physical layer — the wires, connectors, supply and ground, before any code is involved.
• Common ground — a shared zero-volt reference between two connected devices.
• Supply sag — the voltage dropping when something suddenly draws a lot of current.
• Isolating — testing one part on its own before combining it with the rest.
• Halving the problem — removing half the system to find which half holds the fault.
• Known-good test — running something you are certain works, to prove the equipment does.
• Intermittent fault — one that appears and disappears, usually mechanical.

The mental model

Start with the board itself. Before suspecting your program, prove the board runs. Upload the simplest program that blinks a light and watch it blink. That single test proves the board is powered, the connection works, the environment compiles, the upload succeeds and the chip runs. If it fails, none of your own code was ever the problem.

The environment has its own failure modes, and they are numerous and mostly dull. The wrong port selected. A missing driver. Another program holding the connection. The wrong board chosen in the menu. Having the list is worth more than understanding any one item on it, because each has an obvious fix once recognised.

Then the method, which is the most transferable thing in this whole course.

Isolate before you combine. Prove the board runs. Prove the sensor reads on its own. Prove the display works on its own. Then put two together and test. Then three. When something breaks, you know which addition broke it. A project assembled all at once and then debugged is a much harder problem than the same project assembled in steps.

Halve the problem when isolation is not obvious. Disconnect half the system and see whether the symptom persists. Whichever half still shows it holds the fault. Repeat. A handful of halvings finds a fault in a system that would take many hours to read through.

Separate hardware from software deliberately. Print a value to the serial monitor at the point you doubt. If the value is right and the behaviour is wrong, the fault is after that point, probably in hardware. If the value is already wrong, the fault is before it, probably in code. That one habit divides most problems in half immediately.

Three hardware faults account for a large share of the trouble. A wire that looks connected and is not, which shows as an intermittent fault. Two devices with no shared ground, so their signals have no common reference and readings are nonsense. And a supply that cannot deliver what a motor demands at the instant it starts. The board resets, and the symptom is a program that restarts for no visible reason.

The applications close the course, and they are best read as project templates. Agriculture uses the same sensors as the interfacing topic, measuring soil moisture and air conditions. It is well within reach of a student project. Home applications are where most of these projects end up, and there power consumption becomes the design constraint. A device that must be plugged in is a different product from one that runs a year on a battery.

Medical and security applications are worth reading for their reliability requirements rather than their circuits. A sensor that misses one reading in a thousand is fine for a plant and unacceptable for a patient. Automotive applications are the useful contrast, because the environment is far harsher than anything else here. Heat, vibration, electrical noise, and a supply that is anything but steady.

What you should now be able to explain or do

Test a board before suspecting your own code, and say what a blink test proves. Recognise the environment's common failure modes. Apply isolation and halving to find a fault. Use a printed value to separate hardware faults from software ones. Name the three hardware faults that cause most trouble, and say what constraint dominates each application area.

Check yourself