Skip to main content

5.4 Functional Test Design

Power-on safety, golden units, firmware load, and parametric verification—so the board behaves like a product, not just a collection of parts.

Functional test (FCT) is the production gate that proves a board behaves like the intended product, not just a pile of correctly soldered parts. It starts with safe, controlled power-on—using current-limited supplies, sequenced rails, and I/O protection—before firmware is loaded and key features are exercised. Golden Units (known-good boards) anchor trust in the tester, verifying its integrity at shift start and after any change. The test flow should fail fast on basic health checks, then run only a few high-value use-case paths, with programming ideally done earlier in the process to keep FCT time inside TAKT. Measurements focus on customer-critical parameters—like rail stability, communication link health, and key sensor readings—using guard-bands that account for test uncertainty. With complete logging, disciplined calibration, and modular fixtures, FCT becomes a stable, efficient checkpoint that catches real functional risks without slowing the line.

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)

  1. Smoke check: power-off shorts/opens on main rails (mΩ or isolation test).
  2. Soft power-up: enable primary rail → measure inrush/steady current.
  3. Secondary rails: enable in order; verify voltages, ripple, and reset timing.
  4. Safe state pins: force drivers off, H-bridges idle, backlights/RF disabled.
  5. 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.

Area

Typical checks

Notes

Power

Rail V/I at idle & one load point; ripple; POR timing

Guard-band to measurement uncertainty

Clocking

Main osc ±ppm; PLL lock

Short gate time; pass/fail, not a thesis

Digital I/O

GPIO wiggle; LED on/off; button reads

Quick loop; record response times if critical

Comms

USB/Eth link up; ping/loopback; serial echo

Log link speed/PHY ID; MAC/SN set

Sensors/ADC/DAC

2–3 calibration points via simulators

Linear spot-check, not full INL

Audio (if any)

THD+N at 1 kHz; gain

Use known load/attenuators

RF (if any)

Output power/EVM/channel mask (lite)

Use shielded box/attenuator; or sample offline

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

Pain

Why it happens

First fix

Random FCT fails

Flaky cables/ground loops

Shorten grounds; replace suspect harness; add ferrites

Brown-outs on power-up

Loads enabled too early

Delay loads; raise PSU current limit carefully

Tester “passes anything”

Limits too loose / drift

Re-run GU; restore limits from repo; recal instruments

Long test time

Doing lab work in production

Trim to fail-fast; sample deep tests; move programming upstream

Intermittent comms

Fixture strain on connectors

Add strain relief; reduce mating cycles; use better guides

ESD zaps DUT

No discipline at station

Add mats/straps; bond tester chassis; ESD audits



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)



Bottom line: make power-up safe, keep a Golden Unit as your compass, program firmware deterministically, and measure a short list of customer-meaningful numbers with guard-bands you can defend. Log it all, maintain the tester like equipment (not a pet project), and FCT will be quick, calm, and trusted.


Back to top