正文
大家好，我是bug菌~
最近被客户搞得一愣一愣的，你跟他谈技术，他跟你无话可谈，一直待在自己的认知里，当然客户是上帝，还得求着跟他谈，态度还得好，属实无奈~
相信搞技术的朋友最初有很大部分还是因为技术的纯粹与客观，然而随着职业的发展，不断地往上攀升就会发现似乎蒙头搞技术很难"吃遍天"，大一点的项目就得跟客户搞关系，并且得客户认可你的技术价值，难以独善其身，也就会变得越来越不纯粹了。
好了，还是聊聊今天的技术内容。
1
问题背景
大家在单片机程序开发升级功能的过程一定遇到过这种尴尬的场景：基础的IAP升级功能一切正常，然而由于你修改了App，在App中不小心引入了一个致命bug，编译成功直接生成了烧录文件，且生成了对应的升级文件完整性校验，当你把该完整的升级文件烧录完成以后，哦豁，完蛋，boot校验App文件校验通过，运行App直接卡死，你尝试重新上电同样却还是继续跳转卡死。
此时的你只能乖乖的找来烧录器如jlink进行调试找出这个卡死App的bug并重新烧录，当然这在开发的过程中还相对比较简单，但如果电路板没有引出烧录接口且被封装在了一个非常难拆的机器内，那这个过程工作量就大了。
是否有其他设计方案能够规避掉这种问题呢？
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进阶专辑 
☞ “bug说”专辑 
☞ 专辑|手撕C语言
☞ 专辑|经验分享
3970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
