MCU Firmware Outsourcing: What to Put in the Acceptance Requirements

An outsourced MCU firmware project is ready for acceptance when another engineer can build it, flash it, exercise the agreed interfaces and explain its behavior during failures. A successful demonstration is useful, but it does not define what will happen after a sensor disconnects, a configuration write loses power or a network stays unavailable.

This guide proposes an acceptance structure for resource-constrained MCU products, including bare-metal and RTOS designs. It is an engineering checklist, not a claim that a particular board has passed these tests. Safety-related products need their own hazard analysis, development process and applicable regulatory review.

1. Freeze the boundary before freezing the price

Start with a configuration sheet identifying the MCU part and revision, board revision, clock sources, external memories, peripheral modules, toolchain, SDK and RTOS version. List the actual external devices and protocol documents. “RS485 support” identifies an electrical interface; it does not specify baud rate, direction timing, register mapping, retry policy or application interoperability.

Divide the scope into required features, explicit exclusions and assumptions that another party must satisfy. If the customer provides an existing bootloader, identify its image format, memory reservation and update contract. If hardware is still changing, state which board revision is the acceptance target and how later pin or component changes will be evaluated.

Give every requirement a stable identifier and an observable result. “Reliable collection” is too open-ended. A better requirement names the input frame, expected decoded value, allowable reporting delay, behavior on a checksum error and how the test observer will obtain evidence.

2. Define the data path from pin to application

For each interface, document physical settings, message framing, timeouts, ownership and error behavior. An acquisition product should make it possible to compare the source instrument reading, received bytes, decoded engineering value and outgoing application payload for the same sample. Include units, scaling, signedness, invalid-value representation and timestamp origin.

Write down what happens when producers run faster than consumers. A queue can reject the newest item, discard the oldest item, block a task or trigger a fault. None is universally correct. The acceptance requirement must choose a policy and expose a counter so that silent data loss is distinguishable from a quiet input.

Likewise, distinguish transport delivery from application completion. A command acknowledgment should identify whether it means “parsed,” “accepted” or “executed.” If a retry could operate a relay twice, agree an idempotency or sequence-number rule and test a duplicate command deliberately.

3. Make timing and memory limits measurable

Choose timing limits from the product’s needs rather than copying a familiar tick period. Specify the stimulus edge, measurement point, permitted load and acceptance statistic. For example, measure input-to-output response with a logic analyzer under concurrent communication traffic. Record observed worst case separately from any analytical bound; a finite test does not prove every possible execution schedule.

For RTOS projects, collect per-task stack margin, allocation failures, queue high-water levels and relevant execution-time measurements during the defined workload. FreeRTOS provides stack-usage and overflow-checking facilities, but configuration and port behavior matter. A high-water reading is evidence about exercised paths, not proof that all future call paths fit. See the FreeRTOS stack-checking documentation.

Record the units of every metric. Stack depths may be expressed in stack elements or bytes depending on the API and platform. Reserve margin for diagnostic paths and upgrades, and make the agreed RAM and flash budgets visible in the release report.

4. Accept failure behavior, not just normal behavior

• Malformed input: send truncated, oversized and checksum-invalid frames. Verify bounded processing, a defined error count and recovery on the next valid frame.
• Missing device: disconnect a sensor or hold a bus unavailable using a safe test fixture. Verify timeouts and that unrelated functions remain responsive.
• Network outage: interrupt the approved test network. Observe retry spacing, queue limits and the documented discard or replay policy after recovery.
• Configuration interruption: on a recoverable bench unit, interrupt power during an authorized settings update. The next boot should select an intact version or declared defaults, not partially decoded values.
• Stalled execution: use a test build to prevent a required task from progressing. Check watchdog supervision, reset reason and safe output behavior.
• Bad update: test rejected image metadata or an interrupted update using the product’s recovery design. Preserve a verified way to restore the unit before destructive tests.

Agree the number of units, repetitions, environmental conditions and pass criteria before running this matrix. These values are project decisions, not universal industry thresholds. Avoid connecting uncontrolled industrial loads during fault injection.

5. Require diagnostics that survive handover

A fault record should associate the symptom with a build identity, reset cause, uptime and a bounded set of state information. Define retention, extraction and what happens when storage fills. Do not log passwords, private keys or complete customer payloads merely because they are convenient during debugging.

Where available, a platform core dump can support post-mortem analysis. ESP-IDF, for example, documents flash and UART dump destinations and tooling that uses the matching application build. This is an ESP-IDF-specific facility, not a generic promise for every MCU. See Espressif’s core-dump guide. Prove the selected extraction workflow with a controlled fault before accepting it.

6. Treat the release package as a testable deliverable

Require source and dependency revisions, build instructions, configuration files, linker scripts, partition layout, programming instructions, release binaries, checksums and debug symbols. Include licenses and redistribution obligations for supplied components. Separate development credentials from provisioning instructions; secrets should not be embedded in the handover archive.

The receiving engineer should build from the documented clean environment and flash a designated unit without help from the original developer’s workstation. If byte-for-byte reproducibility is a requirement, define how timestamps, generated files and toolchain inputs are controlled. Otherwise specify functional reproduction and record why binary hashes may differ.

Deliver the test procedure, raw evidence, results by requirement ID and unresolved deviations together. A known issue needs a trigger, impact, workaround, owner and disposition. “Passed with comments” is not meaningful if those comments hide missing required behavior.

7. Troubleshoot acceptance failures by layer

If raw input is correct but decoded data is wrong, investigate framing, byte order and conversion before blaming networking. If output delays appear only during logging, compare the logger’s blocking and buffering behavior. If only warm resets recover, check retained peripheral state, reset sequencing and settings validity. Change one factor at a time and preserve the failing release so that a later improvement can be demonstrated against the same test.

Apply the checklist to a real project scope

Obeita’s STM32 Data Acquisition and MQTT Integration project configuration describes instrument decoding and Ethernet or cellular uplink work. It is a useful scope example for linking raw frames to published values, not evidence that the acceptance matrix above has been completed. For a firmware handover review, the relevant service is Firmware and BSP Diagnostics.

Prepare the board revision, protocol samples, current source/build package and a short list of unacceptable failure outcomes. Those inputs make it possible to turn “firmware finished” into a reviewable acceptance plan.