嵌入式升级为何变砖？掉电怎么兜住？

升级失败最可怕的不是版本没换上，而是设备连旧版本都回不来。嵌入式产品只要把 Flash 擦写原子性和回滚判据想得过于理想，一次普通掉电就足以把启动链路切成半截，现场表现就是大家熟悉的“变砖”。

页擦写原子性先决定了你能不能承受任何时刻断电。Flash 擦除通常按扇区进行，写入又按字或页推进，中间存在长短不一的忙时窗口；若镜像头、向量表、版本标记和配置参数混在同一扇区，更新其中一个字段就可能迫使整段内容先被抹空再重写。掉电一旦落在这个窗口里，最致命的往往不是正文镜像缺几百字节，而是启动时必须先读的元数据已经半旧半新。若配置区和镜像头还共享磨损块，重复升级后风险会继续累积。系统于是既不能确认旧镜像完整，也不能确认新镜像可用，只能在复位后反复跌进同一个无效入口。

更稳妥的设计，是把“可否启动”的最小信息压缩成独立、可重复验证、可延后提交的一小块状态，而不是让整个升级过程共享同一片元数据。镜像先完整写到备用区，正文校验通过后再切换活动指针；关键头部最好做双份或带序号记录，保证任意时刻至少有一份状态能解释当前应从哪启动。这样即使中途断电，损失也被限制在“本次升级未完成”，而不会扩散成“设备再也起不来”。

回滚标志位则决定系统在失败现场会不会做出错误自信。很多实现只在升级完成后把一个成功位写成真，看似简单，实际忽略了新镜像首次启动、外设初始化和业务自检仍然可能失败。嵌入式启动链若没有把“下载完成”“镜像可启动”“业务运行稳定”分成不同阶段，Bootloader 很容易在新镜像刚点亮就永久提交，等看门狗数秒后把系统拉回复位，回滚条件已经被自己提前抹掉了。

更可靠的回滚判据通常要跨越两个复位周期。Bootloader 先把新镜像标成试运行，只给有限次数启动机会；应用在关键外设、自检和通信心跳都通过后，再显式提交成功。试运行计数也必须掉电可恢复，不能只放在 RAM 里。若中途掉电、异常复位或卡死喂不到确认标志，下一次上电就自动回到旧镜像。这个流程看似多了一层状态机，实际是把“能起机”和“能稳定工作”分开承认，避免一次侥幸上电就把退路封死。

验证也不能只在实验室做正常升级。应故意在擦除、写头、写尾、首次启动和业务初始化不同阶段切断电源，检查每一种断点后系统究竟会落到哪条启动路径。很多方案在连续供电下都显得完美，一旦做掉电注入才暴露出配置区被误覆盖、活动位提交过早或回滚次数耗尽无法恢复。这样才能确认每一种坏状态都能被旧镜像解释并接管。只有把这些最坏情况逐个跑通，升级可靠性才算真实存在。

所以，防变砖的核心不是校验写得多复杂，而是掉电时系统始终知道自己还能信哪一份状态。把原子边界和回滚判据先立稳，升级才敢上线。