📚 课程目录第4章失败场景分类

4. 失败场景分类：网络中断、校验失败、存储空间不足、电源异常、版本兼容性问题

做OTA升级，说白了就是跟不确定性打交道。我做了这么多年嵌入式，见过太多次升级失败的情况。有些是设计时就能预见的，有些则完全出乎意料。

今天咱们就来聊聊最常见的五类失败场景。我把它们分门别类讲清楚，每个场景我都会结合自己的踩坑经历，告诉你到底该怎么排查、怎么预防。

核心观点：失败不可怕，可怕的是你不知道为什么失败。分类的目的，就是让你在出问题时能快速定位根因。

这是最频繁的失败场景，没有之一。尤其是做物联网设备，Wi-Fi信号不稳定、基站切换、甚至有人不小心拔了路由器，都会导致传输中断。

我遇到过最典型的一个案例：某款智能门锁，升级到一半时用户把网关断电了。结果固件只写了50%，设备直接变砖。嗯，从那以后我就在所有项目里强制要求：下载阶段必须支持断点续传。

我的习惯：在下载过程中，每收到一个包就记录进度到非易失存储（比如EEPROM或Flash的专用区域）。这样即使断电重启，也能从断点继续，不用从头下载。

校验失败，说白了就是数据坏了。可能是传输过程中发生了比特翻转，也可能是存储介质本身出了问题。

我记得有一次，某款设备在高温环境下反复升级失败。排查了很久才发现，是Flash在高温下读取不稳定，导致校验时算出的哈希值跟预期不符。

常见的校验方式有几种：

我个人建议：分层校验。每个包用CRC32做快速校验，整个固件包用SHA256做完整性校验，最后再用RSA验证签名。三层下来，基本能挡住99.9%的数据损坏问题。

避坑指南：我曾经遇到过一种情况——校验算法本身没问题，但校验用的参考值存错了位置。结果每次升级都提示校验失败，折腾了两天才发现是参考值地址偏移了一位。所以，校验逻辑写完后，一定要做正向测试和反向测试。

这个问题在资源受限的嵌入式设备上特别常见。你想想看，MCU的Flash通常就那么几百KB到几MB，既要跑当前固件，又要存升级包，还要留出备份区，空间非常紧张。

我见过最离谱的一次：某款设备Flash总共512KB，当前固件占了480KB，升级包有200KB。结果下载到一半，空间不够了，直接报错退出。

解决思路其实就两条：

我的做法：在升级包的元数据里，明确写上所需的最小Flash空间。设备端收到元数据后，先做空间检查，不够就直接返回错误码，避免浪费带宽和时间。

电源问题是最致命的。因为一旦掉电，写入Flash的操作可能只完成了一半，轻则固件损坏，重则Bootloader都被冲掉。

我记得有个项目，设备用的是电池供电。用户升级到一半，电池没电了。结果设备再也起不来了，只能返厂维修。

针对电源异常，我总结了几个关键措施：

避坑指南：我曾经以为掉电检测只要软件做就够了。结果有一次，电压掉得太快，中断都没来得及响应，MCU就直接复位了。后来我学乖了——掉电检测必须硬件配合，用比较器+外部中断，而且要在电源滤波电容之前采样。

这个问题往往被忽视，但一旦出现，排查起来最头疼。因为错误信息可能五花八门，甚至根本不会报错，只是功能异常。

我遇到过最经典的案例：新固件改了Flash分区布局，但升级脚本没更新。结果升级完成后，设备读取配置数据时全乱了，屏幕显示花屏，按键完全失灵。

版本兼容性检查，我建议至少覆盖以下几点：

我的习惯：在升级包的元数据里，明确声明兼容的版本范围。设备端在下载前就做版本匹配检查，不匹配就直接拒绝。这样能避免很多莫名其妙的问题。

下面这张图，我把五类失败场景以及它们的关联关系画了出来。你可以看到，有些场景是独立的，有些则会相互触发。

从这张图里你能看出来，网络中断和电源异常是两大元凶。它们一旦发生，往往会引发连锁反应——数据不完整导致校验失败，写入中断导致版本兼容性问题。所以，我建议你在设计OTA方案时，优先把这两个场景的防护做好。

总结一下：五类失败场景，每一类都有其独特的根因和排查方法。但它们的共同点是——都需要在架构层面做预防。不要等到出了问题再想办法补救，那往往已经晚了。