Electronics Design AU

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

Bring-Up and Debug

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

Forum Discussions