先说结论固件升级框架这东西平时不显山不露水可一旦设备到了客户现场、升级到一半网络闪断、新固件跑飞电又没了你才会发现它比应用逻辑本身还重要。我做过不少带远程维护的嵌入式项目从早期的 UART 本地升级到后来基于网络和存储介质的 OTA 升级踩过的坑加起来能凑一篇长文。这篇内容我尽量不讲空话直接围绕嵌入式固件升级框架的组成、分区方案、镜像设计、状态机、以及我实际遇到过的变砖案例来展开适合正在做物联网设备、工业控制器、车机或者带 bootloader 的 MCU 项目的工程师参考。很多工程师一听到“升级框架”第一反应就是 bootloader 加一个下载协议。实际项目跑下来你会发现这远远不够。真正的升级框架要管的不只是“把新固件写进 Flash”而是如何保证升级过程中不管发生什么设备都还有救。整篇文章我会按照我自己的设计思路来讲分六块框架总体要解决什么问题、分区和启动策略、固件包的信任设计、升级状态机与掉电安全、真实事故复盘、以及工程化落地方法。1. 明确升级框架的边界设备端、打包端、恢复通道缺一不可1.1 很多人只看到“烧写 Flash”但框架其实是三端协作我见过不少同事把固件升级理解成“写一个 bootloader收到包就往 Application 区拷贝”。这么想不能说错但很危险。一个完整的固件升级框架至少同时包含三个角色打包端在 PC 或服务器上把编译好的 bin/hex 文件加上头信息、校验值、签名、版本号生成标准升级镜像。传输端定义升级包怎么从源端到设备端。本地升级往往是 UART/SPI/I2C/USB远程升级则更复杂可能是 MQTT、CoAP、HTTP、TCP 私有协议甚至是通过 TF 卡/U 盘人工拷贝。设备端负责接收数据、临时存储、校验、状态管理、触发 bootloader 切换、执行写入、启动新固件、失败回滚。三端之间是强耦合关系打包端的镜像字段如果和设备端校验逻辑对不上升级必失败传输端的切包大小如果超过设备端接收缓冲区轻则重传风暴重则写坏 Flash设备端的状态机如果不考虑掉电、看门狗、非法跳转变砖只是时间问题。我在框架设计的初期会先画一张最简单的数据流图源服务器/PC 生成镜像传输通道把镜像拆包发给设备设备把数据写入临时分区校验通过后标记待生效状态重启后 bootloader 根据标志位决定启动哪个分区。这张图看起来简单但每个环节都藏着不少决策点。1.2 一次升级跨越多层每层都要有明确的失败处理更直白一点说升级框架是一个典型的“多步骤长事务”。普通函数调用失败了你还能回滚内存状态但升级涉及 Flash 擦写、重启、硬件状态切换一旦中间断了可能连回滚入口都没了。比如设备正在擦写 Application 区的时候突然断电如果没有任何保护机制重启后 bootloader 发现 Application 区是半擦状态校验失败进不了 App也没有其他固件可用设备就成砖了。所以框架设计的第一原则就是每一步把现场保护起来让失败在下一次上电时能被识别并恢复。这句话我会在后面反复提到因为几乎所有变砖事故归根结底都是“现场没有被保护”。1.3 “失败可恢复”应该写进需求而不是当作加分项有些项目把回滚功能当成“如果有时间再做”的锦上添花。我的建议是只要产品存在远程升级或者用户可自行升级的场景就必须把“升级失败后设备仍然可恢复”写进核心需求。否则出一次现场事故差旅和商务成本就远超你省下的那点 Flash 空间和开发工时。我之前做过一款工业数据采集器最开始方案只规划了一个 Application 分区想着反正有 bootloader升级失败最多再升一次。后来设备部署在野外基站维护人员根本不可能频繁到现场第一次 OTA 失败导致设备离线后团队只能派人出差刷机。那次之后我们重新翻工设计了双分区方案。这件事给我的教训特别深升级框架的复杂度应该由“失败后果”决定而不是由“开发成本”决定。2. 分区与启动策略单分区、双 bank 和 A/B 槽位怎么选2.1 单分区方案只适合本地可控场景远程 OTA 千万别碰单分区方案是所有方案里最简单的Flash 里只有一个 Application 区bootloader 负责接收固件并直接覆盖写入写完校验通过就跳转。它的优点是占用的 Flash 空间最少代码逻辑也最简单。缺点也很致命升级动作不具备原子性。如果写了一半掉电或传输中断Application 区处于不确定状态bootloader 很难判断该不该启动它。就算你有完整的 CRC 校验也只能发现“固件坏了”但发现之后你没有任何备选可用来启动。所以我的判断是单分区只适用于工厂烧录、现场调试、或者由专业人员配合编程器/调试器在场的场景。凡是面向终端用户的远程升级基本可以排除单分区。2.2 双 bank 是嵌入式 OTA 最常见的“性价比答案”双 bank 方案我习惯叫“双区互为备份”。它的思路是在 Flash 里划分两个足够大的区域一个作为当前运行区Active Bank另一个作为升级暂存区Inactive Bank。正常运行时数据从 Active 区读取收到升级包后先把新固件完整写入 Inactive 区校验通过后设置一个升级标志位重启后 bootloader 检查标志位把 Inactive 区和 Active 区进行整体切换或者把备份区数据搬运到主区。双 bank 最大的价值在于升级过程中旧固件始终完整保留在 Active 区。哪怕新固件写入一半断电甚至写完后校验失败bootloader 大不了不清除旧标志位继续启动旧固件设备仍然可用。我在实际项目里更倾向使用“标志位切换 启动时验证”的组合而不是直接把备份区数据拷贝回主区。原因很简单拷贝整片 Flash 耗时较长功耗和时间成本都高直接用向量表或者分区映射的方式切换启动速度几乎不增加Flash 扇区擦写寿命有限频繁整体搬运会加速损耗。当然双 bank 也有代价就是 Flash 占用翻倍。对很多成本敏感的小 MCU 来说这可能是个不小的门槛。如果你的 Flash 实在不够放两个完整固件也可以退一步做“压缩包 解压写入”但那样既要考虑解压算法又要考虑 RAM 占用复杂度反而更高。2.3 A/B 槽位更像是“双 bank 的加强版”适合高可用产品A/B 方案在双 bank 基础上增加了更细的槽位管理系统可以存在 A、B 两个槽位每个槽位都有完整的系统镜像设备启动时根据槽位标记选择其中一个运行正常后会把“当前槽位可用”的标记正式提交。下次升级时写入另外一个不活动的槽位。A/B 方案相比普通双 bank核心优势是升级确认机制更完整。很多双 bank 方案在 bootloader 里校验完 CRC 就认为升级成功但新固件实际启动后可能起不来——比如外设初始化失败、看门狗没人喂、驱动崩溃。A/B 方案允许新系统先试运行一段时间成功后才把槽位永久切换试运行失败自动回退到上一个正常版本。我刚接手带 A/B 方案的项目时会觉得它复杂但后来发现在车机、网关、医械这类对可用性要求高的产品里A/B 几乎是标配。它的主要缺点就是 Flash 占用、分区表复杂度、以及需要配套升级状态管理模块。三种方案对比下来我的大致建议是方案Flash 开销掉电容错回滚能力实现复杂度适用场景单分区最小差会变砖无低工厂烧录、现场调试双 bank约 2 倍较好旧固件保留可回退到上一个版本中物联网设备、中小型 MCUA/B 槽位约 2 倍以上很好带运行确认可自动回滚高网关、车机、高可用产品如果你第一次做 OTA预算允许我建议直接上带运行确认的双 bank。它比单分区复杂不了太多但安全性高了一个量级。2.4 别忽略预留的“恢复引导区”和“出厂固件区”只规划两个 App 分区还不够。我一般还会单独划一个很小的引导恢复区放着极简的出厂测试固件或者恢复固件。这个固件不参与日常业务只负责两件事当 bootloader 发现主备区都不可用时进入恢复引导模式等待串口/网络重新传输固件当设备需要恢复出厂设置时从恢复固件启动并重新烧写 App。看起来多占了几十 KB Flash但换来的是“即使两个区都坏了也有最后一条命”。特别是在设备已经量产的阶段这个恢复区能省下大量售后人力。3. 镜像头、三层校验与版本管理把升级包先做成“能被信任的东西”3.1 镜像头是设备端识别升级包的“身份证”很多人觉得升级包就是把编译好的 bin 文件直接传过去设备端拿到就写。实际项目里我会在固件前固定加一段镜像头让设备端在写入前就知道这个包是谁、给谁用的、版本多少、内容该不该收。下面是我常用的一种定义#define FW_HEADER_MAGIC 0x46575746 /* FWWF */ typedef struct { uint32_t magic; /* 固定魔数识别是否为合法升级包 */ uint32_t header_len; /* 镜像头长度 */ uint32_t version; /* 固件版本号用于防降级 */ uint32_t hw_id; /* 硬件兼容 ID跨型号混刷就靠它拦 */ uint32_t image_len; /* 固件数据长度 */ uint32_t image_crc32; /* 固件数据 CRC32 */ uint8_t reserve[16]; /* 预留字段可放签名、区域 */ } fw_header_t;设备端拿到升级包后第一步不是去接收整个文件而是先解析镜像头。magic 不对的包直接丢弃hw_id 不匹配直接终止version 低于当前版本直接拒绝。这些判断越早越好因为传输一个完整固件包既耗时又占 Flash 寿命。一个容易忽略的细节是header_len。不同版本的工具生成的固件包头部可能不同预留长度字段可以保证将来扩展字段时旧设备仍然能正确跳过头信息。3.2 三层校验链帧校验、包级校验、签名校验各管一段我把升级过程中的校验拆成三层缺一不可传输帧校验传输过程按块分包每块 256 字节或 1KB 加一个 CRC16/CRC32用来发现网络或者串口传输中的随机错误。这一层不通过就请求重传当前块不用等整个包传完。镜像包级校验整个固件接收完成后设备端对全镜像做 SHA256 或 MD5 校验和镜像头里存的摘要比对。这一层能发现传输过程中累计的数据缺损也能防止存储介质写入时出错。签名校验升级包用私钥签名设备端内置公钥bootloader 在决定写入前验签。这一层解决的是“数据来源是否可信”的问题而不是简单的“数据有没有坏”。很多工程师只做 CRC 不做签名理由是“我们是内网不会有攻击者”。但固件升级包的完整性校验和信任模型是两码事CRC 只能抗随机干扰防不了人为构造的恶意包。如果设备真的有远程升级能力却没有签名校验一旦攻击者拿到传输通道就能直接构造一个看似合法的升级包让设备加载任意代码。我们在设计安全要求稍高的产品时固件至少要用 RSA 或 ECDSA 做签名校验。哪怕是前期图省事我建议也在镜像头里留出签名长度字段方便后续加上。3.3 版本管理防降级、灰度升级、兼容性检查一起做版本管理看起来和 Flash 无关但它决定了升级框架的稳定度。我踩过的一个典型坑是现场有 100 台设备固件版本分散在 V1.0 到 V1.8 之间某次发布 V2.0 后部分老版本设备升级失败率高得离谱排查半天发现是老设备存储布局和新版本不一致。所以我在打包端会额外做这几件事防降级设备端判断新版本号必须大于当前运行版本号否则直接拒绝。这个规则避免现场误操作把新设备刷回旧版本导致的数据结构不兼容。硬件兼容 ID这个字段属于“防呆设计”。同一家公司往往有多个硬件版本引脚、传感器型号、存储容量都可能不同。没有 hw_id 时最常见的错误是把 A 型号的包刷进 B 型号运气好只是功能异常运气差直接驱动烧毁外设。灰度策略服务端分批发布先升级少量设备观察 24 小时成功率和离线率再把升级范围扩大到全网。这项策略看起来是运维层面的但它直接决定了框架的事故半径。此外建议在设备端保存一个“当前运行版本 最近一次升级结果”的日志重启后可以上报给服务端。远程诊断时这份日志往往比任何抓包工具都管用。4. 升级状态机的设计与掉电安全先写标志再做动作4.1 状态机是升级框架的“骨架”事件驱动每个转移我在实现设备端升级逻辑时不会把升级流程写成一长串顺序调用而是抽象成一个状态机。核心状态大致如下IDLE正常运行态等待升级指令。RECEIVING正在接收升级包写入临时分区。VERIFYING包接收完成做完整性校验和签名校验。PENDING_UPDATE校验通过写入升级标志等待重启。UPDATINGbootloader 完成分区切换/拷贝启动新固件。RUNNING_CONFIRM新固件运行确认成功后回到 IDLE确认失败则触发回滚。状态机的好处有两个。第一每个状态之间的转移动作都很明确便于代码评审第二掉电后重新上电bootloader 可以通过外部状态变量知道“上次进行到哪一步了”从而决定是继续升级还是回滚。比如设备正在 RECEIVING 时断电重启后 bootloader 发现临时区数据不完整可以直接清掉临时区回到 IDLE不影响当前运行的旧 App。在具体实现上我最关心的不是状态本身而是状态字段的存储方式。很多人喜欢把一个枚举变量直接放在普通 Flash 的某个地址但普通变量区在写入和读取之间容易丢失。我会把升级状态保存在一个独立的状态页并且每次写入前先擦除一整页再写入新状态页尾附带 CRC 校验。读取时如果 CRC 校验不过认定状态无效保守回退到 IDLE。4.2 “先写标志再做动作”掉电安全的核心操作顺序升级框架里有一个特别容易被忽视的问题执行顺序。我总结过一条规则任何高风险动作擦除、写入、分区切换执行之前先把描述该动作的标志写入持久存储动作完成后再更新标志状态。举个例子bootloader 要执行“从备份区切换为主区”。正确顺序是在状态页写入PENDING_SWITCH标志并附上目标分区标识和版本号执行分区映射切换切换完成后写入SWITCH_DONE标志跳转到新固件。为什么必须分两步因为 Flash 擦写过程不具备原子性。如果先在内存里改逻辑、再写标志中途断电后Flash 里的实际分区状态和标志可能不一致。下次上电时 bootloader 只看到旧标志就会错误地启动一个已经半擦写的分区。反过来先写标志再做动作即使动作没执行完上电后 bootloader 也能识别出“上次只做到一半”从而执行补偿逻辑。另外一个容易被忽略的顺序问题是擦写标志页的顺序。有些 Flash 擦除后默认全0xFF写入则只能把1变0。如果你要更新状态从0xA1变成0x33通常需要先擦除整个页再写入而擦除中断后该页数据可能残缺。所以状态页设计最好有两个备份页交替写入读取时按 CRC 判断最新页。这个小细节让我避免了至少两次现场救砖。4.3 看门狗、中断与 Flash 编程时长的关系升级过程中最隐蔽的“杀手”是看门狗。我曾经在一个项目里遇到升级进行到一半系统自动重启反复抓日志才发现是擦除大扇区耗时过长超过了看门狗溢出时间。尤其是一些内部 Flash 的擦除操作会阻塞指令执行中断处理也会受影响看门狗实际得不到及时喂食。处理方式有这么几种我按推荐优先级排列升级模式下拉长看门狗超时比如从正常的 2 秒拉到 30 秒并在下载/擦写过程中按块喂狗分段擦除不要一次性擦除整个大扇区每次擦一个小扇区后喂一次狗既能保证看门狗不死也降低单次阻塞时间如果 Flash 控制器支持后台擦写如 QSPI Flash 的 status polling可以在等待擦写完成期间用轮询方式继续执行其他轻量任务但要注意不要和中断抢占 Flash 控制器。还有一点是关于中断的。Flash 编程期间如果来了高优先级中断而中断服务程序里又访问了正在被编程的相同 Flash 地址可能会导致总线错误。所以我的习惯是在进入关键擦写流程前关闭可屏蔽中断或者确保中断服务程序不会访问 Flash 区间。像 STM32 这种内部 Flash 和向量表在同一空间的情况尤其要小心。5. 复盘四起真实升级事故从“升完变砖”到“远程救砖”5.1 事故一传输中断导致 App 区半擦设备彻底失联这是我第一份工作里遇到的事。设备通过串口接收升级包工程师为了保证简单直接写得一块 App 区就擦一块新数据流式覆盖。结果升级过程中维护人员拔了串口线擦了一半的 App 区里既有新数据又有旧残留bootloader 启动时 CRC 校验失败直接停在一个空壳状态既不启动也没法继续升级。那次修复是靠设备返厂用编程器重新烧录才救回来的。事后我们把方案整个改成“先收完整包到临时区校验通过后再拷贝到主区”。第一原则就是前面说的“失败可恢复”。也是从那时起我坚决不在没有临时存储区的情况下做覆盖式升级。5.2 事故二校验只做 CRC结果新固件能验过却不能启动另一个项目里升级包只有 CRC32 校验bootloader 验完就把新固件设为启动项。结果新固件在外部 RAM 初始化卡死了CRC 完全正常但设备根本跑不起来。系统也没有运行确认机制于是每台上电就卡在同样的位置只能靠售后逐台拆机处理。这个事故的直接原因是“校验通过”和“启动成功”之间隔着一道鸿沟。CRC 只保证了数据和源端一致并不能保证代码和当前硬件、配置、外设初始化兼容。从那以后凡是有条件的产品我都会在升级流程里加一个“试运行计数器”新固件启动后业务程序正常运行 60 秒后主动提交APP_RUNNING_OK标志如果启动后连续三次都没能提交bootloader 自动回滚到上一个可用版本。5.3 事故三跨型号误刷升级框架成功执行了不该执行的包这件事说起来有点丢人。项目里有 A、B 两款硬件主控相同但传感器供电引脚不同。打包端没做硬件兼容 ID某个维护人员把 A 型号的固件包推给了 B 型号设备。设备端升级流程完全成功没有任何校验拦截结果新固件启动后传感器驱动反复初始化失败部分板子还烧坏了传感器。后来我推动在镜像头和打包工具里都加入了hw_id字段并在设备端判断当前hw_id不匹配直接拒绝升级。这个字段花不了多少代码量但从源头上拦住了跨型号误刷。做多型号产品线的同学一定不要觉得这是小事。5.4 事故四读保护和 Flash 扇区保护让升级“假失败”这个坑属于硬件配置层面。有款产品出厂时为了防抄板开启了 STM32 的读保护并且把某些扇区设置了写保护。结果升级框架明明一切逻辑正常擦写却始终失败bootloader 每次上报WRITE_FAILED但真实原因是被保护扇区不允许写入。排查的时候我一度以为是代码逻辑问题后来用编程器和厂商工具检查选项字节才发现读保护等级冲突。解决方式是把升级需要的扇区加入可编程许可列表并且在升级流程里增加了对写保护状态的检测上报。如果你用的 MCU 有类似安全特性建议在升级前先读取并检查 Flash 选项字节避免“假失败”浪费大量排查时间。5.5 这些事故的共同点都是“没有保护现场”导致的回头看这四起事故共同点很有意思要么没有保证旧固件完整保留要么没有校验运行结果要么没有在源头拦截错误包。每一次都是升级框架里某个环节的缺失而不是某个驱动 BUG。所以我在项目评审时经常从事故的反向去追问设计升级到一半断电会怎样新固件起不来会怎样刷错型号会怎样如果答案是不确定说明框架还不够健壮。6. 工程化落地升级测试、发布节奏与回滚机制6.1 升级测试不能只在“正常路径”上跑我见过不少团队测试升级功能就是编译一个新版本从旧版本升上去看到进度条走完就报“通过”。这种测试覆盖远远不够。真正验证升级框架可靠性的测试至少要有掉电测试在升级过程的各个阶段随机断电然后重新上电检查设备能否按预期恢复或回滚。这个测试要靠继电器定时断电跑几百个循环坏包测试传输过程中故意篡改数据、截断数据确认设备不会把坏包写入正式区降级测试尝试用低版本包升级高版本设备确认被拒跨型号测试构造错误的hw_id包确认被拦Run/Reset 风暴测试新固件启动后立即反复复位验证“试运行确认”和回滚计数逻辑。这些测试看似多但很多可以自动化。我在 CI 里加过一个脚本用串口自动化工具循环给开发板下发不同状态的升级包再模拟断电自动统计恢复成功率。6.2 升级状态的上报与可观测性远程升级最怕的是“不知道设备现在卡在哪一步”。所以设备端我强烈建议维护一个升级日志区记录每一步的关键时间和结果码。日志不需要很长比如固定存最近 20 条记录每一条包含timestamp, phase, result。事故发生后通过串口或者上报机制拿到日志可以快速定位是网络中断、校验失败、还是启动确认超时。在没有实现远程日志的项目里也可以退而求其次把升级状态写到设备掉电不丢失的 RTC 后备寄存器或者独立 EEPROM 里重启后读取。这个状态信息哪怕只有几个字节也能让现场维护人员在拆机之前先判断问题方向。6.3 发布灰度、回滚开关和现场救砖通道最后聊聊发布层面的经验。升级框架做得再稳也不能保证 100% 不出问题所以发布策略非常关键。我的做法是发布阶段分三档灰度比例从 1% 到 10% 再到 100%。第一档选内部测试机第二档选少部分稳定客户第三档才全网发布。每一档之间至少间隔 24 小时盯两个指标升级成功率和设备离线率。哪怕设备端回滚逻辑完美灰度也能把影响面控制在很小的范围。服务端还要保留“回滚开关”这里的回滚不是指设备自动回退而是指“暂停继续下发升级包”。如果发现新版本有某些现场环境下才会出现的问题第一时间停止升级任务比逐台修改设备要快得多。最后的救砖通道也很重要。很多低成本设备没有远程调试能力一但变砖就得返厂。我在产品里会强行保留一个物理按键进入强制升级模式长按按键上电bootloader 跳过 App 校验直接进入串口或者网络下载模式。这个功能在量产阶段几乎救过我无数次强烈建议任何有升级能力的产品都加上。回到开头那句话固件升级框架不是一个 bootloader 那么简单。它贯穿了打包、传输、存储、校验、启动、回滚整个链路每一个环节都要用“假设它会失败”的心态去设计。如果你正在规划一个新项目的升级功能我建议先把分区方案和状态机想清楚再动手写代码。分区定错了后面改起来成本很高状态机没定好掉电恢复就是一句空话。别学我当年那样等设备在野外变砖了才回来补课。
嵌入式固件升级框架设计：分区、状态机与掉电安全实践
先说结论固件升级框架这东西平时不显山不露水可一旦设备到了客户现场、升级到一半网络闪断、新固件跑飞电又没了你才会发现它比应用逻辑本身还重要。我做过不少带远程维护的嵌入式项目从早期的 UART 本地升级到后来基于网络和存储介质的 OTA 升级踩过的坑加起来能凑一篇长文。这篇内容我尽量不讲空话直接围绕嵌入式固件升级框架的组成、分区方案、镜像设计、状态机、以及我实际遇到过的变砖案例来展开适合正在做物联网设备、工业控制器、车机或者带 bootloader 的 MCU 项目的工程师参考。很多工程师一听到“升级框架”第一反应就是 bootloader 加一个下载协议。实际项目跑下来你会发现这远远不够。真正的升级框架要管的不只是“把新固件写进 Flash”而是如何保证升级过程中不管发生什么设备都还有救。整篇文章我会按照我自己的设计思路来讲分六块框架总体要解决什么问题、分区和启动策略、固件包的信任设计、升级状态机与掉电安全、真实事故复盘、以及工程化落地方法。1. 明确升级框架的边界设备端、打包端、恢复通道缺一不可1.1 很多人只看到“烧写 Flash”但框架其实是三端协作我见过不少同事把固件升级理解成“写一个 bootloader收到包就往 Application 区拷贝”。这么想不能说错但很危险。一个完整的固件升级框架至少同时包含三个角色打包端在 PC 或服务器上把编译好的 bin/hex 文件加上头信息、校验值、签名、版本号生成标准升级镜像。传输端定义升级包怎么从源端到设备端。本地升级往往是 UART/SPI/I2C/USB远程升级则更复杂可能是 MQTT、CoAP、HTTP、TCP 私有协议甚至是通过 TF 卡/U 盘人工拷贝。设备端负责接收数据、临时存储、校验、状态管理、触发 bootloader 切换、执行写入、启动新固件、失败回滚。三端之间是强耦合关系打包端的镜像字段如果和设备端校验逻辑对不上升级必失败传输端的切包大小如果超过设备端接收缓冲区轻则重传风暴重则写坏 Flash设备端的状态机如果不考虑掉电、看门狗、非法跳转变砖只是时间问题。我在框架设计的初期会先画一张最简单的数据流图源服务器/PC 生成镜像传输通道把镜像拆包发给设备设备把数据写入临时分区校验通过后标记待生效状态重启后 bootloader 根据标志位决定启动哪个分区。这张图看起来简单但每个环节都藏着不少决策点。1.2 一次升级跨越多层每层都要有明确的失败处理更直白一点说升级框架是一个典型的“多步骤长事务”。普通函数调用失败了你还能回滚内存状态但升级涉及 Flash 擦写、重启、硬件状态切换一旦中间断了可能连回滚入口都没了。比如设备正在擦写 Application 区的时候突然断电如果没有任何保护机制重启后 bootloader 发现 Application 区是半擦状态校验失败进不了 App也没有其他固件可用设备就成砖了。所以框架设计的第一原则就是每一步把现场保护起来让失败在下一次上电时能被识别并恢复。这句话我会在后面反复提到因为几乎所有变砖事故归根结底都是“现场没有被保护”。1.3 “失败可恢复”应该写进需求而不是当作加分项有些项目把回滚功能当成“如果有时间再做”的锦上添花。我的建议是只要产品存在远程升级或者用户可自行升级的场景就必须把“升级失败后设备仍然可恢复”写进核心需求。否则出一次现场事故差旅和商务成本就远超你省下的那点 Flash 空间和开发工时。我之前做过一款工业数据采集器最开始方案只规划了一个 Application 分区想着反正有 bootloader升级失败最多再升一次。后来设备部署在野外基站维护人员根本不可能频繁到现场第一次 OTA 失败导致设备离线后团队只能派人出差刷机。那次之后我们重新翻工设计了双分区方案。这件事给我的教训特别深升级框架的复杂度应该由“失败后果”决定而不是由“开发成本”决定。2. 分区与启动策略单分区、双 bank 和 A/B 槽位怎么选2.1 单分区方案只适合本地可控场景远程 OTA 千万别碰单分区方案是所有方案里最简单的Flash 里只有一个 Application 区bootloader 负责接收固件并直接覆盖写入写完校验通过就跳转。它的优点是占用的 Flash 空间最少代码逻辑也最简单。缺点也很致命升级动作不具备原子性。如果写了一半掉电或传输中断Application 区处于不确定状态bootloader 很难判断该不该启动它。就算你有完整的 CRC 校验也只能发现“固件坏了”但发现之后你没有任何备选可用来启动。所以我的判断是单分区只适用于工厂烧录、现场调试、或者由专业人员配合编程器/调试器在场的场景。凡是面向终端用户的远程升级基本可以排除单分区。2.2 双 bank 是嵌入式 OTA 最常见的“性价比答案”双 bank 方案我习惯叫“双区互为备份”。它的思路是在 Flash 里划分两个足够大的区域一个作为当前运行区Active Bank另一个作为升级暂存区Inactive Bank。正常运行时数据从 Active 区读取收到升级包后先把新固件完整写入 Inactive 区校验通过后设置一个升级标志位重启后 bootloader 检查标志位把 Inactive 区和 Active 区进行整体切换或者把备份区数据搬运到主区。双 bank 最大的价值在于升级过程中旧固件始终完整保留在 Active 区。哪怕新固件写入一半断电甚至写完后校验失败bootloader 大不了不清除旧标志位继续启动旧固件设备仍然可用。我在实际项目里更倾向使用“标志位切换 启动时验证”的组合而不是直接把备份区数据拷贝回主区。原因很简单拷贝整片 Flash 耗时较长功耗和时间成本都高直接用向量表或者分区映射的方式切换启动速度几乎不增加Flash 扇区擦写寿命有限频繁整体搬运会加速损耗。当然双 bank 也有代价就是 Flash 占用翻倍。对很多成本敏感的小 MCU 来说这可能是个不小的门槛。如果你的 Flash 实在不够放两个完整固件也可以退一步做“压缩包 解压写入”但那样既要考虑解压算法又要考虑 RAM 占用复杂度反而更高。2.3 A/B 槽位更像是“双 bank 的加强版”适合高可用产品A/B 方案在双 bank 基础上增加了更细的槽位管理系统可以存在 A、B 两个槽位每个槽位都有完整的系统镜像设备启动时根据槽位标记选择其中一个运行正常后会把“当前槽位可用”的标记正式提交。下次升级时写入另外一个不活动的槽位。A/B 方案相比普通双 bank核心优势是升级确认机制更完整。很多双 bank 方案在 bootloader 里校验完 CRC 就认为升级成功但新固件实际启动后可能起不来——比如外设初始化失败、看门狗没人喂、驱动崩溃。A/B 方案允许新系统先试运行一段时间成功后才把槽位永久切换试运行失败自动回退到上一个正常版本。我刚接手带 A/B 方案的项目时会觉得它复杂但后来发现在车机、网关、医械这类对可用性要求高的产品里A/B 几乎是标配。它的主要缺点就是 Flash 占用、分区表复杂度、以及需要配套升级状态管理模块。三种方案对比下来我的大致建议是方案Flash 开销掉电容错回滚能力实现复杂度适用场景单分区最小差会变砖无低工厂烧录、现场调试双 bank约 2 倍较好旧固件保留可回退到上一个版本中物联网设备、中小型 MCUA/B 槽位约 2 倍以上很好带运行确认可自动回滚高网关、车机、高可用产品如果你第一次做 OTA预算允许我建议直接上带运行确认的双 bank。它比单分区复杂不了太多但安全性高了一个量级。2.4 别忽略预留的“恢复引导区”和“出厂固件区”只规划两个 App 分区还不够。我一般还会单独划一个很小的引导恢复区放着极简的出厂测试固件或者恢复固件。这个固件不参与日常业务只负责两件事当 bootloader 发现主备区都不可用时进入恢复引导模式等待串口/网络重新传输固件当设备需要恢复出厂设置时从恢复固件启动并重新烧写 App。看起来多占了几十 KB Flash但换来的是“即使两个区都坏了也有最后一条命”。特别是在设备已经量产的阶段这个恢复区能省下大量售后人力。3. 镜像头、三层校验与版本管理把升级包先做成“能被信任的东西”3.1 镜像头是设备端识别升级包的“身份证”很多人觉得升级包就是把编译好的 bin 文件直接传过去设备端拿到就写。实际项目里我会在固件前固定加一段镜像头让设备端在写入前就知道这个包是谁、给谁用的、版本多少、内容该不该收。下面是我常用的一种定义#define FW_HEADER_MAGIC 0x46575746 /* FWWF */ typedef struct { uint32_t magic; /* 固定魔数识别是否为合法升级包 */ uint32_t header_len; /* 镜像头长度 */ uint32_t version; /* 固件版本号用于防降级 */ uint32_t hw_id; /* 硬件兼容 ID跨型号混刷就靠它拦 */ uint32_t image_len; /* 固件数据长度 */ uint32_t image_crc32; /* 固件数据 CRC32 */ uint8_t reserve[16]; /* 预留字段可放签名、区域 */ } fw_header_t;设备端拿到升级包后第一步不是去接收整个文件而是先解析镜像头。magic 不对的包直接丢弃hw_id 不匹配直接终止version 低于当前版本直接拒绝。这些判断越早越好因为传输一个完整固件包既耗时又占 Flash 寿命。一个容易忽略的细节是header_len。不同版本的工具生成的固件包头部可能不同预留长度字段可以保证将来扩展字段时旧设备仍然能正确跳过头信息。3.2 三层校验链帧校验、包级校验、签名校验各管一段我把升级过程中的校验拆成三层缺一不可传输帧校验传输过程按块分包每块 256 字节或 1KB 加一个 CRC16/CRC32用来发现网络或者串口传输中的随机错误。这一层不通过就请求重传当前块不用等整个包传完。镜像包级校验整个固件接收完成后设备端对全镜像做 SHA256 或 MD5 校验和镜像头里存的摘要比对。这一层能发现传输过程中累计的数据缺损也能防止存储介质写入时出错。签名校验升级包用私钥签名设备端内置公钥bootloader 在决定写入前验签。这一层解决的是“数据来源是否可信”的问题而不是简单的“数据有没有坏”。很多工程师只做 CRC 不做签名理由是“我们是内网不会有攻击者”。但固件升级包的完整性校验和信任模型是两码事CRC 只能抗随机干扰防不了人为构造的恶意包。如果设备真的有远程升级能力却没有签名校验一旦攻击者拿到传输通道就能直接构造一个看似合法的升级包让设备加载任意代码。我们在设计安全要求稍高的产品时固件至少要用 RSA 或 ECDSA 做签名校验。哪怕是前期图省事我建议也在镜像头里留出签名长度字段方便后续加上。3.3 版本管理防降级、灰度升级、兼容性检查一起做版本管理看起来和 Flash 无关但它决定了升级框架的稳定度。我踩过的一个典型坑是现场有 100 台设备固件版本分散在 V1.0 到 V1.8 之间某次发布 V2.0 后部分老版本设备升级失败率高得离谱排查半天发现是老设备存储布局和新版本不一致。所以我在打包端会额外做这几件事防降级设备端判断新版本号必须大于当前运行版本号否则直接拒绝。这个规则避免现场误操作把新设备刷回旧版本导致的数据结构不兼容。硬件兼容 ID这个字段属于“防呆设计”。同一家公司往往有多个硬件版本引脚、传感器型号、存储容量都可能不同。没有 hw_id 时最常见的错误是把 A 型号的包刷进 B 型号运气好只是功能异常运气差直接驱动烧毁外设。灰度策略服务端分批发布先升级少量设备观察 24 小时成功率和离线率再把升级范围扩大到全网。这项策略看起来是运维层面的但它直接决定了框架的事故半径。此外建议在设备端保存一个“当前运行版本 最近一次升级结果”的日志重启后可以上报给服务端。远程诊断时这份日志往往比任何抓包工具都管用。4. 升级状态机的设计与掉电安全先写标志再做动作4.1 状态机是升级框架的“骨架”事件驱动每个转移我在实现设备端升级逻辑时不会把升级流程写成一长串顺序调用而是抽象成一个状态机。核心状态大致如下IDLE正常运行态等待升级指令。RECEIVING正在接收升级包写入临时分区。VERIFYING包接收完成做完整性校验和签名校验。PENDING_UPDATE校验通过写入升级标志等待重启。UPDATINGbootloader 完成分区切换/拷贝启动新固件。RUNNING_CONFIRM新固件运行确认成功后回到 IDLE确认失败则触发回滚。状态机的好处有两个。第一每个状态之间的转移动作都很明确便于代码评审第二掉电后重新上电bootloader 可以通过外部状态变量知道“上次进行到哪一步了”从而决定是继续升级还是回滚。比如设备正在 RECEIVING 时断电重启后 bootloader 发现临时区数据不完整可以直接清掉临时区回到 IDLE不影响当前运行的旧 App。在具体实现上我最关心的不是状态本身而是状态字段的存储方式。很多人喜欢把一个枚举变量直接放在普通 Flash 的某个地址但普通变量区在写入和读取之间容易丢失。我会把升级状态保存在一个独立的状态页并且每次写入前先擦除一整页再写入新状态页尾附带 CRC 校验。读取时如果 CRC 校验不过认定状态无效保守回退到 IDLE。4.2 “先写标志再做动作”掉电安全的核心操作顺序升级框架里有一个特别容易被忽视的问题执行顺序。我总结过一条规则任何高风险动作擦除、写入、分区切换执行之前先把描述该动作的标志写入持久存储动作完成后再更新标志状态。举个例子bootloader 要执行“从备份区切换为主区”。正确顺序是在状态页写入PENDING_SWITCH标志并附上目标分区标识和版本号执行分区映射切换切换完成后写入SWITCH_DONE标志跳转到新固件。为什么必须分两步因为 Flash 擦写过程不具备原子性。如果先在内存里改逻辑、再写标志中途断电后Flash 里的实际分区状态和标志可能不一致。下次上电时 bootloader 只看到旧标志就会错误地启动一个已经半擦写的分区。反过来先写标志再做动作即使动作没执行完上电后 bootloader 也能识别出“上次只做到一半”从而执行补偿逻辑。另外一个容易被忽略的顺序问题是擦写标志页的顺序。有些 Flash 擦除后默认全0xFF写入则只能把1变0。如果你要更新状态从0xA1变成0x33通常需要先擦除整个页再写入而擦除中断后该页数据可能残缺。所以状态页设计最好有两个备份页交替写入读取时按 CRC 判断最新页。这个小细节让我避免了至少两次现场救砖。4.3 看门狗、中断与 Flash 编程时长的关系升级过程中最隐蔽的“杀手”是看门狗。我曾经在一个项目里遇到升级进行到一半系统自动重启反复抓日志才发现是擦除大扇区耗时过长超过了看门狗溢出时间。尤其是一些内部 Flash 的擦除操作会阻塞指令执行中断处理也会受影响看门狗实际得不到及时喂食。处理方式有这么几种我按推荐优先级排列升级模式下拉长看门狗超时比如从正常的 2 秒拉到 30 秒并在下载/擦写过程中按块喂狗分段擦除不要一次性擦除整个大扇区每次擦一个小扇区后喂一次狗既能保证看门狗不死也降低单次阻塞时间如果 Flash 控制器支持后台擦写如 QSPI Flash 的 status polling可以在等待擦写完成期间用轮询方式继续执行其他轻量任务但要注意不要和中断抢占 Flash 控制器。还有一点是关于中断的。Flash 编程期间如果来了高优先级中断而中断服务程序里又访问了正在被编程的相同 Flash 地址可能会导致总线错误。所以我的习惯是在进入关键擦写流程前关闭可屏蔽中断或者确保中断服务程序不会访问 Flash 区间。像 STM32 这种内部 Flash 和向量表在同一空间的情况尤其要小心。5. 复盘四起真实升级事故从“升完变砖”到“远程救砖”5.1 事故一传输中断导致 App 区半擦设备彻底失联这是我第一份工作里遇到的事。设备通过串口接收升级包工程师为了保证简单直接写得一块 App 区就擦一块新数据流式覆盖。结果升级过程中维护人员拔了串口线擦了一半的 App 区里既有新数据又有旧残留bootloader 启动时 CRC 校验失败直接停在一个空壳状态既不启动也没法继续升级。那次修复是靠设备返厂用编程器重新烧录才救回来的。事后我们把方案整个改成“先收完整包到临时区校验通过后再拷贝到主区”。第一原则就是前面说的“失败可恢复”。也是从那时起我坚决不在没有临时存储区的情况下做覆盖式升级。5.2 事故二校验只做 CRC结果新固件能验过却不能启动另一个项目里升级包只有 CRC32 校验bootloader 验完就把新固件设为启动项。结果新固件在外部 RAM 初始化卡死了CRC 完全正常但设备根本跑不起来。系统也没有运行确认机制于是每台上电就卡在同样的位置只能靠售后逐台拆机处理。这个事故的直接原因是“校验通过”和“启动成功”之间隔着一道鸿沟。CRC 只保证了数据和源端一致并不能保证代码和当前硬件、配置、外设初始化兼容。从那以后凡是有条件的产品我都会在升级流程里加一个“试运行计数器”新固件启动后业务程序正常运行 60 秒后主动提交APP_RUNNING_OK标志如果启动后连续三次都没能提交bootloader 自动回滚到上一个可用版本。5.3 事故三跨型号误刷升级框架成功执行了不该执行的包这件事说起来有点丢人。项目里有 A、B 两款硬件主控相同但传感器供电引脚不同。打包端没做硬件兼容 ID某个维护人员把 A 型号的固件包推给了 B 型号设备。设备端升级流程完全成功没有任何校验拦截结果新固件启动后传感器驱动反复初始化失败部分板子还烧坏了传感器。后来我推动在镜像头和打包工具里都加入了hw_id字段并在设备端判断当前hw_id不匹配直接拒绝升级。这个字段花不了多少代码量但从源头上拦住了跨型号误刷。做多型号产品线的同学一定不要觉得这是小事。5.4 事故四读保护和 Flash 扇区保护让升级“假失败”这个坑属于硬件配置层面。有款产品出厂时为了防抄板开启了 STM32 的读保护并且把某些扇区设置了写保护。结果升级框架明明一切逻辑正常擦写却始终失败bootloader 每次上报WRITE_FAILED但真实原因是被保护扇区不允许写入。排查的时候我一度以为是代码逻辑问题后来用编程器和厂商工具检查选项字节才发现读保护等级冲突。解决方式是把升级需要的扇区加入可编程许可列表并且在升级流程里增加了对写保护状态的检测上报。如果你用的 MCU 有类似安全特性建议在升级前先读取并检查 Flash 选项字节避免“假失败”浪费大量排查时间。5.5 这些事故的共同点都是“没有保护现场”导致的回头看这四起事故共同点很有意思要么没有保证旧固件完整保留要么没有校验运行结果要么没有在源头拦截错误包。每一次都是升级框架里某个环节的缺失而不是某个驱动 BUG。所以我在项目评审时经常从事故的反向去追问设计升级到一半断电会怎样新固件起不来会怎样刷错型号会怎样如果答案是不确定说明框架还不够健壮。6. 工程化落地升级测试、发布节奏与回滚机制6.1 升级测试不能只在“正常路径”上跑我见过不少团队测试升级功能就是编译一个新版本从旧版本升上去看到进度条走完就报“通过”。这种测试覆盖远远不够。真正验证升级框架可靠性的测试至少要有掉电测试在升级过程的各个阶段随机断电然后重新上电检查设备能否按预期恢复或回滚。这个测试要靠继电器定时断电跑几百个循环坏包测试传输过程中故意篡改数据、截断数据确认设备不会把坏包写入正式区降级测试尝试用低版本包升级高版本设备确认被拒跨型号测试构造错误的hw_id包确认被拦Run/Reset 风暴测试新固件启动后立即反复复位验证“试运行确认”和回滚计数逻辑。这些测试看似多但很多可以自动化。我在 CI 里加过一个脚本用串口自动化工具循环给开发板下发不同状态的升级包再模拟断电自动统计恢复成功率。6.2 升级状态的上报与可观测性远程升级最怕的是“不知道设备现在卡在哪一步”。所以设备端我强烈建议维护一个升级日志区记录每一步的关键时间和结果码。日志不需要很长比如固定存最近 20 条记录每一条包含timestamp, phase, result。事故发生后通过串口或者上报机制拿到日志可以快速定位是网络中断、校验失败、还是启动确认超时。在没有实现远程日志的项目里也可以退而求其次把升级状态写到设备掉电不丢失的 RTC 后备寄存器或者独立 EEPROM 里重启后读取。这个状态信息哪怕只有几个字节也能让现场维护人员在拆机之前先判断问题方向。6.3 发布灰度、回滚开关和现场救砖通道最后聊聊发布层面的经验。升级框架做得再稳也不能保证 100% 不出问题所以发布策略非常关键。我的做法是发布阶段分三档灰度比例从 1% 到 10% 再到 100%。第一档选内部测试机第二档选少部分稳定客户第三档才全网发布。每一档之间至少间隔 24 小时盯两个指标升级成功率和设备离线率。哪怕设备端回滚逻辑完美灰度也能把影响面控制在很小的范围。服务端还要保留“回滚开关”这里的回滚不是指设备自动回退而是指“暂停继续下发升级包”。如果发现新版本有某些现场环境下才会出现的问题第一时间停止升级任务比逐台修改设备要快得多。最后的救砖通道也很重要。很多低成本设备没有远程调试能力一但变砖就得返厂。我在产品里会强行保留一个物理按键进入强制升级模式长按按键上电bootloader 跳过 App 校验直接进入串口或者网络下载模式。这个功能在量产阶段几乎救过我无数次强烈建议任何有升级能力的产品都加上。回到开头那句话固件升级框架不是一个 bootloader 那么简单。它贯穿了打包、传输、存储、校验、启动、回滚整个链路每一个环节都要用“假设它会失败”的心态去设计。如果你正在规划一个新项目的升级功能我建议先把分区方案和状态机想清楚再动手写代码。分区定错了后面改起来成本很高状态机没定好掉电恢复就是一句空话。别学我当年那样等设备在野外变砖了才回来补课。
