EC-13.5 Embedded and Signals on the Bench

What this is and why it exists

This is the stage where the two halves of the area meet on one bench.

It is also where the hardest student debugging happens, because a symptom can come from either side. A sensor reading that never changes might be a broken sensor or a misconfigured pin. It might equally be a bus that is not running, or a variable never updated.

The method that separates them is instrumental rather than clever. Look at the wire, and see whether what is on it matches what the code intended.

The vocabulary

• Bring-up — proving a board is running before debugging anything on it.
• Heartbeat — a pin toggled at a known rate to show the program is alive.
• Protocol decode — an instrument feature that displays a serial bus as bytes.
• Loopback — connecting an output back to an input to test one side alone.
• Ground truth — a known input, measured independently, used to check a reading.

The mental model

Start every embedded session by proving the board is running. A pin toggling at a known rate proves the supply, the clock, the reset and the program load in one measurement.

It takes three lines of code and one probe, and it is the thing most often assumed instead of checked. A board that is not running looks exactly like every software bug you might have. The two minutes spent here are recovered many times over.

Looking at a serial bus with an instrument is the second technique and it settles questions in seconds that otherwise take an afternoon.

Most oscilloscopes and all logic analysers can decode a serial bus and show the bytes actually transferred. Comparing those bytes with what the code intended tells you immediately which side of the boundary the fault is on. If the right bytes went out and the wrong ones came back, the sensor is at fault. If the wrong bytes went out, the code is.

Verifying a converter reading needs a ground truth. Apply a voltage you have measured independently, and check what the converter reports.

Three failure shapes, three different faults. A constant offset points to the reference or a bias. A scaling error points to the reference value being different from what the code assumes. A reading that never moves at all points to the pin, the multiplexer setting or a conversion that never completes.

Capturing a real signal is the next step, and the thing to check is the sample rate. Record a known sinusoid through the whole chain and confirm that its frequency comes back correct.

An unexpected answer almost always means the sample rate is not what the configuration claimed. A prescaler set differently from the calculation, or a conversion taking longer than the interval allowed, both show up here and nowhere else.

Measuring timing is done by toggling a pin, for the reason the embedded module gave. Set a spare pin high at the start of a section and low at the end, then measure the pulse on an oscilloscope.

It costs one pin and two instructions, and it disturbs the timing far less than printing over a serial line. A fault that appears only at full speed can be measured this way and cannot be measured by printing.

Finally, the split. Two experiments divide the problem in half rather than debating it.

Drive the pin manually, from a wire or a bench supply, and see whether the hardware responds. Then run the code with the hardware disconnected, and see whether it behaves as the program says it should. One of the two will fail, and that tells you which side to look at.

That is the whole method. It is not sophisticated and it is faster than any amount of reasoning about what should be happening.

What you should now be able to explain or do

• Prove a microcontroller board is running before debugging anything on it.
• Decode a serial bus on an instrument and compare it with what the code intended.
• Verify a converter reading against an independently measured input.
• Confirm a sample rate by capturing a known signal through the whole chain.
• Measure the duration of a code section without disturbing its timing.
• Split a fault into hardware or software with two experiments.

Check yourself