MCU 固件外包：验收要求应该写哪些内容

当另一位工程师能够构建、烧录外包 MCU 固件，验证约定的接口，并解释故障发生时的行为，这个项目才具备验收条件。演示成功当然有价值，但它不能说明传感器断开、配置写入中断电或网络长期不可用后，设备究竟会怎样运行。

本文为资源受限的 MCU 产品提出一套验收结构，适用于裸机和 RTOS 设计。这是一份工程检查清单，不代表某块具体电路板已通过这些测试。涉及安全的产品还需要独立的危险分析、开发流程和适用法规审查。

1. 确定报价之前，先确定项目边界

首先制作配置表，明确 MCU 型号及芯片版本、电路板版本、时钟源、外部存储器、外围模组、工具链、SDK 和 RTOS 版本。列出实际外接设备及其协议文档。“支持 RS485”只说明电气接口，并未定义波特率、收发方向切换时序、寄存器映射、重试策略或应用互通要求。

将范围分为必须实现的功能、明确排除的内容，以及需要其他方满足的前提。如果客户提供现有引导程序，应明确其镜像格式、保留内存及升级约定。如果硬件仍在变化，应说明以哪一版电路板作为验收对象，以及后续引脚或器件变化如何评估。

每项需求都应有稳定编号和可观察的结果。“可靠采集”过于笼统。更好的需求会写清输入报文、预期解码值、允许的上报延迟、校验和错误时的行为，以及测试人员如何取得证据。

2. 定义从引脚到应用的数据链路

为每个接口记录电气与通信设置、报文格式、超时、资源归属和错误处理。采集产品应能针对同一个样本，对照仪表原始读数、接收字节、解码后的工程量和发出的应用载荷。单位、缩放、符号位、无效值表示方式和时间戳来源也应明确。

写清生产速度超过消费速度时的处理方式。队列可以拒绝最新数据、丢弃最旧数据、阻塞任务或触发故障，没有一种策略适合所有产品。验收需求必须选择策略，并提供计数器，使无声丢失与输入本身没有数据可以区分。

还应区分传输送达与应用执行完成。命令应答应明确表示“已解析”“已接受”还是“已执行”。如果重试可能让继电器动作两次，应约定幂等或序列号规则，并主动测试重复命令。

3. 让时序与内存限制可以测量

时序限制应来自产品需要，而不是照搬熟悉的系统节拍。定义激励边沿、测量位置、允许负载和验收统计量。例如，在通信并发负载下用逻辑分析仪测量输入到输出的响应。实测最坏值与分析得到的上界应分别记录；有限次测试不能证明所有可能的调度都满足要求。

对于 RTOS 项目，在约定工作负载下收集各任务栈余量、分配失败次数、队列最高占用量和相关执行时间。FreeRTOS 提供栈使用量及溢出检查机制，但配置和移植层行为都会影响结果。高水位数据只能说明已执行路径的情况，不能证明未来所有调用路径都不会超限。参见 FreeRTOS 栈检查文档。

记录每个指标的单位。不同 API 和平台的栈深度可能以栈元素或字节表示。为诊断路径和后续升级预留空间，并在发布报告中列明约定的 RAM 与 Flash 预算。

4. 验收故障行为，而不只验收正常运行

• 异常输入：发送截断、超长和校验错误的报文，验证处理时间有界、错误计数明确，并能在下一条合法报文到来时恢复。
• 设备缺失：通过安全测试夹具断开传感器或使总线不可用，验证超时，以及无关功能仍可响应。
• 网络中断：中断获准使用的测试网络，观察重试间隔、队列上限，以及恢复后的丢弃或补传策略。
• 配置写入中断：在可恢复的台架样机上，于获准的设置更新过程中断电。下次启动应选择完整版本或明确定义的默认值，而不是部分解码的数据。
• 执行停滞：用测试版本阻止某个关键任务继续运行，检查看门狗监督、复位原因和输出安全状态。
• 错误升级：按照产品恢复设计，测试错误镜像元数据被拒绝或升级被中断的情形。破坏性测试前，保留已经验证的恢复方式。

执行矩阵前应约定样机数量、重复次数、环境条件和通过标准。这些数值是项目决策，并不存在通用的行业门槛。故障注入时，不要连接不受控的工业负载。

5. 要求交接后仍可使用的诊断能力

故障记录应把症状与构建标识、复位原因、运行时间及有限的状态信息关联起来。明确保存周期、提取方式和存储满时的处理。不要仅因为调试方便，就记录密码、私钥或完整客户载荷。

平台支持时，核心转储可以帮助事后分析。例如，ESP-IDF 文档说明了 Flash 和 UART 转储方式，以及需要匹配应用构建的分析工具。这是 ESP-IDF 的特定能力，不是所有 MCU 的通用保证。参见 Espressif 核心转储指南。验收前，应通过一次受控故障验证选定的提取流程。

6. 将发布包作为可测试的交付物

要求提供源码及依赖版本、构建说明、配置文件、链接脚本、分区布局、烧录说明、发布二进制文件、校验值和调试符号。包含所提供组件的许可证及再分发义务。开发凭据与生产配置说明应分开；秘密信息不应嵌入交付归档。

接收工程师应能在文档规定的干净环境中构建，并在不依赖原开发者工作站的情况下烧录指定设备。如果要求逐字节可复现，就要定义时间戳、生成文件及工具链输入的控制方式。否则，应定义功能复现要求，并记录二进制哈希可能不同的原因。

测试步骤、原始证据、按需求编号整理的结果，以及未解决的偏差应一起交付。已知问题需要写清触发条件、影响、临时措施、负责人和处理结论。如果备注掩盖了必需行为未实现，“有备注的通过”就没有实际意义。

7. 按层定位验收失败

如果原始输入正确而解码数据错误，应先检查分帧、字节序和换算，再怀疑网络。如果输出延迟只在记录日志时出现，应比较日志模块的阻塞及缓冲行为。如果只有热复位能够恢复，应检查外设保留状态、复位时序和配置有效性。每次只改变一个因素，并保留失败版本，以便后续改进能在同一测试下得到证明。

把清单用于真实的项目范围

欧蓓特的 STM32 数据采集与 MQTT 集成项目方案描述了仪表解码以及以太网或蜂窝上联工作。它可作为把原始报文与发布数据关联起来的范围示例，但不是上述验收矩阵已经完成的证据。固件交接评估可参阅 固件与 BSP 诊断服务。

准备电路板版本、协议样例、当前源码和构建包，以及简短的不可接受故障结果清单。这些输入可以把“固件已经完成”转化为可审查的验收计划。