← Back to the learning library
Before you begin: Familiarity with digital and analogue interfaces, schematics and board bring-up. Read TFA-101 for ownership concepts.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Learning objectives
By the end of this module, you should be able to:
- Specify electrical and register-level behaviour needed by firmware.
- Control start-up, reset and power-state interactions.
- Design interfaces for diagnosability and test.
- Coordinate hardware changes with firmware evidence.
Lesson 1
1. Treat the boundary as a contract
Datasheets are inputs, not complete interface specifications. Agree signal polarity, units, tolerances, timing, pull states, register reset values, interrupt semantics and invalid conditions. Record what firmware may assume and what hardware must guarantee.
Lesson 2
2. Design start-up and power together
Define sequencing for rails, clocks, reset, boot straps, brownout and peripheral readiness. Firmware must know when outputs are safe to enable; hardware must establish benign states before software takes control.
Lesson 3
3. Make faults diagnosable
Expose status, test points and fault injection where proportionate. Distinguish open circuit, short circuit, stale data and communications loss. Avoid one undifferentiated error line when the system needs different responses.
Lesson 4
4. Control coupled changes
A component substitution, clock change or revised analogue range may invalidate firmware timing, conversion, thresholds or tests. Use shared interface baselines and joint impact analysis before releasing either side.
Lesson 5
5. Write the hardware–firmware interface record
For each signal, record its owner, direction, active level, reset condition, electrical constraints, timing and permitted modes. Include multiplexing, interrupts, DMA requests, clock dependencies and write-one-to-clear or read-to-clear register behaviour. These details can determine whether a driver is safe under concurrent use.
For analogue measurements, state the transfer function, units, offset, gain, saturation and uncertainty across supply, temperature and component tolerances. Firmware thresholds must distinguish a real physical condition from an out-of-range electrical failure. Agree how calibration is generated, stored, validated and associated with a particular unit.
Assign an interface revision and update authority. A schematic note is useful but may not capture operational sequences or firmware assumptions. Jointly review the contract before board fabrication and before firmware driver acceptance.
Lesson 6
6. Use bring-up to retire cross-disciplinary assumptions
Bring-up should proceed from safe power and clock behaviour through reset, debug access, memory and individual peripherals before full application operation. Establish current limits and benign outputs; do not let unfinished application code energise an actuator merely to prove communications.
Check reset causes, brownout thresholds, oscillator start-up and peripheral readiness. Firmware may start before an external device has completed its own power-on sequence. A successful cold boot does not demonstrate a rapid power cycle, watchdog reset or reset of only one component.
For an illustrative 12-bit ADC with a 3.3 V reference, one ideal step is about 0.806 mV. This resolution is not the measurement accuracy. Reference error, front-end gain, offset, noise and calibration uncertainty can dominate. Agree a system error budget before choosing software thresholds based on ADC counts.
| Bring-up question | Observation to retain |
|---|---|
| Output during reset | Pin level and actuator response before firmware ownership. |
| Sensor readiness | Time from valid power to valid first measurement. |
| Bus recovery | Behaviour after a stuck line or peripheral reset. |
| Board identity | How firmware distinguishes incompatible revisions. |
Lesson 7
7. Assess substitutions and fault diagnosability
A nominally equivalent component may differ in reset values, conversion latency, interrupt polarity, error flags or behaviour outside normal operating limits. Review the replacement against the interface contract, not just the purchasing description.
Design test access to verify open circuits, short circuits and stuck measurements safely. Identify whether the fault is injected before the analogue front end, at the ADC input or in a software abstraction. These tests answer different questions. Include sufficient measurement points to distinguish a firmware delay from an electrical settling delay.
Where a hardware safety mechanism is claimed to be independent, examine shared power, clock, sensor and output paths. A separate comparator using the same failed reference may not provide the assumed protection. Coordinate the analysis with the system safety owner and record firmware detection and response assumptions.
Decision guide
Where should a plausibility check live?
| Check | Best owner | Reason |
|---|---|---|
| Electrical range/status | Driver or hardware service. | Closest to peripheral semantics. |
| Physical relationship | Domain control. | Depends on product behaviour. |
| Independent shutdown | Separate safety mechanism. | Preserves fault independence. |
Worked example
Worked example — current-sense interface
ADC counts are converted differently across board revisions and saturation is not detected.
Hardware defines gain, offset, tolerance, valid range and revision identifier. Firmware applies revision-controlled conversion and distinguishes under-range, valid and saturated samples.
The interface is reviewable and board changes trigger focused regression evidence.
Engineering evidence
What should the work produce?
Hardware–firmware interface specification
Controls signals, registers, units and timing.
Start-up sequence
Defines power, reset and safe outputs.
Tolerance analysis
Justifies thresholds and conversion accuracy.
Joint change assessment
Links board changes to firmware impact.
Common failure patterns
What goes wrong?
- Assuming a peripheral is ready immediately after reset.
- Leaving units and tolerances implicit.
- Reusing a pin without firmware impact analysis.
- Providing no way to stimulate or distinguish failures.
Applied exercise · approximately 25 minutes
Review a replacement temperature sensor
A replacement sensor has the same address and units but takes 30 ms to produce its first valid reading instead of 5 ms. Its error value is a plausible low temperature. The existing controller enables heating 10 ms after reset.
- Identify why pin and protocol compatibility are insufficient.
- Define a revised readiness and validity contract.
- Choose cold-start, warm-reset and sensor-fault tests.
Review a suggested approach
The controller may interpret the sensor’s error value as a valid low temperature and enable heat too early. Define readiness through a trustworthy status condition or a justified start-up sequence, not only the numeric reading. Inhibit control until validity requirements are met; specify a timeout if readiness never occurs.
Test the longest specified start-up across relevant conditions, a reset of the controller without resetting the sensor and a reset of the sensor during active control. Observe the actual heater output and diagnostic response. Record the new component revision, driver assumptions and supported board/firmware combinations in the controlled interface and regression record.
Completion criteria
- Readiness and numeric plausibility are treated separately.
- Asymmetric resets are included.
- Evidence verifies physical output, not only a driver return value.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Are reset and power states safe?
- Are signal semantics and tolerances recorded?
- Can faults be detected and distinguished?
- Are board revisions identifiable to firmware?
- Do hardware changes trigger regression decisions?
Dependable firmware begins with a precise, testable contract at the hardware boundary.
References and further reading
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.