HTTP协议固件升级（三）

固件激活阶段的核心是实现“无缝切换”与“安全回退”，依赖设备端Bootloader的双分区管理能力。校验通过后，设备会更新OTA状态区的“激活标记”，指定下一次启动时加载空闲分区的新固件，随后触发设备重启；重启后，Bootloader首先读取OTA状态区，若激活标记有效，则初始化新固件所在分区，验证固件的魔法数（如固定的0xAA55）与版本兼容性，确认无误后跳转到新固件执行；若新固件启动失败（如启动后10秒内未向Bootloader发送“启动成功”信号），Bootloader会自动触发回滚机制，清除激活标记，重新加载原固件分区，确保设备不会因新固件故障而“变砖”。部分高端设备（如STM32H7、ESP32-S3）支持“无缝升级”，即在应用固件运行的同时，将新固件写入备用分区，写入完成后无需重启，通过内存映射切换直接加载新固件，适用于对停机时间敏感的场景（如医疗设备、工业生产线控制器）。

结果反馈阶段是升级流程的收尾，设备需将最终的升级状态（成功/失败及原因）上报至云端，便于云端更新设备版本记录与调整策略。若升级成功，设备发送“升级成功”请求，携带新固件版本与启动时间；云端收到后，将该设备的版本状态更新为新版本，并停止向其推送旧版本升级指令。若升级失败（如校验失败、激活失败），设备需上报失败原因（如“哈希不匹配”“固件启动超时”），云端记录失败信息，根据原因制定重试策略——例如因“网络中断”失败的设备，可在1小时后重新触发升级；因“固件损坏”失败的设备，则需等待云端重新推送正确的固件。

HTTP固件升级的轻量化优化是适配资源受限设备（如8位MCU、KB级RAM）的关键，需从协议栈、内存占用、功耗控制三个维度展开。协议栈层面，选择专为嵌入式设计的轻量级HTTP Client库（如uHTTPc、Mongoose的嵌入式版本），这类库通常仅保留HTTP/1.1的核心功能（如GET/POST请求、Range头支持），去除冗余模块（如Cookie、表单解析），代码量可控制在10KB以内，RAM占用仅需2KB~5KB，远低于通用HTTP库（如libcurl）。内存优化方面，除了采用“分块下载-即时写入”策略减少RAM占用，还可通过“固件压缩”进一步降低传输与存储压力——云端将固件通过gzip或LZ77算法压缩，设备下载后在Flash中直接存储压缩固件，激活前再通过硬件或软件解压（如STM32的硬件解压模块），压缩率通常可达30%~50%，例如1MB的固件压缩后仅需600KB Flash空间，适配小容量Flash设备。功耗控制则需与设备的低功耗模式协同，例如在固件下载间隙（如等待云端分块数据），让网络模块（如ENC28J60）进入睡眠模式，关闭未使用的外设（如UART、I2C），仅保留核心电路供电，将电流从几十毫安降至微安级；对于电池供电设备（如NB-IoT水表），可选择在设备空闲时段（如夜间用水低谷）执行升级，避免升级过程与业务数据采集争抢功耗资源。