Board Bring-Up and Fault Finding

• Bring-up is a procedure, not an activityWrite the bring-up procedure before the boards arrive, while you still remember the design intent and while you are not under pressure. It should list, in order, every check with its expected value. Improvising bring-up is how boards get destroyed on first power.
• Never power a new board from an unlimited supplyUse a bench supply with the current limit set just above the expected idle current. A short that would vaporise a trace on a USB port merely trips the limit on a bench supply, and the limit trip is itself diagnostic information.
• Sectional power-upWhere the design allows, bring up one rail at a time using zero-ohm links or unpopulated regulators. Prove each rail before enabling the next. Designing these links in at layout time is what makes this possible, which is why bring-up considerations belong in the design phase.
• Root cause, not symptomA board that works after you reflowed a joint has an unknown root cause: was the joint cold, was the pad damaged, is the footprint wrong, is the paste stencil aperture wrong? Chasing symptoms produces boards that fail in the field. Every fault gets pursued to a cause and to a specific design or process change.
• Distinguish design faults from assembly faultsIf one board out of five has the problem, it is assembly or a component. If five out of five do, it is design. This single question, asked early, saves enormous amounts of time, and it is why you build more than one prototype.
• Reworking to test a hypothesisCutting a trace and adding a wire is a legitimate experimental technique, not an admission of failure. Do it deliberately, photograph it, record it, and keep a rework log per board so that a board's measured behaviour can always be attributed to its actual, current configuration.
• The errata documentEvery finding — design fault, assembly issue, documentation error, a value that should change — goes into a board errata document tied to the revision. This becomes the changelist for the next revision, and it is the artifact that turns a prototype run into engineering progress.
• Knowing when to stop and respinThere is a point at which a board is so reworked that its measurements no longer represent the design. Recognise it, capture what you have learned, and respin. Continuing to patch past that point produces confident conclusions about a circuit that does not exist.

ProblemFirst power-up. The 5 V input is correct. The 3.3 V LDO output measures 2.1 V and the current limit on the bench supply is tripping at 400 mA. Diagnose it.

1. 1
   Stop and think before probing further. A rail below its target with excessive current means either the regulator is faulty, or something downstream is drawing too much, or the regulator is in current limit because of a short.
2. 2
   Power down. Measure the resistance from 3.3 V to ground. If it reads a few ohms or less, there is a short and the regulator is doing its job. If it reads hundreds of ohms, the regulator itself is suspect.
3. 3
   Suppose it reads 8 ohms. That is a short, not a load. 3.3 V into 8 ohms would be 400 mA, exactly matching the observed current — consistent.
4. 4
   Localise the short. Bisect physically: the 3.3 V net probably spans the whole board. Look at the layout and identify the natural cut points — usually a ferrite bead, a zero-ohm link, or a via you can drill.
5. 5
   If there is no designed cut point, this is your first errata item: 'add a 0 ohm link in each rail for sectional bring-up'.
6. 6
   Bisect by measurement instead: use a low-resistance measurement (four-wire if you have it, or a milliohm meter) at several points along the rail. The point closest to the short reads lowest. This works because the copper's own resistance creates a gradient toward the fault.
7. 7
   Alternatively, inject a current-limited voltage into the shorted rail (a few hundred millivolts, an amp or so) and use a sensitive voltmeter to find the voltage gradient, or a thermal camera or your fingertip to find what is getting warm. The warm part is usually the fault.
8. 8
   Suppose the short localises to a decoupling capacitor near the microcontroller. Remove it and re-measure: 8 ohms becomes 50 kohm. Confirmed.
9. 9
   Now the crucial step: root cause. Why did that capacitor short? Options: (a) a genuinely faulty part, (b) mechanical damage during assembly, (c) it is the wrong voltage rating and was overstressed, (d) it was placed on a footprint that bridges to something.
10. 10
    Check the BOM: is it rated for 3.3 V with adequate derating? Check the placement: was it the correct value and package? Check the neighbouring pads for a bridge under the part.
11. 11
    Suppose the BOM specifies a 6.3 V part and the board also has a 5 V test point adjacent — but the part is on 3.3 V, so overstress is unlikely. Suppose the removed part measures short out of circuit. That points to a faulty part or damage.
12. 12
    Check the other four boards. If none of them shows it, this is a single faulty component — record it, replace it, and continue. If two of five show it, the part or the reel is suspect and this becomes a sourcing errata item.
13. 13
    Record: symptom, measurements taken, localisation method, root cause, evidence, action taken, and whether a design change is required. Even a 'single faulty part' finding may generate a design change: 'increase capacitor voltage rating to 16 V for margin' or 'add a rail-splitting link for future bring-up'.
14. 14
    Resume the procedure from the beginning, not from where you left off. A fault can mask others.

AnswerShort on the 3.3 V rail localised by resistance gradient to a decoupling capacitor. Root cause pursued to component level and checked against the other boards. Two errata items generated: the failed part, and the absence of rail-splitting links that made localisation harder than it needed to be. Then the procedure restarts from the top.

Tool: Bench supply, multimeter, scope, thermal detection and a written procedure

• Write the procedure first, as a table: step number, action, expected value, tolerance, actual value, pass/fail, notes. Ten to thirty steps is typical for a small board.
• Step group 1 (unpowered): visual inspection against the assembly drawing; resistance from each rail to ground; resistance between adjacent rails; continuity of ground across the board.
• Step group 2 (first power): bench supply set to the input voltage with the current limit at expected idle plus 50%. Ramp from zero and record the current at 25%, 50%, 75% and 100% of nominal input voltage. A step change is a fault signature.
• Step group 3 (rails): measure every rail at the point of load with the multimeter, recording the value and comparing to the power tree. Then scope every rail on AC coupling at high sensitivity, looking for oscillation or excessive ripple. Record the peak-to-peak.
• Step group 4 (clock and reset): scope the oscillator output and the reset line, recording frequency, amplitude and reset pulse width.
• Step group 5 (digital): attach the debug probe, confirm target detection, flash and run blink, then run the GPIO sweep, I2C scan and device ID reads from the firmware skill.
• Step group 6 (analogue and interfaces): ADC verification, each serial bus captured and decoded, each connector's signals verified.
• Now practise fault-finding. Have a colleague inject three faults into a working board (a lifted pin, a wrong-value resistor, a bridged pair), or inject them into a spare board yourself and then set it aside for a week.
• Work the procedure. For each failure, record which step caught it and how many additional measurements were needed to localise it.
• Practise the thermal technique: with the board powered at a low current limit, use a thermal camera if you have one, or an alcohol-dampened fingertip, or a can of freeze spray, to find the part dissipating unexpectedly.
• Practise the resistance gradient technique on a deliberately shorted rail.
• For each fault, write a full errata entry with root cause and proposed design or process change.

• EEVblog and Robert Feranec - board bring-up and debugging videosfreevideo~180 minSearch both channels for board bring-up and debugging. Watching an experienced engineer work a real fault in real time, including the wrong turns, is the closest thing to apprenticeship available free.
• All About Circuits - Troubleshooting theory and strategyfreereading~45 minThe written treatment of systematic fault-finding, bisection and the dangers of assumption applies directly at board level.
• NASA-STD-8739.3 - Soldered Electrical Connectionsfreereference~60 minFor distinguishing assembly defects from design faults you need an objective standard for what a good joint looks like. This one is free to download and heavily illustrated.
• sigrok for logging during bring-upopen licencetool~30 minUse sigrok-cli to log supply voltage and current over time during power-up, so transient behaviour is captured rather than guessed at.

Write and execute a complete bring-up procedure on a real board, diagnose every fault found to a root cause, and produce a board errata document that constitutes the change list for the next revision.

Deliverables

• A written bring-up procedure produced before power-up, with at least twenty numbered steps, each with an action, an expected value and a tolerance, organised in the order unpowered / first power / rails / clock and reset / digital / interfaces.
• The completed procedure with actual measured values recorded for every step and a pass/fail verdict, against a specific board serial number.
• Photographs or captures for the critical steps: rail scope traces, clock waveform, reset waveform, and at least one decoded bus transaction.
• A fault log for every problem encountered, each entry containing: the symptom as first observed, the measurements taken to localise it, the localisation technique used, the root cause with its evidence, whether other boards show it, the immediate fix applied, and whether a design change is required.
• At least three faults diagnosed. If your board genuinely has fewer, inject the remainder deliberately and diagnose them blind after a delay.
• A rework log per board: every modification made, photographed, with a statement of what it was testing and whether the board's measurements remain representative of the design.
• A board errata document for the revision, listing every finding as a numbered item with a severity, a proposed change, and a statement of whether it blocks the next revision or can be deferred.
• A design-for-bring-up review: at least five specific changes to the design that would have made this bring-up faster (rail-splitting links, more test points, a spare instrumentation GPIO, better silkscreen, sectional enables), each with the time it would have saved.
• A statement of the board's final verified state: which subsystems are proven, which are unproven, and which are known bad.

Acceptance criteria — how you know it is good enough

• The procedure was written before power-up and has expected values, not just actions.
• Every step has a recorded actual value, not a tick.
• Every fault is pursued to a root cause with evidence, not stopped at 'reflowed it and it worked'.
• Each fault is checked against the other boards to distinguish design from assembly causes.
• The rework log lets any measurement be attributed to a known board configuration.
• The errata document is a usable change list with severities.
• The design-for-bring-up review contains at least five specific, actionable changes.

If you want to push further

• Build a simple test fixture (pogo pins on a 3D-printed jig) that runs the whole electrical portion of the procedure in one insertion, and time the improvement.
• Automate the procedure: a script that drives the bench supply, the meter and the logic analyser over their interfaces, executes the checks and produces the report.

• I write the bring-up procedure with expected values before the boards arrive.
• I power new boards from a current-limited supply and ramp deliberately.
• I localise shorts with resistance gradients or thermal methods rather than by removing parts at random.
• I pursue every fault to a root cause and check it against the other boards.
• I keep a rework log so measurements can always be attributed to a known configuration.
• I produce a board errata document that becomes the next revision's change list.
• I know when a board is too reworked to be representative and it is time to respin.