First power-up of a new prototype board, step by step

The boards arrive. You plug in the supply, nothing happens, or something gets warm, or the debugger says “no target.” Now you have one board, no spare, and no idea whether the fault is in the design, the assembly or the firmware.

That is the most expensive moment in a prototype. The cure is order. A fixed sequence, run every time, narrows the fault by one layer at each step and keeps you from applying power to something that was already broken.

Before power: look and measure

Do the checks that need no power first. They cost minutes and they are the only ones that cannot damage anything.

Look at it under magnification. You are hunting for bridged pins on fine-pitch parts, tombstoned passives, a part rotated 90 or 180 degrees, and polarized parts (diodes, electrolytics, LEDs, tantalums) placed backwards. Compare the board against the assembly drawing, not against your memory of the schematic. Pin-one marks on ICs and connectors are the usual casualties. If you built the board through an assembler, this is also where a wrong part or a swapped footprint shows up. A layout mistake that only shows at assembly will often be visible here.

Measure every rail to ground with the board unpowered. A short between a supply rail and ground is the most common reason for a completely dead board, and it is findable with a meter. Write down each rail’s resistance. A very low reading on a rail with a lot of decoupling is not automatically a fault, because the meter is seeing capacitors charge, so watch whether the number settles and rises. A reading that sits at a dead short does not.

Make this easier at design time. Put a test point or an accessible pad on each rail and on ground, and put a zero-ohm link or a removable part in series with any rail you may need to isolate. That is the same thinking as deciding which test points and programming pads a board needs, and it pays off most on the first board you ever build.

Check connector pinouts against the schematic. A reversed power connector, or a mirrored footprint on a right-angle header, will destroy a board the instant it is powered. Check the mating cable too. This is the cheapest check on the list and the one people skip because they “know” the pinout.

First power: limit the current and watch

Use a bench supply with the current limit set low, well above what the board should draw at idle but far below what would cook a short. Raise the voltage in steps if the supply allows it, rather than jumping to nominal.

Then watch two things: the current and your fingers. If the supply goes straight into current limit, stop. Do not raise the limit to see what happens. A short that is dropping the supply to a fraction of a volt while pulling the limit current is dissipating heat in exactly one place, and you can find it. Thermal imaging, or a careful touch of a fingertip on each regulator and large IC with the limit still low, usually finds the part. Freeze spray or a drop of isopropyl alcohol that evaporates first over the hot spot works too.

If current is sane, do not assume the board is fine. Measure.

Rails first, then clocks, then reset

Walk the power tree in the order the chips are powered, with a meter and then a scope on anything that is meant to be quiet.

1. Each rail at its pin, not at the regulator. Measure at the load. A rail that is right at the regulator and wrong at the IC points to a missing via, a bad solder joint or a trace that was never connected.
2. Sequencing and enable lines. If one regulator enables another, or a power-good output gates a reset, confirm those signals move in the order the datasheets require. Many “dead” boards are waiting on an enable pin that is floating.
3. Ripple and startup on the scope. A switching regulator with the wrong inductor or output capacitance can start, hiccup and restart. A meter averages that into a plausible-looking voltage. A scope shows it.
4. Every supply pin of the microcontroller. Datasheets and reference designs expect every supply pin to be connected and decoupled; Check your part family’s hardware-design guidance for the minimum a board needs: power, clock, reset, boot configuration and debug. Parts with internal regulators can also need a specific capacitor on a dedicated pin, so check the pin list rather than assuming.
5. The clock. If the part uses an external crystal, probe the oscillator pins. No oscillation is usually a load-capacitor problem, a wrong crystal footprint or a layout that put a ground pour or a noisy trace under the crystal. Probing can load a crystal enough to stop it, so use a high-impedance probe, and if you can, check a clock output pin or a toggling GPIO instead.
6. The reset line. Confirm reset is released and stays high. A reset pin that sits low because of a stuck supervisor, a missing pull-up or a debug cable fighting the on-board circuit will look exactly like a dead chip.

If a board resets on its own after it has been working, that is a separate hunt, and we cover it in finding why a device resets in the field.

Get the debug link up before anything else

Do not write application firmware until you can talk to the chip. The debug link is the instrument everything else depends on.

For Cortex-M parts the standard small connector carries a target voltage reference, SWDIO, SWCLK, optional SWO, ground and a reset line. Arm’s CoreSight 10-pin connector reference lists the signals; in that description, the voltage reference tells the probe which I/O level the target uses, and the reset line is pulled high on the target and driven low to reset it. The common failures are practical ones:

• Probe sees no target voltage. The reference pin is not wired to the board’s I/O supply, or the supply is off.
• Connector rotated or mirrored. A 1.27 mm header is easy to place flipped. Check against the probe cable, not the datasheet drawing.
• Reset wired but fighting. If the reset pin has a heavy capacitor or a supervisor driving it, the probe may be unable to pull it low. Try connecting under reset, or try without the reset line.
• Debug pins repurposed. If an earlier firmware build reconfigured the debug pins as GPIO, a chip that once connected will now refuse. Hold reset low or use a boot-pin method to get in, then erase.

When the debug port is dead on a good-looking board, check the boot configuration. Many chips decide at reset whether to run user flash or a ROM bootloader, based on a boot pin or option bytes. Read your family’s bootloader documentation for the serial interfaces it accepts. Two cheap lessons follow: a floating boot pin gives you a board that sometimes starts in the wrong place, and a spare serial header wired to the bootloader’s interface is a rescue path when the debug port is locked out. Boot-pin behavior differs between families and even between parts in one family, so read the reference manual for the exact part you use.

Then, and only then, run firmware

Start with the smallest program that proves something: toggle an LED, print a character over a UART, read one register from one I2C sensor. Each of those exercises a different part of the board. Build up from there peripheral by peripheral, so that when something fails you know it is the one thing you just added.

Keep a log of what you measured on board number one. When board two comes back from assembly, the same numbers tell you in minutes whether it matches. Differences between boards are the strongest evidence of an assembly defect rather than a design flaw.

What to stop and do

Stop when a rail is wrong and you do not know why. Do not keep powering a board that is warm, that browns out, or that draws more than expected. Cut the supply, remove the suspect part or lift the rail with the link you designed in, and measure again. Boards are cheaper than the habit of hoping.

How we approach it

We design boards with the bring-up in mind: isolatable rails, probe-able test points, a debug header oriented to the cable, and a boot path that does not depend on luck. If you have a board that will not start, send us the schematic, the layout files, a photo of both sides and what you measured; that is enough to tell you where the fault most likely is.