正文
1
问题背景
2
常规处理方式
对于boot自带通信功能(如串口、USB等)的系统，可以在boot跳转App前检查是否存在更新App请求，如果存在则进入升级模式，把原有异常的App替换掉。
这样的方案其实在uboot或者电脑的BIOS中都能看到影子。
3
变体
上面的方案根据项目外部的交互接口不同，可以进一步演变，上面我们介绍的是等待通信命令，然而有些项目并没有通信接口等，只有按键，那么可以在boot跳转App前检测是否对应的按键长时间强制按下，而进入升级请求状态，这种方式在一些消费类的小项目中比较常见。
4
不想重启
大家应该有注意到，上面的方案麻烦点的就是要重启，有复位按键再好不过了，然而有些系统掉电时间较长，或者不允许外部异常复位，那重启操作起来就比较费时。
最常用就是应用程序自身开启了watchdog，这样当我们不小心烧录了卡死程序，没有及时喂狗就会导致重启进入boot，然后又可以进入前面介绍的强制升级流程了。
当然对于对开机速度有要求的项目，可以在boot里检测是否为watchdog复位再让延时等待请求介入。
5
boot比较小
有时候我们不想把boot设计得非常复杂，驱动太多需要改来改去，那么可以采用AB面升级方式。
如果当前升级的App异常，也可以重新上电回退到上一个可用App版本，这样在上一个版本进行新App的更新。
最后
好了，今天就跟大家分享这么多了，如果你觉得有所收获，一定记得点个赞~
bug菌唯一、永久、免费分享嵌入式技术知识平台~
推荐专辑 点击蓝色字体即可跳转
☞ MCU进阶专辑
☞ 专辑|手撕C语言
☞ 专辑|经验分享
