我不知道任何预制的解决方案，但我将描述我如何在一个项目中解决它。它并非完全“牢不可破”，但我不知道它在数千次升级中失败了。对于此应用程序，非常低的故障率仍然比必须访问单元便宜。

主应用程序在其正常通信协议中添加了三种额外的数据包类型，其中包括错误检测和重试策略：

1. 开始固件更新命令清除外部 SPI 闪存中的保留存储区。如果设备使用备用电池运行或使用外部电源运行但电池充电状态低于 25%，则会返回错误。

2. 写块命令接受偏移地址和以小块写入外部闪存的数据。更高级别的协议负责错误检测和重传。在每个块被写入之后，它会在命令被确认之前被读回和验证。

3. 完成固件更新命令包括接收到的固件应具有的长度以及整个映像的 CRC32，以供进一步验证。如果这与外部闪存的内容相匹配，并且电源条件仍然可以，则相同的长度和 CRC32 与“幻数”一起被传输到 EEPROM 区域，以指示固件更新正在等待。

4. 在主应用程序中执行一个硬循环来强制看门狗重启。

5. 引导加载程序（位于 ARM 闪存的写保护区域）看到 EEPROM 中的幻数并再次验证映像的 CRC32。如果一切正常，它会将图像从外部闪存传输到 ARM 闪存的主程序区域。

6. 挂起的升级信息会从 EEPROM 中清除，并且硬循环会强制重新启动。这次引导加载程序将正常启动主应用程序。

虽然我从未见过更新阶段失败，但在部署之前测试新固件版本是使用这种方法的关键。如果新版本无法连接到 GSM 网络并无法接受未来的更新命令，则需要进行现场固件更新。

您是在运行 Linux 还是 RTOS，还是裸机？如果使用 Debian，您可以拍摄当前文件系统的快照，通过“apt-get”进行升级，然后根据它是否有效保留或回滚更改。