Testing
Hardware validation, automated test, and debugging methodology.
Hardware testing and validation bridges the gap between a completed design and a product that reliably does what it is supposed to. Testing starts before the first prototype (design review, simulation) and continues through bring-up, integration, environmental screening, and production test. Understanding which tools to use, how to use them effectively, and how to structure a validation plan separates engineers who find bugs early from those who find them in the field.
What Is Hardware Validation?
Hardware validation is the systematic process of verifying that a design meets its specifications:
- Bring-up testing — the initial power-on sequence for a new PCB: verifying supply rails, checking for shorts, and progressively loading the board to test each subsystem.
- Functional verification — exercising every feature of the design against its specification.
- Debug — diagnosing unexpected behaviour using measurement instruments and test methodology.
- Environmental testing — verifying performance over temperature, vibration, humidity, and other environmental factors relevant to the application.
- Production test — the in-manufacturing test that gates whether each assembled board passes to the next stage; often implemented as ICT, flying probe, or functional test.
Why Testing Methodology Matters
Random probing with an oscilloscope is not a test methodology. Effective hardware validation:
- Is systematic — follow the signal path from source to destination rather than measuring at random points.
- Uses the right instrument — an oscilloscope is appropriate for analog signals and fast transients; a logic analyser for digital protocol decoding; a multimeter for DC voltages and resistance.
- Proceeds from known-good to suspect — verify power rails first, then clocks, then digital communication, then application-layer behaviour.
- Documents findings — a test that cannot be reproduced and whose results are undocumented is not a test; it is a measurement that may be forgotten.
Key Concepts
- Oscilloscope — measures voltage over time with high bandwidth and sample rate. Used for analog signals, transient events, switching waveforms, and verifying digital signal quality. Key settings: vertical scale, timebase, trigger, probe bandwidth.
- Logic analyser — samples digital signals at high speed and decodes them as protocol data (SPI, I2C, UART, etc.). Better than an oscilloscope for multi-channel digital protocol debugging.
- Multimeter — measures DC/AC voltage, resistance, and current. First instrument to use when powering on a new board — measure supply voltages before connecting logic.
- JTAG/SWD debugger — connects to the MCU's debug interface to set breakpoints, inspect registers, and step through firmware. Essential for firmware debugging.
- ICT (In-Circuit Test) — production test method using a bed-of-nails fixture to verify component values and connectivity at every node simultaneously.
- Flying probe test — moves probes to specific test points to measure connections and component values; slower than ICT but requires no custom fixture.
- DUT (Device Under Test) — the board or system being tested.
Common Tools and Software
- Oscilloscope — Rigol DS/MSO, Siglent SDS, or Keysight DSOX series cover most embedded electronics work. Key specs: bandwidth matching the signal frequency range, adequate sample rate (typically 5× bandwidth minimum), and isolated probes for floating measurements.
- Logic analyser — Saleae Logic (USB, excellent software with protocol decode for SPI, I2C, UART, CAN, and others), Rigol LA5000 (benchtop with larger channel count). Prefer a logic analyser over an oscilloscope for any work involving protocol-level debugging.
- Multimeter — a basic digital multimeter is the first instrument to use on any new board. Fluke 87 series, Brymen, and BM235 are well-regarded mid-range instruments; a CAT III rating is important if measuring at mains voltages.
- Bench power supply — a supply with an adjustable current limit is essential for safe bring-up of a new board. Set the current limit to slightly above expected idle current before the first power-on.
- Debug probes — J-Link (SEGGER), ST-Link V3 (STM32), CMSIS-DAP compatible probes (open-source, inexpensive); connected to the MCU's SWD or JTAG port for on-target firmware debugging.
- Current analyser — Nordic PPK2 (nRF-focused but USB-compatible), Otii Arc, or a current-sensing oscilloscope setup for measuring instantaneous and average current consumption over time.
Common Mistakes
- Probing at random rather than following a systematic path — begin every debug session with a hypothesis, work from known-good to suspect, and verify each section of the signal path in turn. Random probing generates data without insight.
- Checking the firmware before the power supply — a surprising proportion of firmware problems are actually power supply problems. Verify every supply rail is at the correct voltage and stable before assuming firmware is at fault.
- Loading a high-impedance node with a standard oscilloscope probe — a 10 MΩ probe loads high-impedance nodes (high-gain op-amp circuits, high-impedance sensor interfaces) and alters the circuit behaviour. Use a high-impedance active probe when measuring sensitive analog nodes.
- Missing test points in the PCB layout — test points for critical nets are required for ICT, flying probe, and bring-up. Adding them retrospectively results in crowded placements or none at all. Plan test point coverage during layout.
- Declaring the board working before testing edge cases — a board that works correctly at room temperature on a clean bench supply may fail at temperature extremes, under actual power supply ripple, or during simultaneous load on multiple subsystems. Test at the boundaries of the operating envelope before releasing a design.
Common Questions
Oscilloscope or logic analyser for debugging I2C communication?
Use a logic analyser when you need to see the actual I2C data — addresses, register values, ACK/NAK, and protocol sequencing. A logic analyser decodes the protocol into readable frames, making it far more useful than an oscilloscope for diagnosing application-layer communication failures. Use an oscilloscope when you need to look at signal quality — edge rates, noise, ringing, or bus voltage levels — rather than data content. Most I2C debugging benefits from having both.
What is the first thing to do when a new PCB behaves unexpectedly?
Check the power supply rails with a multimeter before touching anything else. Verify that every supply is at the expected voltage. Then check the current consumption: if it is significantly higher than expected, there is likely a solder bridge or damaged component. Check for solder bridges around fine-pitch ICs under a microscope or with a loop. Then verify the clock is running (oscilloscope at the MCU's crystal pins) before assuming a firmware problem. See the PCB bring-up checklist for the complete systematic process.
How do I set up for production test?
Define test coverage requirements early and design test points into the PCB for all critical nets. For high-volume production, invest in an ICT fixture or build a custom functional tester with a bed-of-nails interface. For lower volumes, a flying probe test covers component placement and value verification without a fixture, complemented by a functional test that exercises the application software. Zeus Design supports prototype bring-up and production test strategy for commercial hardware projects.
Knowledge Base
Measurement Instruments
- How Does an Oscilloscope Work and What Can It Measure? — trigger modes, probe bandwidth, timebase, AC/DC coupling, and when to use each setting
- Logic Analyser vs Oscilloscope: Which Should You Use? — when each instrument is appropriate, protocol decoding, and combining both for complete debug coverage
- How Do You Use a Multimeter for Electronics Work? — voltage, current, resistance, continuity, and diode check modes; safety and probe technique
Bring-Up and Debug
- PCB Bring-Up Checklist: First Power-On for a New Board — the systematic first power-on process: pre-power checks, current limiting, supply verification, and progressive subsystem testing
- How Do You Debug Embedded Firmware? — JTAG/SWD debugging, printf tracing, SWO, and systematic fault isolation strategies
Debug Interfaces
- What Is JTAG? — TAP state machine, boundary scan, JTAG chains, FPGA programming, and how JTAG compares to SWD for ARM Cortex-M debugging
- What Is SWD (Serial Wire Debug)? — ARM's two-wire debug protocol, CoreSight access, SWO trace, debug probe selection, and connector footprint options
Production Test
- How Is a PCB Assembly Tested and Inspected? — AOI, X-ray, ICT, flying probe, and functional test; choosing the right combination for your volume and requirements
Forum Discussions
Scope showing 200+ mV spikes on my 3.3V rail — is this real or a probe problem?
Probing the 3.3V output of a switching regulator on a new board and I'm seeing large spikes on the scope that don't make sense to me. The wa
STM32 USB not detected by Windows after jumping to bootloader mode
Working on a custom STM32F411 board, trying to jump into the built-in USB DFU bootloader from application code instead of holding BOOT0 on p