Embedded software should be designed around the actual device, its operating conditions and the person responsible for testing and updates. Start with a board-specific constraint sheet and a representative behaviour to verify. Keep module tests, device-level observations and the update path identifiable so a successful build can be assessed in the context where the software will run.
A small device may interact with sensors, storage, power and communications in ways that a desktop demonstration does not reproduce. List those dependencies before choosing a test approach. Use measured or manufacturer-documented values for the chosen target and mark unknown constraints as questions to investigate, rather than borrowing a memory or timing limit from another device.
The original device-and-update worksheet below uses a hypothetical monitoring unit. Narrow technical examples come from Zephyr’s testing and Device Firmware Upgrade documentation, retrieved on 24 October 2026. For application planning and system connections, see web development and business systems.
What belongs on the device constraint sheet?
Identify the exact board, processor variant, relevant peripherals and intended operating behaviour. Attach the applicable hardware documentation and the configuration used for the exercise. Describe what the unit must do when an input is missing or a connection is interrupted. These are proposed requirements for the sample unit, to be checked against the chosen target.
Keep capacity and performance questions specific. If the requirement depends on available storage, identify what will occupy it and how the actual image and data use will be measured. If it depends on timing, define the event and observation method. A clear measurement question helps the implementer choose a useful test.
Zephyr Ztest supports both integration testing and unit testing. Its test-framework documentation supplies examples for separating those levels. Choose which behaviour can be tested as an isolated module and which requires the device or a fuller system context.
Ztest provides assertion macros and a generic test structure. Use assertions to express the expected result of the selected module behaviour. Record the input, expected output and relevant configuration so the resulting evidence can be interpreted by another developer.
Which test environment produced the result?
Zephyr’s Twister tool can run selected test scenarios. Twister reports passed, failed, blocked and skipped cases. Retain those distinctions in the acceptance record. A test that did not run needs a different explanation from a test that exercised the intended behaviour successfully.
Zephyr’s unit_testing target builds an isolated native executable without the Zephyr kernel. Zephyr’s native_sim target includes the complete operating-system context in a host binary. These documented differences matter when interpreting evidence. Name the target and explain what the test setup represents before presenting the result as relevant to the actual board.
For the hypothetical monitoring unit, an isolated test could assess how a module interprets a sample input. A device-level exercise could then inspect the response using the chosen hardware and peripheral configuration. Write the expected relationship between these tests so a reviewer knows which requirement each addresses.
| Worksheet area | Proposed evidence | Owner’s question |
|---|---|---|
| Device identity | Exact board and configuration | Which target does this requirement describe? |
| Module behaviour | Inputs, assertions and results | What was exercised in isolation? |
| System context | Target, peripherals and observations | What environment produced this result? |
| Image preparation | Version and build configuration | Which firmware is being assessed? |
| Update transfer | Chosen delivery mechanism | How does the image reach the device? |
| Boot and recovery | Observed result and responsible role | Who checks the next boot and handles an exception? |
The worksheet is an original acceptance proposal. Use actual measured values and observations when the chosen target is available.
What does the firmware-update subsystem cover?
Zephyr DFU manages application images but not their transport protocols. Its Device Firmware Upgrade guide makes that boundary explicit. Identify the proposed transfer route separately from the image-management mechanism so the implementation brief covers both responsibilities.
Zephyr’s flash-image API simplifies writing firmware chunks to flash. Zephyr’s MCUboot API exposes image-version and boot-status information. Those are narrow documented capabilities to assess against the intended update design. Record which information the operator needs to identify the image and interpret the device’s state after the update.
Zephyr requires the appropriate flash partitions when using MCUboot. The chosen board and layout therefore belong in the update evidence. Have the implementer identify the relevant partition configuration and the intended application-image location before preparing a device exercise.
Assign update ownership explicitly. The person who prepares an image, the person who approves its use and the person who investigates an unsuccessful update may be different roles. Keep the image version, intended target and authorisation decision with the test record so the next operator can identify what was supposed to happen.
Include the application configuration in the version record alongside the source and image. Ask the reviewer to identify which build options matter to the tested behaviour and which peripherals are assumed. This makes a later comparison between two images more informative than comparing only their filenames.
Original monitoring-unit test and update exercise
For the hypothetical unit, choose a representative input-processing function and define its expected response to a normal value, a boundary case and a missing input. Use a separate test setup and fictional readings. Record the configuration and assertions that correspond to each proposed requirement.
Run the appropriate module tests when implementation is available, retaining the actual statuses and outputs. Then inspect the relevant behaviour in the agreed system context. Compare the observations with the written requirement and record environmental differences that still need investigation. This keeps the evidence useful without assuming that every host result proves board-level behaviour.
Next, prepare a firmware-update plan that identifies the image, target, transfer method, partition layout and responsible roles. Define the observation that should establish the expected boot result. Agree the safe test arrangement and recovery route before the exercise is performed, especially where the target contains important configuration or data.
After the update exercise, record the actual image and boot information available from the configured system. Have another authorised colleague use the record to identify the target, explain the result and locate the next action if an exception remains. Capture any missing evidence as a specific implementation requirement.
Use the sheet to assess the device constraints and maintenance responsibility together. A useful embedded-software brief should make the target, test meaning and update ownership understandable to the people who will maintain it. To discuss those requirements and the evidence still needed, get started with the worksheet and chosen hardware references.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.