100nF

Bringing up a board that does nothing

A first-power-on procedure in the order that finds faults fastest: current before voltage, rails before reset, reset before clock, clock before code. Most dead boards fail in the first three steps.

By bring-updebugginghardware

The first board comes back, you plug it in, and nothing happens. No enumeration, no debugger, no blink.

The failure mode of this moment is not technical, it is procedural: people start where they are most comfortable — usually the firmware — and work outward. That is the wrong end. A board that does nothing has almost always failed somewhere in the first three of these steps, and each one is faster to check than the one after it.

The order below is chosen so that each step is cheap and each step’s assumptions have already been proven by the step before.

0. Before you apply power

Look at it under magnification. Tombstoned passives, a bridged QFN pad, a part rotated 180°. Five minutes here beats an hour of probing. Check polarity on everything polarised, and check that any part you hand-soldered is the part you meant.

Ring out the rails to ground with a meter, unpowered. Every supply net to ground, on the diode or resistance range. A rail reading a few ohms or less is a short, and you want to know that before a regulator finds out. Note the readings even when they are fine — a healthy 3V3 rail with plenty of decoupling reads as a capacitor charging, and knowing what “normal” looks like on board one makes board two’s fault obvious.

Check the input protection is the right way round. A reverse-polarity diode fitted backwards is a short across your supply.

1. Current-limited power, and watch the current — not the voltage

Set the bench supply to the input voltage with the current limit set low — somewhere just above the expected idle draw. If you have no idea, 50–100 mA is a reasonable first guess for a small MCU board.

Then apply power and look at the current, not the voltage.

  • At the limit, voltage collapsed: a short. Power off. If you have a thermal camera, this is the moment to use it — the shorted part will be visibly warm within seconds. Failing that, the isopropyl trick: a thin wipe over the board evaporates first over the hot part.
  • Zero current: nothing is being enabled. Check the input path before blaming the load — connector, fuse, protection diode, enable pin.
  • Roughly what you expected: good. Move on.

A board that draws its expected idle current has already told you that the regulator started, nothing is shorted, and the MCU is probably not held in a fault state. That is a lot of information from one number.

2. Every rail, in sequence, at the far end

Measure each rail at the load pin, not at the regulator output — the whole point is to catch the volt drop or the broken via between the two.

Check them in supply-sequence order. Many parts have sequencing requirements between core and I/O rails, and a rail that is correct in steady state can still have come up in the wrong order. If sequencing matters for your part, put a scope on two rails at once and look at the turn-on, not the DC value.

Then check the ripple, with a proper probe technique — a ground spring, not the 15 cm clip, or you will be measuring your own probe. If a rail looks noisy here, the decoupling calculator and the layout article are the follow-up; but be sure it is real before you redesign anything.

While you are here: AVR042 makes the point that an I/O pin switching a capacitive load can demand several hundred milliamps for a few nanoseconds, and that this current cannot be delivered over long power supply lines; the main source is (or should be) the decoupling capacitor. If your rail sags only when the board starts doing something, that is what you are looking at, and it is a layout problem, not a regulator problem.

3. Reset, and the pins that decide what happens next

Now the boring pins that stop more boards than any circuit fault.

Reset. Scope it through power-up. It should go low and release cleanly at the right point. Common failures: a pull-up that is missing or far too weak, a capacitor that makes the release far too slow, a watchdog or supervisor holding it low, or a debugger holding it low because it is attached and confused.

Boot / configuration straps. Almost every modern MCU samples strapping pins at reset. Get one wrong and the part boots from the wrong place and looks dead. The RP2040 design guide gives the shape of this — pulling QSPI_SS low and then toggling RUN makes the chip restart in BOOTSEL mode instead of attempting to run the contents of the flash — and notes that the strap resistor must be chosen so the pin can safely over-drive it once booting starts. Every family has an equivalent, and every family has people who got it wrong.

Measure the strap voltages at reset release, not later. A pin driven by something else after boot tells you nothing about what was sampled.

Enable pins. Regulators, level shifters, load switches. An unconnected enable on a part that needs one is a very quiet failure.

4. The clock

If the rails are good and reset releases and the part still does nothing, look at the clock.

Most parts start on an internal oscillator and only switch to the crystal later, so “no crystal” often presents as code runs but timing is wrong, or as a hang at the exact line where the firmware waits for the external clock to become stable — which is an easy thing to misread as a firmware bug.

Probe carefully, or you will change the answer. A 10× probe adds roughly 10 pF directly onto the oscillator node — enough to stop a marginal oscillator, or start one that would not otherwise run. Probe the drive side through a series resistor, or use an active probe, and treat any measurement on the input side as approximate. The crystal load calculator and why the crystal won’t start cover what to do when it is genuinely not oscillating.

5. The debugger

Only now is it reasonable to expect a debug connection.

If SWD or JTAG will not attach: check the debug pins have not been reassigned by firmware already in flash (connect-under-reset exists for this), check the target reference voltage pin is actually connected to the target’s I/O rail, and check ground. A debugger needs a ground return near the signals, not just somewhere on the board.

If the part is factory-blank it cannot have reassigned anything, so a blank part that will not attach is a hardware fault — rails, reset, or wiring.

6. Peripherals, one bus at a time

With code running, bring up buses individually rather than running the full application.

  • I²C: scope SDA and SCL. Both idle high is the healthy state; either stuck low is a bus fault — a device holding the line, or a missing pull-up. Check the rise time, not just the level: a slow, rounded edge means the pull-up is too weak for the bus capacitance, which the I²C pull-up calculator sizes properly.
  • SPI: check chip select actually goes low, and that mode (CPOL/CPHA) matches. Most “SPI doesn’t work” is one of those two.
  • UART: check the baud rate error before suspecting anything else, especially on an internal oscillator.

The general rule

Every step above proves an assumption the next step depends on. The reason people lose days to this is not that any individual check is difficult — it is that they start at step 6, find something that does not work, and debug it for hours without knowing that step 2 was already broken.

If you are ever lost, go back to the current draw. It is the cheapest measurement on the board and it tells you more per second than anything else.

Sources