Hardware–software integration
Bring the product together through controlled increments: prove power, clocks, interfaces and behaviours while faults are still local enough to diagnose.
After this module, you should be able to:
- Define testable hardware–software interface contracts
- Plan a safe and observable bring-up sequence
- Distinguish interface, configuration and timing faults
- Retain repeatable integration evidence
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-102, TEA-104 and TEA-107. You should understand the hardware–software interface contract.
Integration proves assumptions at the real boundary.
Hardware and software can each pass separate tests and still fail together. Integration exposes incorrect assumptions about pin assignment, polarity, voltage, reset state, clock source, timing, byte order, scaling, interrupt behaviour and ownership.
Make the first power-up deliberate and recoverable.
| Before bring-up | What to establish | Why it matters |
|---|---|---|
| Known configuration | Board revision, fitted options, component variants, firmware build, tools and calibration data. | Prevents debugging an unidentified combination. |
| Safe defaults | Inactive outputs during reset, boot and debugger halt; current-limited supplies where suitable. | Avoids unintended motion, heating or energy delivery. |
| Observability | Test points, debug port, console, logic analyser access, trace events and status indicators. | Makes internal assumptions visible. |
| Golden references | Known-good board, stimulus, load, cable, firmware and expected traces. | Separates a new fault from the test environment. |
| Bring-up firmware | Small, controlled tests for clocks, pins, memory and each peripheral. | Reduces interactions and shortens diagnostic paths. |
| Hazard controls | Energy limits, guards, emergency stop, supervision and prohibited tests. | Protects people, equipment and prototypes. |
Record expected measurements before applying power. A result is easier to interpret when voltage, clock frequency, current, signal polarity and acceptable tolerance were agreed in advance.
Integrate in vertical slices with objective gates.
- Inspect unpowered hardware. Check assembly, shorts, resistance and critical component orientation.
- Prove power and reset. Measure rails, sequencing, consumption, clock and reset behaviour before enabling loads.
- Establish control. Confirm programming, debugging, boot identity and a minimal diagnostic output.
- Exercise one peripheral at a time. Begin with safe interfaces, observe waveforms and force error paths.
- Close a low-energy loop. Connect one sensor-to-decision-to-output path with limited authority.
- Add realistic load and timing. Introduce concurrency, full data rates, actuators and environmental extremes incrementally.
- Exercise off-nominal behaviour. Disconnect, corrupt, delay, brown out, reset and recover under controlled conditions.
Worked example: SPI analogue front end
Software reports plausible but noisy measurements from a new board. The fault could exist in reference voltage, sensor bias, SPI timing, conversion-ready handling, byte order or scaling.
The team keeps raw ADC codes visible alongside engineering units. A known electrical stimulus separates analogue faults from conversion errors. Captured frames are compared with the interface contract, and the open-sensor test confirms that diagnostics survive the complete hardware–software path.
Turn bring-up learning into controlled product knowledge.
Order, dependencies, safety precautions, equipment, configurations, gates and responsibilities.
Schematic references, pin map, timing, data representation, units, tolerances and error behaviour.
Board and software identity, measurements, observations, traces, anomalies and conclusions.
Repeatable peripheral, loopback, production-test and hardware-in-the-loop procedures.
Symptoms, evidence, root cause, affected configurations, correction and regression coverage.
Permitted hardware, bootloader, firmware, calibration and configuration combinations.
Common failure patterns
Many new boards, drivers and behaviours appear together, making every symptom ambiguous.
Timing or initialisation works only when halted, single-stepped or powered through a debug probe.
Raw measurements disappear, so electrical, driver and scaling faults cannot be separated.
Key settings and fixes remain with one engineer and cannot be reproduced on the next build.
Plan bring-up as a sequence of evidence gates
Begin with a known board revision, assembly status and safe test setup. Inspect supply rails and reset behaviour before enabling high-energy outputs. Establish current limits and the permitted physical state. The purpose is to make each step explainable and reversible, with clear stop conditions.
Prove basic execution and observation before complex behaviour: clock, reset, debug access, a bounded diagnostic channel and a simple peripheral transaction. Then build a vertical slice from a physical input through the firmware to an observed output. A large feature bundle makes the first fault difficult to localise.
Keep bring-up firmware and production firmware distinct and controlled. Temporary pin toggles, bypasses and calibration constants can otherwise survive into a release. Retain what was changed, why it was safe for that experiment and how it will be removed or replaced.
Diagnose the boundary using competing explanations
When a sensor returns constant data, possible causes include a wiring fault, incorrect bus mode, an unstarted conversion, stale DMA memory or a parser error. Form a hypothesis and choose the cheapest discriminating observation. Rewriting the driver before observing the bus can destroy useful evidence without resolving the cause.
Compare electrical traces, register state and software events using aligned timing where possible. Be aware that probes load circuits and breakpoints change real-time behaviour. A debugger can also power a rail indirectly or prevent entry into sleep. Repeat the decisive observation under a representative configuration.
Record anomalies with board identity, firmware hash, fixture configuration, steps, expected behaviour and raw evidence. Convert a discovered interface assumption into a controlled specification and regression check, so the same lesson is not rediscovered on the next board.
| Gate | Evidence before proceeding |
|---|---|
| Power and reset | Rails, current, reset timing and safe output defaults. |
| Basic execution | Clock configuration and observable start-up progression. |
| Peripheral path | Correct electrical transaction and interpreted data. |
| Physical loop | Measured input-to-output behaviour within agreed bounds. |
| Fault response | Injected failures produce the required physical state. |
Control compatibility across board revisions
A replacement component can change timing, start-up, voltage thresholds, fault indications or endurance even when nominal function is unchanged. Define a compatibility matrix linking hardware, firmware, bootloader, calibration and configuration versions.
Make unsupported combinations detectable before operation where feasible. A board-identification value should have an invalid or unknown case; treating every unknown board as the first revision hides errors. Test both accepted and rejected combinations, including a recovery image or service tool that may contain an older compatibility policy.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Investigate a sensor that works only with the debugger
The release firmware intermittently reads zero after power-on. Stepping through initialisation makes the sensor work. A new board revision uses a replacement sensor.
- List three hypotheses that explain the timing sensitivity.
- Choose observations that distinguish them without relying on breakpoints.
- Define the controlled change and regression evidence after finding the cause.
Show the worked answer
Plausible hypotheses include inadequate power-on settling, incorrect conversion-ready handling and a reset or bus transaction arriving before the sensor is available. Debugger timing can mask all three. Capture supply, reset and bus activity with a power-cycle trigger, and log bounded time-stamped initialisation events. Compare both board revisions under the same conditions.
If the replacement requires a longer readiness sequence, implement the documented state and timeout behaviour rather than an unexplained delay that happens to work. Test repeated cold and warm starts, supply extremes and a sensor that never becomes ready. Update the interface contract and compatibility matrix, and retain traces with exact board and firmware identity.
Review criteria
- Hypotheses span electrical and software causes.
- The decisive evidence does not depend on stepping.
- The fix covers failure as well as successful initialisation.
Check your understanding
Why is a vertical slice useful during bring-up?
It proves one complete physical path with limited complexity, making incorrect cross-boundary assumptions easier to isolate.
Is a pin-compatible component automatically compatible?
No. Electrical limits, timing, reset behaviour, diagnostics and lifecycle characteristics can differ.
Further learning
- NASA Systems Engineering HandbookProduct integration, verification, configuration and technical risk across the system lifecycle.
- Arm CMSIS-Driver documentationStandardised software interfaces for common microcontroller peripherals and middleware.
Integrate in observable, reversible increments.
Successful hardware–software integration depends on explicit interface contracts, safe bring-up, known configurations and evidence that isolates each new behaviour and fault.