1. 固件升级概述

各位工程师朋友，咱们今天聊聊固件升级。这话题看着基础，但我在项目里见过太多因为升级中断导致的“翻车”现场——设备变砖、数据丢失、产线停摆。说白了，升级这事儿，做对了没人夸你，做砸了可是要背锅的。

1.1 什么是固件升级

固件升级，就是把设备里跑的程序换一版新的。你想想看，手机、路由器、智能电表、汽车ECU，这些嵌入式设备出厂后不可能永远不更新。修复漏洞、增加功能、优化性能，都得靠升级。

我个人习惯把固件升级分成两类：

• 全量升级：整片Flash全部擦掉重写。简单粗暴，但耗时长、风险高。
• 差分升级：只替换变化的部分。省流量、省时间，但需要复杂的差分算法。

嗯，这里要注意：不管哪种方式，升级过程中一旦断电、断连、或者程序跑飞，设备就可能卡在半死不活的状态。这就是咱们这门课要解决的核心问题。

1.2 OTA升级与有线升级的区别

很多新手会问：OTA和有线升级，不就是传输方式不同吗？其实没那么简单。我整理了一张对比表，你看完就明白了。

对比维度	有线升级	OTA升级
传输介质	UART、USB、JTAG、SPI等物理线缆	Wi-Fi、蓝牙、LoRa、4G/5G等无线链路
传输可靠性	高，物理连接稳定，误码率低	低，受信号干扰、距离、带宽影响大
升级速度	快，通常几Mbps到几十Mbps	慢，受无线带宽限制，大包可能传几分钟
中断风险	低，线缆松动或人为拔插是主要风险	高，信号丢失、电量耗尽、网络切换都可能中断
恢复手段	容易，重新连接线缆即可重试	困难，设备可能失联，需要现场干预
典型场景	产线烧录、实验室调试、售后维修	远程推送更新、批量设备维护

我在项目中遇到过最头疼的OTA场景：一个智能水表部署在地下井里，信号本来就差，升级包传了一半断连了。设备既不能正常跑旧程序，也没法继续收新程序，最后只能派人去现场拆盖用线刷。所以，OTA升级的中断防护，比有线升级要严格得多。

1.3 固件升级的典型流程

不管是有线还是OTA，升级流程的核心骨架是一样的。我画了一张流程图，帮你理清每个环节。

每个步骤的要点，我简单拆解一下：

1. 版本检查与准备：先确认新版本是否兼容硬件，检查剩余存储空间是否够用。我习惯在准备阶段就把旧固件备份到备份区，万一新固件跑不起来，还能回滚。
2. 固件传输/下载：有线升级通常用XMODEM、YMODEM协议；OTA则用HTTP、MQTT或私有协议。传输过程中要加CRC校验，分包确认，防止丢包。
3. 完整性校验：下载完成后，用MD5、SHA256或者CRC32校验整个固件包。校验不通过，直接丢弃，不执行写入。
4. 写入Flash并激活：这是最危险的环节。写入过程中如果断电，Flash里的数据可能处于“半擦半写”状态。我建议用“双备份区”策略——先写备份区，再切换启动指针。
5. 重启验证与回滚：重启后检查新固件是否正常启动。如果连续三次启动失败，自动切回旧版本。

1.4 升级中断的常见场景与影响

升级中断，说白了就是升级流程被意外打断。我根据项目经验，把常见场景分成了三类：

1.4.1 电源类中断

• 电池耗尽：物联网设备升级到一半，电池没电了。我曾经遇到过一批NB-IoT水表，升级包2MB，传了80%设备没电了，结果30%的设备需要返厂重刷。
• 意外断电：用户拔插头、产线跳闸、电源接触不良。这类中断最致命，因为写入Flash的过程被硬生生打断。
• 电压波动：供电不稳导致MCU复位。有些廉价电源在写入Flash大电流时电压会跌落，触发BOR复位。

1.4.2 通信类中断

• 无线信号丢失：OTA升级时设备移动到了信号盲区，或者Wi-Fi路由器重启了。
• 蓝牙连接断开：手机APP升级手环时，手机走远了或者APP被后台杀了。
• 网络超时：HTTP下载固件时，服务器响应慢导致TCP连接超时。

1.4.3 软件/逻辑类中断

• 看门狗超时：写入Flash耗时太长，没有及时喂狗，导致MCU复位。
• 内存溢出：固件包太大，解压或校验时堆栈溢出，程序跑飞。
• 版本不兼容：新固件依赖的硬件外设与旧驱动冲突，启动后死机。

我整理了一个中断影响等级表，方便你评估风险：

中断场景	影响等级	典型后果	恢复难度
传输过程中断	低	固件包不完整，校验失败，可重试	容易
校验过程中断	低	校验未完成，丢弃包，重新下载	容易
Flash擦除中断	高	Flash扇区数据损坏，旧固件丢失	困难
Flash写入中断	极高	固件数据不完整，启动校验失败	极困难
重启验证中断	中	新固件启动失败，依赖回滚机制	中等

嗯，看到这里你应该明白了：升级中断不是“断了重来”那么简单。尤其是Flash写入阶段的中断，轻则丢数据，重则变砖。后面的章节，我会逐一拆解每个中断场景的根因和防护方案。