What programming and test fixture details should be in a PCBA RFQ?

Direct Answer

A PCBA RFQ should include programming interface, physical access, boot or reset state, target power assumptions, firmware artifact and revision control, programming verification, fixture ownership, functional-test sequence, pass/fail limits, retest rules, and required logs before programming or custom fixtures are priced.

Decision Model

Quote-ready programming and fixture scope = target interface + physical access + power/reset/boot state + controlled firmware artifact + verification method + fixture owner + test sequence + pass/fail limits + retest and evidence rules.

Why It Matters

Turn firmware programming, debug access, fixture ownership, functional-test limits, and shipment evidence into quote-ready handoff inputs. Late discovery changes cost, schedule, yield, or acceptance evidence after engineering and procurement have already made assumptions.

Engineering Principles

• Programming is a manufacturing operation only when the interface, access, target power state, boot mode, firmware artifact, and verification expectation are visible before quote.
• A test fixture is not a generic accessory; it encodes electrical access, mechanical support, operator flow, safety assumptions, test software, limits, records, and maintenance ownership.
• Keep firmware debugging separate from production acceptance: the RFQ should define what the supplier must program and verify, not ask the assembler to infer product behavior from prototype notes.

Example

An STM32 sensor board should state SWD or bootloader access, pad or connector location, BOOT and reset assumptions, firmware image and version, target voltage during programming, serialization needs if any, FCT steps, measurement limits, fixture ownership, and shipment log requirements.

Comparison

• ICT or flying probe checks electrical conditions when access and programs are defined; programming loads or configures firmware; FCT verifies powered product behavior against supplied limits.
• A connector-based programming method may be enough for prototypes, while repeat builds often need fixture access, controlled firmware revision, verification logs, and retest rules.
• A quote that excludes fixture design can be valid only if the buyer supplies the fixture, test software, limits, and acceptance evidence path.

RFQ Inputs

• Exact programmable device part number, package, programming method, interface, pad or connector access, boot mode, reset line, clock dependency, and target voltage or power sequence.
• Firmware image, version, checksum or release identifier, programming options, serialization or key-injection needs if any, verification step, and owner of firmware updates.
• Fixture ownership, mechanical access, pogo-pin or connector map, ESD and power assumptions, operator steps, test-program owner, calibration or golden-board assumptions if used, and maintenance responsibility.
• Functional-test sequence, measurement points, pass/fail limits, sampling or 100% test expectation, retest and rework rules, required logs, labels, serialization records, and shipment evidence.

FAQ

Is firmware programming always part of PCB assembly?

No. It is part of assembly scope only when the RFQ asks the supplier to load or verify firmware and provides the interface, access method, firmware artifact, target state, and acceptance evidence.

Can the assembler design the test fixture from the PCB files alone?

Usually no. PCB files show electrical access, but fixture design also needs product behavior, connector use, power state, operator flow, limits, software ownership, logging, retest rules, and mechanical constraints.

What should be controlled when firmware changes after quote?

Treat it as a release change. Update the firmware artifact, version or checksum, programming options, verification method, test limits, logs, and responsibility for reprogramming or retesting affected boards.

Source Notes

• STM32 programming handoff boundary - STM32CubeProgrammer programming tool (semiconductor_vendor).

Source fact: ST presents STM32CubeProgrammer as an official tool for reading, writing, and verifying STM32 device memory through debug interfaces such as JTAG/SWD and bootloader interfaces such as UART, USB DFU, I2C, SPI, or CAN. Omini interpretation: Use this to require the RFQ to name programming interface, access method, boot mode, reset and power assumptions, firmware artifact, verification expectation, and any serialization or security step before PCBA programming is quoted. Allowed usage: Use on programming, STM32, fixture, FCT, PCBA RFQ, and production-test handoff pages.

• PCBA release package completeness boundary - IPC checklist for producing rigid printed board assemblies (standard).

Source fact: IPC publishes a public checklist for producing rigid printed board assemblies that frames fabrication, assembly, BOM, inspection, and test inputs as a build-package completeness problem. Omini interpretation: Use this to require a prototype-to-production handoff to expose Gerber or ODB++, BOM, centroid, assembly drawing, revision, inspection scope, and test expectations before pilot build. Allowed usage: Use on RFQ readiness, PCBA quote scope, prototype-to-production, and release package pages.

• Design-to-manufacturing data exchange boundary - IPC-2581 printed board assembly products manufacturing description data transfer (standard).

Source fact: IPC-2581 is a printed-board design-to-manufacturing data-transfer standard for describing fabrication and assembly product data. Omini interpretation: Use this to frame production handoff as structured manufacturing data, not a collection of informal screenshots, emails, and prototype notes. Allowed usage: Use on release package, fabrication handoff, assembly handoff, and prototype-to-production pages.

• Electronic manufacturing traceability boundary - IPC-1782 standard for manufacturing and supply chain traceability of electronic products (standard).

Source fact: IPC-1782 is a source boundary for manufacturing and supply-chain traceability of electronic products. Omini interpretation: Use this to explain why repeat builds should name lot traceability, approved alternates, revision ownership, and shipment evidence before the process leaves prototype mode. Allowed usage: Use on traceability, production handoff, regulated-product readiness, BOM control, and NPI pages.

• ICT manufacturing test boundary - Keysight in-circuit test for manufacturing (manufacturer).

Source fact: Keysight presents in-circuit test as a manufacturing test method for assembled boards, focused on detecting assembly faults and verifying circuit-level conditions. Omini interpretation: Use this to require explicit ICT access, fixture readiness, net coverage, program ownership, and pass/fail evidence when a PCBA quote includes ICT. Allowed usage: Use on SMT inspection, PCBA quote scope, ICT, DFT, and production-test handoff pages.

• PCBA functional test automation boundary - NI PCB Assembly Test Toolkit (manufacturer).

Source fact: NI publishes PCBA test automation resources for electrical functional test workflows and test-station development. Omini interpretation: Use this to separate inspection from functional test: FCT needs fixtures, firmware state, measurement steps, limits, and a pass/fail handoff defined before quote. Allowed usage: Use on functional test, PCBA quote scope, programming, fixture, and production-test handoff pages.

• Configuration and review handoff boundary - NASA Systems Engineering Handbook (government).

Source fact: NASA systems engineering guidance treats configuration management, technical baselines, and readiness reviews as controls for moving work between lifecycle states. Omini interpretation: Use this as conservative framing for PCBA revision control: production handoff should freeze the files, assumptions, acceptance evidence, and change path that a repeat build depends on. Allowed usage: Use on NPI, prototype-to-production, revision control, release package, and production handoff pages.

• Existing OminiPCB repository content (internal): May seed structure and internal links; engineering claims still need external verification when specifications are involved.

CTA

Request a PCB quote when the design files and acceptance requirements are ready for engineering review.