diptrace-board-bringup

Read runtime access before selecting tools or declaring a capability unavailable. MCP tools and native/headless CLI are separate interfaces.

DipTrace board bring-up and production test

RAG: engineering memory by default — shared workflow. Use indexed measurement, circuit and bring-up material to derive the test sequence, probe strategy, limits and fault-isolation plan for this exact board.

Use the exact schematic/PCB, fitted BOM, component rules, release evidence, and firmware revision. Planning produces a procedure; a physical test passes only from actual observed measurements. Do not energize or flash hardware from a planning request.

Prepare the procedure

1. Resolve board revision and unit/serial identity, assembly/rework state, available instruments, supply, programming interface, and requested mode: plan or guided run. Check pinouts and testpoint nets from the actual design; do not reuse another board's connector order.
2. Read rules/ and the project specification. For every measurement define the condition/load, probe points and reference, method, expected range/tolerance, source/calculation, and stop condition.
3. Derive supply voltage, initial current limit, rail/startup expectations, and thermal limits from this design and the instruments. Leave unknown values unresolved. Never choose a universal current limit or infer a short from a generic resistance threshold. Inspect low-resistance rails and charging capacitors in context.
4. Plan access to power/GND, reset/boot, debug, and representative interfaces. If PCB changes are requested, use testpoint-planner and an ECO; existing connector access may suffice. Do not load sensitive RF, crystal, high-impedance, or fast nets with an unspecified probe or long stub.

First article sequence

1. Unpowered inspection: correct parts/variant, orientation/polarity, solder bridges, connector mating, exposed pads, missing/DNP parts, and known assembly defects.
2. With power removed, check ground and supply continuity/resistance and isolation required by the design. Account for capacitors and parallel semiconductor paths.
3. Power from the specified current-limited source using the approved connection sequence. Observe input current, rails, sequencing, reset, and heating. Stop and remove power on a defined limit violation, unexpected heating, or abnormal behavior; record the fault before retrying.
4. Use the exact target/programmer and verify device identity before flashing. Record firmware hash, boot configuration, programming/verification results, and logs. Mass erase, irreversible fuses, and security provisioning require their own scope. Use an installed flashing/serial tool only after discovering its actual capability.
5. Exercise one subsystem at a time, then combined loads and interfaces. Test RF last when present. Compare measurements with the planned bounds; a missing instrument leaves that test NOT_RUN, not PASS.
6. For failures, preserve logs and measurements, isolate the owning subsystem, and record any physical rework as an ECO through diptrace-revision-review.

Records and repeatable production test

Create/update BRINGUP.md with the procedure and append actual runs to TEST_RESULTS.csv: unit, hardware revision, firmware hash, timestamp, test/conditions, expected range, measured value/unit, result, instrument, and evidence path. Keep planned values separate from measured values.

After first-article validation, write PRODUCTION_TEST.md with fixture pin map and access, power/flash/test order, limits derived from specifications and observed validation, calibration needs, cycle time, serialization, pass/fail handling, and rework retest rules. Include environmental, EMC, reliability, or safety qualification only when applicable to the specification; bench success does not certify those categories. Fixture contact/access must be physically validated, not inferred from a CAD grid.

Return the procedure, actual results, failing or unrun tests, and the next concrete measurement. If no hardware/instruments are available, finish the plan and report that physical acceptance remains unverified.

Return the shared result; use document: null when no CAD document is involved. Record concrete artifacts and unavailable checks; a completed plan is not physical or manufacturing acceptance.