OE-9.5 Debugging Tools & Application Case Studies

What this is and why it exists

Embedded debugging is hard for a specific reason, and it is worth naming rather than enduring. The usual crutch is gone. There is often no console to print to — and adding one changes the timing you were trying to observe.

That is the observer problem in a practical form. Your instrument disturbs the thing it measures, which never happens when you add a print statement to a desktop program.

So the tools matter more here than elsewhere, because each one sees a different layer and disturbs the system differently.

The vocabulary

• Logic analyser — captures many digital signals over time.
• Simulator — runs the code on a model of the processor.
• Emulator — imitates the target closely enough to run real code.
• In-circuit emulator — replaces the processor in the real circuit.
• Integrated development environment — editor, compiler and debugger together.
• Intrusive — changes the timing or behaviour of what it observes.
• Heisenbug — a fault that disappears when you try to observe it.

The mental model

Match the tool to the layer and to how much disturbance you can afford.

A simulator runs your code against a model. It is fast, completely observable, and unfaithful. The model is not the chip, and it lacks your board's timing, your sensor's noise and your supply's sag. Excellent for logic, useless for anything involving the real world.

An in-circuit emulator sits in the real circuit in place of the processor. It is faithful, and it is intrusive: it may change timing slightly, and it costs money. When a fault only appears in the real system, this is what sees it.

A logic analyser watches many digital lines at once and disturbs almost nothing. It sees what actually happened on the wires, which is the only impartial witness when hardware and software each blame the other.

An integrated environment with a debug connection is the everyday tool, giving breakpoints and variable inspection on the real device. Note that halting at a breakpoint stops the processor and not the outside world. Motors keep turning, buffers keep filling, and a communication partner times out. A breakpoint in real-time code can create a failure that was never there.

That is the habit this whole topic is built around. Ask what your instrument is changing before you trust what it shows. A fault that vanishes when observed is not mysterious. It is a timing fault, and the observation altered the timing.

The case studies are worth reading as three different constraint sets rather than three technologies. A mobile-network module is about a device that must survive an intermittent link and negotiate with a network it does not control. A vehicle bus is about many nodes on one wire, with message priority decided by the bus itself and reliability treated as a safety matter. A low-power mesh is about devices that must run for years on a battery. The radio is the biggest consumer, and being asleep is the normal state.

Each chose differently on exactly the design metrics from the first topic, which is what makes them worth comparing.

What you should now be able to explain or do

Say why printing is not available and what adding it costs. Match simulator, in-circuit emulator, logic analyser and debug environment to a fault. Say which tool is fast and unfaithful and which is faithful and intrusive. Explain why a breakpoint can create a failure in real-time code. Recognise a disappearing fault as a timing fault. Compare the three case studies by their constraints rather than their technology.

Check yourself