5.4 Functional Test Design
Functional test is the point where a board stops being a set of assembled parts and must prove it behaves like the finished product. Unlike structural tests, which catch build defects, FCT validates power sequencing, firmware operation, and critical use-case paths under controlled conditions. Golden Units anchor trust, while disciplined power-on safety and guard-banded parametrics keep both boards and operators safe. By trimming scope to only customer-relevant checks and logging results rigorously, FCT balances assurance with speed, avoiding the trap of turning production into a lab experiment.
5.4.1 What FCT is (in plain words)
Functional test (FCT) answers: “Does this board actually work?” You’ve already caught most build faults with ICT/Probe/BSCAN/AOI/AXI. FCT powers the PCA safely, loads the right firmware, talks to its interfaces, nudges peripherals, and checks a short list of parametrics that matter to the customer.
Mindset: fail fast on basics (power, ID, clocks), then prove a few use-case paths—not a full lab characterization.
5.4.2 Power-on safety (protect the DUT and the humans)
Before any code runs, make turn-on boring and safe.
Hardware
- Current-limited supplies for each rail; per-rail fast cut-off.
- E-stop and interlocks: no power unless clamps closed / fixture safe.
- Series safety on I/O to the outside world: resistors or buffers so you can’t drive a customer port into a short.
- Loads you control: electronic loads or resistor banks with relays, not improvised heaters.
Sequence (always this order)
- Smoke check: power-off shorts/opens on main rails (mΩ or isolation test).
- Soft power-up: enable primary rail → measure inrush/steady current.
- Secondary rails: enable in order; verify voltages, ripple, and reset timing.
- Safe state pins: force drivers off, H-bridges idle, backlights/RF disabled.
- Only then run firmware.
If any step fails, drop power and flag NG. Don’t “retry until it works.”
5.4.3 Golden Units (GU) & reference artifacts
A Golden Unit is a known-good DUT you trust more than your tester.
- Keep two GUs: one for electronics, one for mechanics/fit (if your fixture mates connectors).
- Stamp each with firmware version, calibration constants, and a service life (# of runs or months).
- Run a GU pass at the start of each shift and after any tester change (code, cables, instruments). If the GU fails, stop—fix the tester first.
- Retire GUs on a schedule; store their last passing logs.
Other artifacts: loopback dongles, attenuators, sensor simulators, and a “fixture self-test coupon” that proves switching and measurement channels without a DUT.
5.4.4 Firmware load & configuration (fast, deterministic)
- Prefer programming earlier (BSCAN/ICT) to keep FCT short. If FCT must program:
- Use a signed, versioned image; verify hash after write.
- Provision SN/MAC/keys atomically with the image; store them in the log.
- Control VTREF/reset/boot pins from the tester; isolate shared buses (e.g., SPI flash vs MCU) with series resistors or tristate.
- Time budget: programming must fit TAKT or be off-line/batched.
5.4.5 Tester architecture (blocks that scale)
Stimulus → DUT → Measurement
| | |
PSU/Loads Firmware DMM/DAQ/Scope/RF/Audio
Switches Drivers Matrix/Relays
Switch matrix/relays route signals and loads; default to safe.- Instruments: PSU + DMM as the core; add DAQ/scope for timing, SMU for precision, audio/RF only if your product needs it.
- Protocol boxes: USB/Ethernet/CAN/LIN/I²C/SPI/UART masters to exercise ports and sensors.
- Simulator fixtures: sensor emulators (thermistors, bridge sensors), loopback plugs, and dummy antennas/attenuators.
Keep it modular: swap a box, not the entire tester.
5.4.6 Parametric verification (measure what matters)
Pick a few numbers that prove function without killing TAKT.
Guard-banding: set limits wider than customer spec by your uncertainty and drift. If spec is tight, calibrate instruments more often or sample deep tests.
5.4.7 Time & coverage (hit TAKT)
- Fail fast: shorts → rails → ID → clocks → comms → the one or two use-case paths.
- Parallelize independent waits (e.g., gather multiple rails in one DAQ sweep).
- Skip logic: if a port isn’t populated on this variant, don’t test it.
- Sampling: heavy RF/audio tests on N-of-M boards if allowed; 100% on critical safety paths.
5.4.8 Data & traceability (make results useful)
Log everything needed to reproduce decisions:
- Board SN, work order, date/time, station ID, tester software rev, instrument cal due dates.
- Firmware image ID/hash, keys/MAC/SN burned.
- Raw readings + limits used + pass/fail per step; graphs only when needed.
- Attach plots (e.g., power-up current vs time) for golden runs.
- Push records to MES; block pack-out if no record.
5.4.9 Tester care: calibration & self-health
- Daily: fixture visual check, connector clean, GU run.
- Weekly: switch/matrix self-test with coupon; cable wiggle check.
- Monthly/Quarterly: instrument calibration (per cert), PSU foldback trip tests.
- Spares: one fully imaged hot-swap PC, spare key cables/relays/instruments.
- Version control: tests are code—git them; tag releases that shipped product.
5.4.10 Common pitfalls → quickest fix
5.4.11 Pocket checklists
Design (before you build the tester)
- Power-on sequence defined; rails/current limits chosen
- Golden Unit(s) identified; sensor/loopback simulators listed
- Firmware image & provisioning plan (keys/MAC/SN) fixed
- Parametric list trimmed to customer-meaningful items
- Data schema agreed (fields, limits, attachments)
Bring-up (first week)
- GU passes end-to-end; failure of GU blocks lot
- E-stop/interlocks verified; default state is safe/off
- Programming time within TAKT; hash verified
- Logs land in MES with all IDs
Daily run
- GU at shift start; fixtures clean; cables seated
- Fail-fast sequence intact; no “retries until pass”
- Top 3 failure codes reviewed; obvious process drifts routed upstream (print/reflow/placement)