MCU 故障复盘开发短记：证据怎样留下来

MCU 故障复盘开发短记：证据怎样留下来

MCU 故障复盘的价值不在于写出一段完整故事，而在于下一次能更快缩小范围。记录“系统偶发死机”没有意义；记录复位原因寄存器、固件版本、触发输入和最小复现步骤才有用。

先保存会消失的证据

复位后 RAM 和外设状态可能已经变了，因此 HardFault、看门狗复位和 brown-out 的处理程序要优先保存关键寄存器、任务栈边界和最近事件。日志量有限时，保留事件编号、时间戳和状态位，不要在中断里打印长文本。

复盘产物要能变成检查

每个结论应对应一个动作：栈溢出就增加栈水位监控；非法状态转换就加断言或状态机测试；电源抖动就把阈值和波形要求写入硬件验收。无法复现的判断要标记为假设，不能当作根因。

复盘结束时，至少留下复现条件、修复提交、回归用例和未解决风险。这样它才是工程记录，而不是一次事故总结。

一个可执行的核对清单

例如看门狗复位的记录应包括复位寄存器原值、喂狗任务的最后一次心跳、堆栈水位和固件的构建标识。将这组字段编码为固定长度的环形记录，并用调试固件主动触发看门狗，确认复位后仍可读出。若记录区与业务写入共用 Flash，还需验证掉电时不会破坏文件系统。

修复上线后，不只看是否再次复位，还要运行对应的压力场景并检查记录格式是否兼容旧版解析器。硬件、电源或编译器版本变化时重新验证，因为相同症状未必有相同根因。

若确认只是临时绕过，也应保留下一次复查的触发条件。

测试记录应注明使用的是调试固件还是发布固件，避免把额外日志带来的时序差异误当成修复效果。该标签也方便后续定位不一致结果。

若复现依赖特定外设状态，也要写入检查单。