Hardware Bring-Up: What Happens After PCB Assembly?

You finish a step, you write the observation against the unit's identity, and only then you take the next risk. A board that "sort of works" with no record has not been brought up. It has been handled. Every figure below is hypothetical teaching maths. None of it is a measurement from a product, a yield, or a BrahmWorks result.

Match the board in your hand to a build record: bare-board revision, assembly revision, bill of materials, and the firmware you intend to load, which may be a tiny bring-up image rather than the field image. If those four can disagree, label the unit so they cannot be mixed later.

Inspect before you measure. Look for reversed polarised parts, missing parts on the rails, solder bridges on fine-pitch devices, and a thermal pad that never saw paste. A microscope minute here is cheaper than a dead microcontroller that you will then blame on the silicon. Note rework. A unit that was already patched is not the same evidence as an untouched unit.

With power still absent, measure resistance from each rail to ground and between rails that must not be tied. Agree the floor for this board before you start, from the design, because a legitimately low-impedance rail can sit well below a textbook "open". The floor is a stop rule, not a universal constant. If the reading is below the floor, you do not apply power. You find the path.

Use a supply that can fold back or limit, set near the idle current you expect plus a margin you choose, at the first rail only. A limit set at several amperes does not protect a small board; it only protects the supply. Enable the first regulator, watch the current and the voltage, and confirm the rail is inside the window the parts on it require. Then the next rail, in the order the design specified. Skipping ahead because "it is probably fine" is how a sequencing bug becomes a burnt device and an unknown.

If the current limit trips, remove power and go back to the unpowered measurement. Do not raise the limit to win the argument. A limit that trips is a result. Write it down against the unit.

Only when the rails that the debug circuit needs are inside their windows do you connect the debugger. Confirm the clock that the core needs is running, then that reset is released, then that the tool can halt the core. Load the smallest image that can report identity and rail status. A full product image that immediately drives a transmitter, a motor or a large load is a poor first guest. It mixes too many failures in one LED.

Walk peripherals in an order that limits damage. A sensor's identity register before its calibration. A transceiver's idle current before a bus is tied to another product. A connector's pinout, checked against the cable, before a high-current load. Each step has a pass condition written beforehand: a voltage window, a register value, a current. "Looks okay" is not a condition.

Stop the session when something fails that stop rule. Leave the unit in the state that failed if that is safe, mark it, and do not quietly rework it into a different design while the log still describes the old one. Rework is allowed, and it is a new revision of that unit. The hardware product development process treats a result as attached to a named revision. Bring-up that reworks and backdates the log produces confidence you cannot trace.

Bring-up is not production test and not design verification. It asks whether this assembled article matches the design well enough to test further. It does not ask whether every unit can be built, and it does not ask whether the design meets the product's limits. Those questions need their own methods. Using three happy bring-ups as a substitute for either one is how a pilot starts on a wish.

Invented board: a 5 V load rail for a relay, a 3.3 V rail for a microcontroller and a transceiver, a 1.8 V rail for a digital block. The relay must stay undriven until firmware says otherwise. Teaching floors, agreed for this fictional design and not as a standard: each of the 3.3 V and 1.8 V rails must measure at least 200 Ω to ground unpowered, or the session stops. The 5 V rail's floor is agreed separately because the relay circuit may be lower; the point is that the floor was written before the probe touched the board.

The first image toggles no relay. It prints the revision and lets the debugger halt the core. Only a later image, on a unit whose rails already passed, may energise the coil.

Invented idle budget at first power, relay off, nothing transmitting:

• 3.3 V rail: core 8 mA, transceiver 2 mA, the rest under 1 mA, so 8 + 2 + 1 = 11 mA
• 1.8 V rail: 4 mA
• 5 V rail: 0 mA while the relay is off; the coil, if driven, would be a teaching 40 mA and is a bug if it appears now

Suppose the meter on the 3.3 V rail, in this lesson, sits at 80 mA and the voltage is still inside the window. Excess: 80 − 11 = 69 mA. That is not a dead short. A rough path resistance at the teaching rail voltage: 3.3 / 0.069 = 48 Ω. Look for a reversed part, a wrong resistor, or a bridge that is not a whisker of copper, not only for a direct short. The 48 Ω figure is arithmetic on invented readings so a founder can see why "it still reads 3.3 V" does not mean the rail is healthy. It is not a failure analysis of a real board.

If the supply were set to a teaching limit of 30 mA, this board would have folded instead of sitting at 80 mA cooking a part. The limit is doing the job only if it is near the budget. A limit of 500 mA would have hidden the lesson and kept the damage. Set the limit from the budget you wrote: for this rail, a teaching margin might be 11 mA plus 15 mA, so 26 mA, rounded to a setting the supply can actually hold. The margin is a choice. Write it down before you switch on.

The 5 V reading decides a different bug. Anything near the teaching 40 mA coil current, before firmware has driven the pin, means the relay is on by default. That is a schematic or a stuffing error, and it is independent of the 69 mA on the other rail. Two currents, two faults. Do not average them.

• Bare-board revision, assembly revision, BOM and intended image are labelled on the unit.
• Visual inspection is done, and any rework already present is noted.
• Unpowered rail floors are written from this design, then measured.
• A reading below a floor stops the session before power.
• The supply limit is set from the idle budget plus a written margin.
• Rails come up in the specified order, each checked before the next.
• A tripped limit is recorded, not raised.
• Debug is connected only after its rails are inside their windows.
• The first image does not start the heaviest loads.
• Each interface has a pass condition written before it is tried.
• Failures stay attached to the unit's revision; rework starts a new note.
• Nobody treats a bring-up pass as a production test or a design sign-off.

No. The first image should identify the unit, stay inside the rails you have just proved, and avoid transmitters, motors, heaters and writes to configuration you cannot replace. Production firmware comes after the board has shown it can run code. Loading it first turns every power fault into a software argument.

Do not start by replacing the microcontroller. Recheck the rail it uses, the reset level, the clock, the orientation of the connector, and that the tool is speaking the interface this part actually implements. A swapped debug pin and a dead core look the same from the laptop. The supply current, already written down, is the clue that separates them.

A named person, with the change written against that unit, including wires added and parts lifted. Anonymous rework produces a sample that no longer represents the assembly drawing, while the team continues to talk as if it does. If the rework is the design you now want, update the design. Do not leave the truth on a piece of enamel wire.

Bring-up is a careful, instrumented pass on early units to find design and assembly faults while you can still think. Production test is a repeatable procedure with limits, aimed at sorting later units. A bring-up notebook is not a fixture script. If a check was essential to decide the unit was safe, decide explicitly whether production must repeat it, in a simpler form, or whether the process now prevents the fault.

Bring the stop rules, the idle-current budget and the identity of the units as assembled. A review can say whether you have a board worth verifying, or only a board that happened to survive a cable.

Review the next stage with BrahmWorks