相信搞技术的朋友都遇到过类似的尴尬：基础IAP升级功能一切正常，然而由于App程序被修改，不小心引入了一个致命bug。编译成功生成了烧录文件，也做好了文件完整性校验，当你把这份“完整”的升级包烧录完成，重启后，Boot校验App文件通过，但一跳转到App，程序直接卡死。尝试重新上电，依旧重复跳转并卡死的循环。
这时候，你只能乖乖找来烧录器（比如 JLink）进行调试，找出让App卡死的bug并重新烧录。这在开发阶段相对简单，但如果电路板没有引出烧录接口，又被封装在了一个非常难拆的设备内部，这个修复过程的工作量就非常惊人了。
那么，是否有其他的设计方案能够规避掉这种“升级即变砖”的风险呢？今天我们就来探讨几种实用的IAP方案改进思路。
1. 常规处理方式：让Boot“等等看”
对于Boot本身自带通信功能（如串口、USB等）的系统，一个常见的优化是：在Boot跳转App之前，先检查是否存在更新App的强制请求。如果存在，则进入升级模式，用新的、正常的固件替换掉当前有问题的App。
这种方案的流程大致如下：
具体来说，系统启动后，Boot会进行一个短暂的轮询（例如5秒），检测是否有来自通信接口的强制更新请求。如果收到请求，则进入升级模块，接收并更新App；如果没有，则直接跳转到现有的App运行。
这个思路其实在很多成熟系统中都能看到影子，比如Uboot或者电脑的BIOS，它们都具备在启动阶段接收外部指令并进行系统修复或更新的能力。
2. 方案变体：用按键触发升级
上面的方案依赖于通信接口。如果项目没有预留通信接口，只有物理按键呢？这时方案可以进一步演变。
我们可以在Boot跳转App前，检测特定的按键是否被长时间强制按下（比如按住不放超过10秒）。如果满足条件，就判定为进入强制升级请求状态，此时Boot可以等待从其他途径（如SD卡、内部预留接口）接收升级包。这种方式在一些对成本敏感、交互简单的消费类小项目中比较常见。
3. 如何避免“必须重启”？
细心的你可能已经发现，上面的两种方案都有一个前提：需要系统重启，让执行流程再次回到Boot。有复位按键还好，但有些系统掉电后重启时间很长，或者出于稳定性考虑不允许外部异常复位，那么“重启”这个操作本身就比较费时。
怎么办呢？最常用的方法是让应用程序自己开启看门狗。这样，当我们不小心烧录了一个会卡死的程序，由于程序卡死无法及时“喂狗”，看门狗超时就会触发系统复位。系统复位后，自然就进入了Boot，此时就可以接入前面所说的强制升级流程了。
对于开机速度有严格要求的产品，还可以在Boot里做一个判断：如果本次复位是由看门狗触发的，则延长在Boot中的等待时间，给强制升级请求的介入创造机会；如果是正常上电，则快速跳转，不影响开机速度。
4. Boot太小？试试“AB面”升级
有时候，我们希望Boot做得尽量简洁、稳定，不想在里面集成复杂的驱动和通信协议。这时，“AB面”（或叫“双备份”）升级方式就派上用场了。
其核心思想是将Flash划分为三个主要区域：Boot区，App1区（A面），App2区（B面）。系统总是从Boot启动，然后由Boot决定跳转到哪个App区运行。升级时，新的固件被写入当前未运行的那个App区。
假设当前正在运行App1（A面），升级时新固件被写入App2（B面）。写入完成后，Boot在下次启动时，会校验新固件（App2）的有效性。如果校验成功，则跳转到App2运行，并将App2标记为“当前使用面”。
关键在于降级回退机制：如果新写入的App2有严重bug，导致系统无法正常运行（例如卡死触发看门狗复位），Boot在重启后检测到App2启动失败，可以自动回滚，跳转到之前稳定可用的App1版本。在App1这个旧版本中，可以再次尝试接收和处理新的升级包。
这种方式极大地提升了系统在固件升级过程中的鲁棒性，即使升级失败，也有“后悔药”可吃，保障了设备的基本运行功能。
总结
从依赖Boot通信的强制升级，到结合看门狗的自动复位，再到更稳健的AB面升级，这些方案都是为了解决同一个核心问题：如何安全、可靠地完成嵌入式设备的远程或现场固件更新，并最大限度避免因升级失败导致设备“变砖”。
选择哪种方案，需要根据项目的具体约束（硬件资源、接口、成本、可靠性要求）来权衡。理解这些设计模式背后的思想，能够帮助我们在面对具体的嵌入式项目时，设计出更贴合需求、更健壮的OTA/IAP方案。
技术的道路总是在解决一个又一个的实际问题中延伸。如果你有更多关于固件升级或嵌入式开发的心得，欢迎在云栈社区交流分享。
发表于 15 小时前
|
查看: 1|
回复: 0
