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

MCU 故障复盘开发短记证据怎样留下来MCU 故障复盘的价值不在于写出一段完整故事而在于下一次能更快缩小范围。记录“系统偶发死机”没有意义记录复位原因寄存器、固件版本、触发输入和最小复现步骤才有用。先保存会消失的证据复位后 RAM 和外设状态可能已经变了因此 HardFault、看门狗复位和 brown-out 的处理程序要优先保存关键寄存器、任务栈边界和最近事件。日志量有限时保留事件编号、时间戳和状态位不要在中断里打印长文本。复盘产物要能变成检查每个结论应对应一个动作栈溢出就增加栈水位监控非法状态转换就加断言或状态机测试电源抖动就把阈值和波形要求写入硬件验收。无法复现的判断要标记为假设不能当作根因。复盘结束时至少留下复现条件、修复提交、回归用例和未解决风险。这样它才是工程记录而不是一次事故总结。一个可执行的核对清单例如看门狗复位的记录应包括复位寄存器原值、喂狗任务的最后一次心跳、堆栈水位和固件的构建标识。将这组字段编码为固定长度的环形记录并用调试固件主动触发看门狗确认复位后仍可读出。若记录区与业务写入共用 Flash还需验证掉电时不会破坏文件系统。修复上线后不只看是否再次复位还要运行对应的压力场景并检查记录格式是否兼容旧版解析器。硬件、电源或编译器版本变化时重新验证因为相同症状未必有相同根因。若确认只是临时绕过也应保留下一次复查的触发条件。测试记录应注明使用的是调试固件还是发布固件避免把额外日志带来的时序差异误当成修复效果。该标签也方便后续定位不一致结果。若复现依赖特定外设状态也要写入检查单。