1. 固件升级概述
大家好，我是你们这门课的老朋友。咱们今天先聊聊固件升级到底是个啥。说白了，固件就是嵌在设备里、直接操作硬件的那些代码。升级嘛，就是给它打个补丁、换个版本。
我刚开始做嵌入式那会儿，升级还全靠烧录器。后来OTA普及了，远程升级成了标配。但问题也来了——升级过程中一旦断电、断网，设备可能直接变砖。嗯，这就是咱们这门课要解决的核心问题。
什么是固件升级
固件升级，就是把设备里现有的程序替换成新版本。你想想看，手机系统更新、智能电表远程修复、汽车ECU刷写，本质上都是同一件事。
升级通常包含三个步骤：
- 获取新固件——从服务器下载或本地读取
- 写入存储——把新数据写到Flash或EEPROM
- 校验生效——检查完整性，然后重启加载
我在项目中遇到过最典型的场景：一个工业控制器，升级到一半突然断电。重启后系统既不能跑旧版本，也没写完新版本，直接卡死在bootloader里。这就是典型的“半砖”状态。
核心要点：固件升级的本质是“原地替换”，而原地替换天然就有中断风险。你没法保证写入过程中永远不掉电、不丢包。
OTA升级与本地升级的区别
这两者的区别，我习惯用一个表格来对比：
| 对比维度 | 本地升级 | OTA升级 |
|---|---|---|
| 传输方式 | 串口、JTAG、USB、SD卡 | Wi-Fi、蓝牙、蜂窝网络 |
| 升级触发 | 人工现场操作 | 远程推送或定时检查 |
| 中断风险 | 主要是掉电、线缆松动 | 掉电 + 网络断连 + 信号弱 |
| 恢复难度 | 现场重烧，相对可控 | 远程恢复，难度大很多 |
| 典型场景 | 产线烧录、售后维修 | 智能家居、车联网、传感器 |
OTA升级最大的坑是什么？我告诉你——你没法控制升级时的网络环境。设备可能在车库、地下室、电梯里，信号说断就断。我曾经调试过一个NB-IoT水表，升级包才32KB，结果因为基站切换，连续失败了7次才成功。
本地升级相对安全，因为你能看到设备、能手动干预。但也不是万无一失。我记得有一次用SD卡升级，客户把卡拔早了，结果文件只写了一半。嗯，从那以后我坚持所有升级都必须做CRC校验。
升级中断的风险与挑战
为什么会这么怕中断？我给你拆开来看：
- 固件损坏——写入一半断电，Flash里留下的是垃圾数据。重启后bootloader读不到有效固件，直接死循环。
- 系统不可用——没有双备份机制，旧固件已经被擦除，新固件没写完。设备彻底变砖。
- 数据丢失——升级过程中可能涉及配置参数、校准数据的重新写入。中断后连校准值都没了。
- 安全漏洞——中断后系统可能进入一个未定义状态，攻击者可以利用这个状态注入恶意代码。
警告：不要以为只有掉电才算中断。OTA升级中，TCP连接超时、HTTP响应截断、Flash写入超时，都是中断。而且这些中断往往比掉电更难检测。
我见过最惨的一个案例：某智能门锁OTA升级到一半，用户把电池抠了。重启后bootloader检测固件校验失败，直接进入DFU模式。但DFU模式需要手机App连接才能恢复，而用户手机恰好没电了……门锁就这么卡了两天。
所以，升级中断恢复技术不是锦上添花，而是刚需。你设计的每一个升级流程，都必须假设“一定会中断”，然后提前想好怎么兜底。
本章知识体系
下面这张图，是我自己梳理的固件升级核心逻辑。你可以把它当作这门课的地图：
我的建议：学这门课之前，你先想清楚自己产品的升级场景。是本地烧录还是远程OTA？Flash有多大？有没有双备份区？这些信息决定了你后面选哪种恢复策略。
好了，第一章就聊到这儿。记住一句话：没有中断恢复的升级方案，就是一颗定时炸弹。后面咱们会一步步拆解，怎么给这颗炸弹装上保险丝。