← Back to the learning library
Before you begin: TFA-101 to TFA-104. This role guide applies those concepts to a complete development change.
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:
- Define clear ownership and interfaces in firmware.
- Control timing, concurrency, memory and error behaviour.
- Design code for verification and diagnosability.
- Create evidence that explains the released implementation.
Lesson 1
1. Own behaviour, not only code
The firmware engineer translates system intent into executable behaviour. That includes states, timing, resource ownership, safe responses and diagnostics—not merely functions that compile. Clarify every assumption about hardware, scheduling and callers before implementation makes it implicit.
Lesson 2
2. Make constraints architectural
Allocate memory, stack, execution time, interrupt latency and queue capacity deliberately. Separate hardware access from product policy, keep asynchronous ownership explicit and define what happens on timeout, overflow, invalid data and reset.
Lesson 3
3. Build for observation and change
Expose stable diagnostic events, test seams and controlled interfaces. Avoid designs that can be understood only with a debugger attached. Configuration, generated code, libraries and compiler options are part of the product baseline.
Lesson 4
4. Produce engineering evidence
Link requirements and risks to design elements, code reviews and tests. Retain static-analysis results, timing measurements, anomaly decisions and the exact binary provenance needed to reproduce a release.
Lesson 5
5. Start a feature with an implementable contract
Before coding a feature, write down its inputs, permitted states, outputs, timing, resources and failure response. Ask systems engineering to resolve ambiguous behaviour and hardware engineering to confirm peripheral assumptions. A firmware engineer owns the implementation but should not silently make product-safety or user-workflow decisions.
For a new sensor, establish measurement units, calibration, age, validity and the effect of invalid data on control. Select an interface that communicates all of these properties. A function returning a floating-point value alone cannot distinguish a valid zero from unavailable data unless the contract defines an additional mechanism.
Turn the contract into acceptance tests before implementation. This reveals missing observability and helps separate a pure conversion function from peripheral access, scheduling and recovery. The resulting design should allow deterministic host tests while preserving target-specific verification.
Lesson 6
6. Use a disciplined daily engineering loop
Implement a small change, review it against the contract, run targeted analysis and tests, then integrate on representative hardware. Keep commits focused enough that another engineer can explain the behavioural change and associated evidence. Reviewers should see the reason for a change as well as the diff.
Debug systematically. State the expected behaviour, observed behaviour and smallest reproducible case. Identify the exact binary and configuration before investigating timing, memory or communication. Change one causal hypothesis at a time where practical; multiple speculative fixes can remove the symptom without identifying the fault.
When a race disappears under the debugger, examine timing and synchronisation rather than declaring it fixed. Use trace, hardware timestamps or bounded instrumentation. Record the cause and add a regression that would have detected it. Preserve limitations if a rare failure cannot yet be reproduced.
| Working interaction | Firmware contribution | Agreement needed |
|---|---|---|
| Systems | Executable state and error model. | Authorised behaviour and acceptance limits. |
| Hardware | Driver assumptions and measured timing. | Electrical semantics and board compatibility. |
| Verification | Test seams and diagnostic identifiers. | Independent oracle and coverage. |
| Release | Build identity and impact analysis. | Approved configuration and evidence. |
Lesson 7
7. Close the change beyond the source diff
A change may alter stack depth, worst-case latency, persistent schema, diagnostic codes or boot compatibility even when the feature is small. Use a short impact checklist to identify these effects and update the corresponding design records and tests.
Document implementation-defined dependencies such as register layout, integer width or atomic operations. Use narrow platform abstractions and reviewed exceptions rather than scattering them through domain logic. Third-party updates need the same integration discipline as locally written changes.
At handover, demonstrate the feature on the releasable configuration and explain its abnormal paths. Provide the binary hash, related requirements, test results, remaining anomalies and field-diagnostic interpretation. The role is complete when another engineer can review and maintain the behaviour, not merely when the original author can demonstrate it once.
Decision guide
What should drive an implementation decision?
| Decision | Primary driver | Evidence |
|---|---|---|
| Component boundary | Responsibility, change and test isolation. | Architecture and interface review. |
| Execution mechanism | Deadline, load and concurrency needs. | Timing budget and stress test. |
| Fault response | System risk and recovery policy. | Fault-injection result. |
Worked example
Worked example — asynchronous sensor service
Samples arrive in an interrupt while control logic and diagnostics need consistent values.
The ISR timestamps and queues bounded records. One service owns conversion and validity. Control code consumes an immutable snapshot; overflow produces a defined diagnostic and safe response.
Timing is bounded, ownership is clear and nominal and overflow behaviour can be tested independently.
Engineering evidence
What should the work produce?
Firmware design description
Explains components, behaviour and constraints.
Interface contracts
Define data, timing, errors and execution context.
Analysis and review records
Show coding, concurrency and timing checks.
Release provenance
Links source, tools, configuration and binary.
Common failure patterns
What goes wrong?
- Encoding product state in unrelated flags.
- Using volatile as the concurrency design.
- Hiding timeouts and retry limits in implementation constants.
- Treating a successful build as release evidence.
Applied exercise · approximately 25 minutes
Plan a sensor-rate change
A product requests an increase from 100 Hz to 400 Hz acquisition. The ISR queues raw samples, a task filters them, diagnostics write to flash and the existing queue has 32 usable entries.
- List the contracts and budgets that must be reassessed before changing the timer.
- Specify evidence for queue capacity, filter behaviour and diagnostic interference.
- Prepare a concise peer-review and handover checklist.
Review a suggested approach
The new rate changes arrival load, queue backlog, CPU use, data age, filter coefficients or time assumptions, communication throughput and possibly energy consumption. Verify sensor and bus capability with hardware engineering. Determine the longest consumer unavailability and sustainable processing rate; 32 entries alone says nothing without that model.
Use host tests to compare the filter against a reference response with the new sample interval. Stress target scheduling while flash diagnostics and communications run. Retain queue high-water marks, dropped-sample indicators and timing traces. The review should cover units, bounds, cancellation, invalid-data behaviour and backwards compatibility of exported data.
Completion criteria
- The change is treated as a system and timing change, not a one-line timer edit.
- The queue calculation includes worst-case consumer delay.
- The handover identifies tested configuration and remaining limitations.
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 hardware and system assumptions explicit?
- Is every shared resource owned and protected?
- Are worst-case paths bounded?
- Can abnormal behaviour be observed and tested?
- Can the released binary be reproduced?
Firmware engineering is ownership of observable product behaviour under real hardware and lifecycle constraints.
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.