2. 升级中断的常见原因

做固件升级这么多年，我见过最多的翻车现场，说白了就四种情况：电源异常、通信中断、存储故障、用户强制断电。你想想看，升级过程中芯片正在擦写 Flash，突然来这么一下，轻则升级失败，重则变砖。咱们一个一个拆开聊。

2.1 电源异常

这是最常见、也是最难防的。我早期做一款智能插座产品时，用户插拔电源适配器导致升级中断，返修率一度冲到 3%。后来我们加了掉电检测电路才压下来。

电源异常分几种情况：

• 电压跌落：电池供电设备电量不足，升级到一半电压掉到 MCU 最低工作电压以下。我记得有一次测试，锂电池从 3.7V 掉到 3.0V，Flash 写入直接卡死。
• 瞬时掉电：插头松动、电源开关误触，几毫秒内电压归零。这时候 MCU 连保存现场的时间都没有。
• 电源纹波过大：开关电源老化或负载突变，纹波超过 200mV 时，Flash 写入可能产生位错误。嗯，这个比较隐蔽，一般排查不到。

异常类型	典型场景	影响范围	检测手段
电压跌落	电池供电、USB 供电不足	写入中断、数据损坏	ADC 监测 VDD
瞬时掉电	插头松动、电源开关误触	固件分区损坏	BOD 欠压复位
纹波过大	电源老化、负载突变	Flash 位错误	示波器测量

2.2 通信中断

通信中断在 OTA 升级里尤其要命。你想想看，固件包传了一半，蓝牙断连、Wi-Fi 掉线、串口被拔，接收端只存了半包数据。这时候如果直接开始擦写，写进去的就是垃圾。

我个人习惯把通信中断分成三个层级：

1. 物理层中断：线缆被拔、无线信号消失。这种最干脆，MCU 通常能通过超时检测到。
2. 协议层中断：TCP 连接超时、蓝牙 ATT 断开、CAN 总线错误。需要协议栈回调通知应用层。
3. 数据包损坏：CRC 校验失败、重传超限。这种最坑，因为连接还在，但数据已经不对了。

2.3 存储故障

存储故障分硬件和软件两方面。硬件上，Flash 是有寿命的——Nor Flash 一般 10 万次擦写，Nand Flash 只有几千次。升级频繁的产品，比如电表、水表，用几年就可能遇到坏块。

软件上更常见：

• 分区表损坏：升级过程中分区表被意外改写，MCU 找不到启动入口。
• 文件系统崩溃：如果用了 LittleFS 或 SPIFFS，突然断电可能导致元数据不一致。
• 地址越界：固件包大小超过分区容量，写入到隔壁分区。我见过一个案例，Bootloader 被覆盖，直接变砖。

2.4 用户强制断电

这个最让人头疼。你无法控制用户的行为——升级进度条走到 80%，用户觉得太慢，直接拔电。或者看到「升级中请勿断电」的提示，偏偏想试试会怎样。

我做过一个用户行为统计：

用户行为	占比	后果
看到提示后故意断电	12%	固件损坏，需强制恢复
误触电源开关	45%	升级中断，可自动恢复
电池耗尽	30%	写入中断，数据损坏
其他	13%	视情况而定

2.5 四种原因的关系图

下面这张图展示了四种中断原因之间的关联和典型触发路径。你看，电源异常往往是其他问题的放大器——电压不稳会导致通信重传、Flash 写入失败，甚至触发用户强制断电。

2.6 如何快速定位中断原因

现场出了问题，怎么快速判断是哪种中断？我一般按这个顺序排查：

1. 看日志：如果有 RTC 或系统滴答，先看最后一条日志的时间戳。如果日志突然中断，大概率是电源或用户断电。
2. 检查复位原因寄存器：大部分 MCU 都有 RCC_CSR 或类似寄存器，能读出是欠压复位、外部复位还是看门狗复位。这个信息非常关键。
3. 看 Flash 内容：读一下升级分区的 Magic Number 和 CRC。如果 Magic 对但 CRC 错，说明通信中断；如果 Magic 都不对，可能是存储故障。
4. 问用户：别不好意思，直接问「您当时有没有拔电源或者按复位键？」用户反馈往往能省掉一半排查时间。