Custom PCB Bring-Up Checklist: What to Test Before Running the Full Firmware

The assembled boards arrive. The full firmware is ready, the programmer is connected, and everyone wants to see the display light up. A better first milestone is less photogenic: establish what is fitted, what the rails and reset do, whether the target can be programmed, and which functions have been checked. Bring-up should reduce uncertainty before the complete application multiplies it.

This guide describes planning and recording a custom PCB bring-up. It is not a universal set of electrical limits or an instruction to energize hazardous circuits. The actual design needs an appropriate setup, qualified work, component information, and reviewed procedures. Industrial PCB development covers the full workflow; this article concentrates on the early evidence before normal firmware controls the assembled product.

1. Identify the board, assembly, and intended checks

Record the PCB revision, assembly variant, BOM, substitutions, rework, configuration, and relevant design documents. Identify which unit is under test. A prototype may contain temporary changes or unfitted options, and those details can explain an observation that otherwise looks like a schematic error. Keep the released design separate from the actual assembled state until they have been reconciled.

Prepare the check plan from requirements and design reviews. List expected measurements, operating limits, test points, instruments, connections, and conditions for stopping to investigate. The expected result should exist before the measurement. A number on a screen becomes much easier to rationalize after somebody has already announced that the board is probably fine.

Unit, PCB, and assembly identifiers:
Schematic, BOM, and rework baseline:
Supply and external connection arrangement:
Instrument and reference setup:
Expected checks and limits from the design:
Programming tools and software revision:
Observed values and result:
Issue, controlled change, and retest:
Remaining limitations before integration:

2. Review assembly and unpowered conditions

Check the assembled item against the intended variant using the applicable inspection and measurement methods. Relevant items may include component identity, orientation, soldering, connectors, fit, unfitted options, and known rework. Review accessible measurements against the circuit and component information rather than applying one resistance or continuity rule to every rail.

Account for connected equipment and unintended power paths. Programming adapters, interface cables, and other boards can influence the target even before its primary supply is enabled. Define those connections in the setup. A test described as unpowered should not secretly depend on which USB cable happened to remain attached.

BOM review helps identify part and substitution concerns. Harness design provides the connection references when the board interfaces to a larger assembly.

3. Establish a reviewed initial power arrangement

Use the design-specific supply arrangement, limits, protection, load conditions, and measurement plan. Where a controlled supply is appropriate, its settings must still follow the circuit requirements; a current limit is not a general guarantee against every hazard or component fault. Identify the expected startup behavior and what observation requires investigation before proceeding.

Measure the relevant rails and references in the intended sequence, including startup where the design requires it. Record input conditions, connected loads, firmware state, and instrument setup. A rail value without those conditions may be difficult to compare later. Unexpected demand, unstable behavior, or heating belongs in the issue record, not in a decision to try the full application and see whether it settles down.

4. Check reset, clocks, and boot conditions

Review the exact processor and supporting circuit requirements for reset, startup, boot selection, clocks, and memory where applicable. Identify the state of externally connected pins during startup. Do not assume that a compatible-looking variant has identical restrictions or that a successful programming connection establishes all operating conditions.

Use the selected manufacturer documentation and record what is verified on the board. Espressif's schematic and layout guidance illustrates the kinds of device-specific requirements that must be checked for an ESP32 design. Other devices require their corresponding documentation. The point is to validate the actual implementation, not collect an attractive library of reference links.

If a reset occurs, retain the cause information and setup. Switching-related reset investigation provides a broader hypothesis framework. Bring-up is easier when the earliest abnormal condition is documented before additional subsystems are introduced.

5. Establish programming and a minimal execution baseline

Confirm the supported programming interface, target identity, tool version, image, and configuration. Use a minimal, reviewed test image when it helps isolate a function from application complexity. Identify its expected outputs and restrictions. A diagnostic image should not activate machine loads merely because a generic example used the same pin number for an LED.

Prove the observations relevant to the next stage: connection, programming, execution, debug or diagnostic access as appropriate, and reset behavior. Record the source and binary relationship. A message appearing on a serial console can establish a useful milestone without proving memory configuration, peripheral behavior, or the complete application.

6. Check interfaces and outputs progressively

Introduce peripherals and external connections according to the plan. Define the stimulus, expected response, setup, and acceptable result for each interface. Start from understood conditions and use appropriate test arrangements for outputs and loads. Keep connected device versions and configurations visible so the same test can be reproduced.

An interface may need more than a loopback or one successful message. Addressing, timing, voltage behavior, load response, error handling, and startup interaction can all matter. Choose the evidence from the requirement. Industrial PCB requirements and communications selection help define what the test must establish.

Review sensors and actuators together with the physical system when the observation depends on a mechanism. A controller output changing state does not prove that a door unlocked or a product moved. That is an integration question to test at the appropriate stage.

7. Introduce the application with controlled operating modes

Once the relevant baseline is established, add application functions in a way that preserves diagnosis. Record firmware and configuration, simultaneous activity, communication, storage, and update behavior as applicable. Compare new observations with the minimal baseline without assuming every difference is a software defect or every reset is a board defect.

Use reviewed fault and interruption checks appropriate to the stage. Watchdogs and recovery and transaction state design show why restart and incomplete operations deserve explicit behavior. Do not treat a reset that returns to the first screen as proof that the physical process recovered correctly.

• Keep hardware, firmware, and configuration revisions together.
• Identify the new variable introduced by each stage.
• Retain abnormal observations before changing the setup.
• Distinguish diagnostic images from the intended application.
• Define what remains for integrated-machine verification.

8. Keep a bring-up log that supports a release decision

Record results, hypotheses, changes, and retests with enough detail for another engineer to interpret them. Mark temporary rework, restrictions, and affected documents. A board with a justified prototype patch may be useful, but the patch must not disappear from the design review because the unit now looks functional in a demonstration.

Classify what needs a design correction, assembly correction, configuration change, further investigation, or later verification. Review whether another unit or variant is affected. Production test planning can turn some lessons into repeatable manufacturing checks. Broader environmental or application evidence may still need a separate plan.

9. Decide what the bring-up has actually established

Review the completed checks, actual configuration, open issues, permitted use, and required next evidence. A successful bring-up can authorize integration work without establishing production readiness, long-term reliability, or every compliance requirement. Label the result accordingly. The prototype does not become a released product simply because it has survived the afternoon.

SolveMpire can discuss bring-up alongside custom electronics and firmware development. Share the design package, assembled revision, test access, intended interfaces, firmware state, and known observations. For the final transfer, the handover checklist helps ensure the evidence and usable source information remain with the project.