Bringing up a new board: a staged power-up checklist
The order we check a new board in, from bare-board inspection to the first working bus, so a single fault can't destroy the board or hide behind another.
RJC Systems4 min read
- bring-up
- debug
- hardware
A new board is back from assembly, and the temptation is to plug in USB and flash the firmware. Sometimes that works. When it doesn't, you can't tell whether the problem is power, the clock, the reset line, the debug connection, or the code, and a shorted rail at full current can take parts with it before you find out.
Bring-up goes faster when you verify one layer at a time and don't move on until it's confirmed. This is the order we follow on every board that comes into our lab.
1. Inspect before you power anything
Most assembly faults can be seen. Under magnification, check:
- Polarity. Diodes, LEDs, tantalum and electrolytic capacitors.
- Orientation. Pin 1 of every IC and connector, against the silkscreen and the assembly drawing.
- Fine-pitch joints. Solder bridges between pins on QFNs, QFPs, and connectors.
- Missing or swapped parts. Especially resistors in feedback dividers, where a wrong value changes a rail voltage without any visible sign.
Five minutes here regularly saves an afternoon later.
2. Measure each rail to ground, unpowered
With the board unpowered, measure the resistance from each supply rail to ground. A near-zero reading means a short, and you have found it before it could do any damage.
Expect the reading to climb for a moment as bulk capacitors charge from the meter. Some rails legitimately read low because of the loads on them, so compare against a second board where you can. If one board reads a few ohms and the other reads a few kilohms, the low one has a problem.
3. Power up on a current-limited supply
Use a bench supply, not USB or a battery. Set the voltage to the board's input and the current limit just above what you expect the board to draw at idle, then switch it on and watch the current.
| What you see | What it usually means |
|---|---|
| Current about where you expected | Proceed to measuring rails |
| Supply hits the current limit | Short or a part in latch-up; switch off and isolate |
| Near-zero current | Input not reaching the regulators; check connectors, fuses, and enables |
| Current creeps up over time | Something is heating; find it before going further |
If the board has several regulators, power them one at a time where the design allows it, by lifting an enable or populating a jumper.
4. Verify every rail at the load
Measure each rail at the pins of the parts it feeds, not just at the regulator output, and compare against the tolerance in each part's datasheet. Then look at each rail on a scope. Use a short ground spring on the probe instead of the long ground lead, which picks up enough noise to make a clean rail look bad.
If the design has power sequencing or power-good signals, confirm the rails come up in the order the datasheets require and that each power-good asserts.
5. Confirm the clock
A processor with no clock looks dead. Check that the oscillator is running and at the right frequency.
Probing a crystal directly adds capacitance that can shift its frequency or stop it from starting, so a reading there can mislead you. Where the part can route its clock to an output pin, measure there instead. Otherwise use a 10x probe, and treat the result with some caution.
6. Check reset and boot pins
Confirm the reset line is released after power-up and stays released. If a reset supervisor holds it low, the reason is usually a rail just below its threshold.
Check the boot-mode pins as well. Many microcontrollers read one or more pins at reset to decide whether to run from flash or start a bootloader. A pin left floating or tied the wrong way produces a board that powers up, then does nothing.
7. Connect the debugger before your firmware
Before loading the real application, connect over SWD or JTAG and read the device ID. This proves power, clock, reset, and the debug wiring at the same time. Then load the smallest possible program: toggle a pin, or print one line over a UART.
If the debugger can't connect, go back to steps 4 through 6. A failed connection is almost never a firmware problem.
8. Bring up peripherals one at a time
Only now start on the rest of the board, one interface at a time:
- I2C: scan the bus and confirm each device answers at the address you expect.
- SPI: read a register with a known value, such as a device ID, before writing anything.
- UART: a loopback test confirms the wiring and baud rate before you talk to another device.
Keep a logic analyzer on the bus during this stage. It shows the difference between "the device didn't answer" and "we never sent anything" right away.
Write it down as you go
Record every measurement, whether or not it looks right: rail voltages, idle current, clock frequency, and any change you made to the board. The notes cost almost nothing to take and are what you'll compare against on the next board or the next revision.
That record is also what we hand back to clients. Every board we bring up returns with a written report of what we measured, what was wrong, and every change we made.