A dead board is a question, not a mystery
You have built something. You power it up and... nothing. Or a wisp of smoke. Or it half-works in a way that makes no sense. The temptation is to start swapping parts at random — resist it. A circuit obeys physics every microsecond, so whatever is wrong has a definite cause sitting at a definite place on the board, and the bench instruments from the earlier guides are now your senses for finding it. Debugging is not luck and it is not art; it is a small, repeatable science: observe, form a hypothesis, design a test the hypothesis must pass or fail, then narrow.
The earlier guides handed you the tools — the bench supply with its current limit, the DMM, the oscilloscope and its compensated probe, the function generator. This guide hands you the method that aims them. The single most powerful idea is this: never change two things at once, and never guess where a fault is when you can measure where it is. A single measurement that rules out half the board is worth more than ten lucky part-swaps.
Rule one: check power and ground first
Before chasing any clever signal fault, confirm the boring foundation: that every chip is actually receiving its supply voltage, referenced to a solid ground. An astonishing share of "it doesn't work" turns out to be a rail that never arrived, a ground that isn't connected, or a supply sagging under load. Put the DMM in DC volts, black lead on a known ground, and measure the voltage right at the power pin of each chip — not at the supply terminals, at the pin — because a thin trace or a bad joint between the two is exactly the kind of fault you are hunting.
Make the numbers talk. Suppose a 5 V rail reads 5.0 V at the supply but only 3.1 V at the chip. That 1.9 V gap is not noise — it is current times resistance across something in between: a hairline crack, a cold joint, an under-sized trace. Or the rail reads 5 V with nothing running but collapses to 3 V the moment you enable the circuit: now something downstream is drawing far more current than it should, and the supply's current limit is doing its job by refusing to feed the runaway. Either way the DMM has just turned "doesn't work" into the far smaller question "where is the excess load?" — and switching the meter to its current range in series with the supply tells you exactly how much is being drawn.
Two foundation checks people skip. First, ground continuity: put the DMM in its beeping continuity mode and confirm every ground point genuinely connects back to the same node — a floating or split ground gives bizarre, drifting symptoms that masquerade as a hundred different bugs. Second, look at the rail on the scope, not just the DMM. The meter reads the average; the scope shows the wobble. If a rail dips and rings every time a chip switches, you have a missing or too-distant decoupling capacitor — the local water tank that keeps the supply from drooping when the thirsty machine beside it gulps a sudden mouthful.
Divide and conquer: cut the problem in half
Once power is solid, the master strategy is divide and conquer — the same binary search you use to find a word in a dictionary. A circuit is a chain of stages, a signal chain running from input to output. Rather than probe stages one by one from the start, probe the middle first. If the signal is healthy there, the fault lies in the second half; if it is already wrong there, the fault lies in the first half. Each measurement halves the suspect territory, so a board with sixteen stages is cornered in about four probes, not sixteen.
To do this you need a known-good input to follow. This is where the function generator earns its keep: inject a clean, known signal — say a 1 kHz sine at 100 mV peak-to-peak — at the input, then walk the scope along the chain, comparing what you see to what the design says you should see at each node. A stage that takes a good signal in and puts a wrong one out has just confessed. On a digital board the same logic uses a logic analyzer to watch many lines at once and catch the bus exactly where the pattern first goes wrong.
FOLLOW THE SIGNAL (inject 1 kHz, 100 mVpp at the input) ------------------------------------------------------------------------ node expected measured verdict -------------- ----------------- --------------- ----------------------- input 1 kHz, 100 mVpp 1 kHz, 100 mVpp good -> fault downstream after RC filter 1 kHz, ~70 mVpp 1 kHz, 100 mVpp C not doing its job? amp output 1 kHz, 700 mVpp flat 0 V DEAD: fault is HERE ------------------------------------------------------------------------ signal good at input, dead at output -> probe the MIDDLE first, not stage 1 then 2 then 3 ... (4 probes corner 16 stages, not 16)
Compare, hypothesize, test — one change at a time
Every measurement is only meaningful against an expectation, so debugging leans on three references. Compare the board to its schematic: is the part actually fitted the part the schematic calls for, in the right orientation and the right value? Compare it to a simulation: what voltage should this node sit at, and is the real one close? And, when you have one, compare to a known-good board side by side. Most "impossible" bugs dissolve the instant you notice a node reading 0 V that is supposed to read 2.5 V and simply ask why.
Be honest about what simulation can and cannot tell you. A SPICE result is only as good as the device models inside it, and it knows nothing of your physical board — it cannot see a solder bridge, a long ground return, the stray capacitance of a breadboard, or a probe that is itself loading the very node it measures. The simulation tells you what the design should do; the bench tells you what this particular copy actually does, layout and all. When the two disagree, the difference is the bug, and chasing that gap is the whole game.
- Observe the symptom precisely. "Output stuck at 0 V when input is driven" beats "it's broken." Write down exactly what is wrong and under exactly what conditions.
- Form one hypothesis with an address. Not "something's wrong with the amp" but "I bet the feedback resistor is open, so this node should float to the rail." A good hypothesis predicts a specific measurement.
- Design the test the hypothesis must pass. If the resistor is open, this node reads the rail; if it is fine, it reads 2.5 V. Decide the verdict before you ever touch the probe down.
- Make exactly one change, then re-test. Two changes at once and you can never tell which one mattered — or worse, one fixes while the other breaks, and the board lies to your face.
- Whatever the verdict, you have learned something: the fault is here, or it is not. Loop — observe, hypothesize, test, change one thing — until the suspect territory shrinks to a single component.
The usual suspects: common failure modes
After enough benches you learn that faults are not spread evenly — a small handful of failure modes account for most of them, and knowing the list turns a blank stare into a checklist. The build mistakes come first: a part fitted backwards (electrolytic capacitors, diodes, and ICs all care which way round they go), a solder bridge shorting two adjacent pins, a cold joint that looks connected but isn't, the wrong value dropped in, or a pin that simply never got soldered. These are exactly why that ten-second visual inspection pays off so handsomely.
Then the subtler, in-service failures. A part stressed beyond its datasheet limits — too much voltage, too much current, too much heat — eventually fails, sometimes as a dead short, sometimes wide open. A transistor or regulator that gets hotter, conducts more, and so gets hotter still can march into thermal runaway and cook itself. And a perfectly correct amplifier can break into unwanted oscillation if its feedback loop carries too much phase shift: the bench symptom is a stage that "doesn't work" but is in fact singing at a megahertz you only see once you finally put a fast enough scope on it.
The thread through all of it: a fault has a cause, the cause has an address, and the bench instruments plus a halving search will find it far faster than luck. Debugging is the same disciplined iteration loop as design itself — observe, hypothesize, test, change one thing, repeat — and it is where you truly come to understand how your circuit works, because a circuit that never once misbehaves teaches you nothing. The final guide of this rung closes the loop by going deep on reading a datasheet and recognizing these failure modes before they ever bite.