【重磅】剖析MCU的IAP升级软件设计(设计思路篇)

     今天为大家推荐一首毛不易的《像我这样的人》，上面链接是现场版本音效上略有打折，不过歌曲所要传递的那份感情全在词里了，在成长的过程中人总会遇到几个情绪低落的阶段，面对现实的世界会觉得非常的力不从心，甚至想逃离现状，如果当你想到世界上还有更多像你这样的人正在努力让生活变得更好，也许这一切就并没有你所想象的那么糟糕了！

    在我们学习MCU的过程中经常看到IAP、ISP、JTAG等等一些与在线编程相关的专业名词，可能很多小伙伴到现在都迷迷糊糊的，作者这里简单为大家介绍一下:

    ICP表示在电路编程，MCU内部不需要有程序，直接上电就能够进行对程序存储区域进行编程的方式，我们平时使用JTAG或者SWD等等就属于这种方式。

    ISP表示在系统编程，通过MCU专用的串行编程接口进行编程，那也就是说MCU需要具有运行的外部条件，比如需要有晶振等等。比如说平时使用的stm32通过设置boot引脚设置对应启动模式，然后通过串口等对内部Flash进行升级，可以说这种方式就是厂家在芯片内部固化了一个BootLoader程序。

    IAP表示在应用编程，这种名词应该是大家在平时学习过程中见得比较多的，相当于自己定制一个BootLoader程序，自己通过编程设计可以实现各种升级的方式比如串口、CAN、以太网等等，非常的灵活。其实这个BootLoader程序也是我们自己设计的程序，你也可以认为是一个App程序，相当于通过对App划分职责对自己进行更新和升级。这种方式也就是我们今天话题的主角。

    作者最早开始结实IAP这个概念还是在大学进行飞思卡尔智能汽车比赛期间，了解的小伙伴应该知道我们大部分时间都是在"烧车"-(也就是车子不行的在赛道上进行测试)，特别是调试PID或者是发现识别算法的Bug以后，要么就是去拿车过来烧录，要么就是拿着笔记本过去进行烧录，这样有时候还真是体力活，后来无意间看来一篇技术报告谈到了远程无线升级，当时自己调参数也是用蓝牙调试，便开始研究这个功能，折腾一段时间，因为需要对芯片的启动过程等等进一步的熟悉，不过后面确实挺方便的，基本上换了电池以后我就只需要坐着写代码升级即可。

    至于到了现在的实际工作过程中，这种升级功能的需求成了软件设计的必备项目，那有小伙伴可能就会问了:我觉得用烧录器烧录挺快的呀，每次想要升级直接用烧录盒烧录不就行了吗？好，那比如说现在你在深圳，客户在北京，你还得每次还要跑到客户现场去升级吗?到了客户现场难道你还要拆客户的机器插上烧录器吗？实在是太麻烦了，还是选择远程升级吧，同时IAP还会有更加严格的测试要求，比如烧录过程中的断电，断网络等等系统的动作和后续修护问题都是要进行考虑和设计的。

    对于我们的MCU现在大部分的都是使用Flash来存储程序，同时程序内部也会有读写Flash的接口函数，中断也可以方便的重定位，这样就非常适合IAP程序的开发。

    作者这里画了一张现在目前比较普遍的升级软件设计图:

    解析一下:我们把MCU的Flash分区分为如上图所示的三个部分，Bootloader就是我们所要编写的启动程序，App程序为项目的实际应用程序，Param区域是用于存储相应的版本App的版本信息以及完整性校验标志序列等传递数据区域。

    工作方式1:当MCU启动以后运行Bootloader程序，检测到Param参数区域是否存在App记录，如果存在App直接运行App程序即可，如果不存在，则向PC机请求App文件。

    工作方式2:当MCU运行App过程中，接收到PC机的升级请求，更新Param参数区域，并跳转到BootLoader进行App程序的接受和升级，升级完成以后处理Param参数区域并运行对应的新App程序。

    V1.0算是比较常规的应用案例，我们都知道对MCU内部Flash进行编程一般会有解锁、擦除、写入和验证几个阶段，当我们擦除原来MCU存储的App程序以后如果手头上没有相关的固件，基本上就不能恢复了，这样如果我们想退回到之前的版本不可能了！于是升级方案还需要在改善一下。

    为了解决V1.0提出的问题我们App分成了两部分如下图所示:

    解析一下:上面两张图的原理是一样的，都是把接收到的新App保存起来(如果你用于备份老的App也是可以的)，图1是通过把MCU内部Flash进行划分，一部分用于存储新App，另外一部分是原来运行的App区域，这样的话，当我们通过bootloader接收完完整的新App进行校验、解密处理以后便可以写入到平时运行的App区域，从而防止了V1.0在升级过程中掉电、通信异常导致擦除了App的问题。

    同时，我们也可以把上一版本App备份到我们预留的内部Flash或者外部存储设备中，如果想还原系统即可直接通过PC发送相应命令进行恢复即可。

    好了，又有小伙伴提出问题，大家都知道我们自己编写的BootLoader是非常灵活的，可以支持多种通信协议的升级模式，不过在前期我们可能没有考虑完善，后续想进一步完善相应功能就需要我们对Bootloader进行升级，那么我们可以通过App对Bootloader进行升级操作，一般这种方式就可以满足需求，不过如果在升级BootLoader过程中发生故障，那Bootloader全部被擦除导致整个MCU变成了个砖头。好吧，是时候上V3.0版本的IAP程序了。

    为了解决V2.0问题，作者设计了第三种升级方式:

    解析一下:在V2.0的基础上我们增加了Bootloader2，对于Bootloader1相当于固化在MCU中自定义的一种升级方式，而Bootloader2是可以根据我们启动升级需求进行升级的区域，这样即使在升级过程中擦除，我们也可以通过BootLoader1或者App2来进行恢复Bootloader2。

    不过具体的实现过程会设计到较多的逻辑处理，大家在实现该方案的同时需要前期进行软件上的设计和梳理。

    对于IAP软件方案作者就分享到这里，大家在选择在线升级方案的同时需要结合自身项目的需求来考量，对于具体的实现过程还是有很多技术细节需要注意的，比如代码的地址链接、中断的重定位方案、软件的加密等等，后续有时间再针对具体的技术细节进行分享。

    好了，这里是公众号:“最后一个bug”，一个为大家打造的技术知识提升基地。同时非常感谢各位小伙伴的支持，我们下期精彩见！

推荐好文  点击蓝色字体即可跳转

【连载】重温C++之面向对象（第一篇）

顿悟,神秘的register关键字(C语言篇) 

【典藏】深度剖析单片机程序的运行(C程序版) 

【连载】通过"库文件"学单片机驱动编程(5)-完结篇

 C语言为什么一般不在.h中定义函数或者变量?(精华)

手把手教你写Modbus-RTU协议(理论篇)

深度剖析"bit序"与"字节序"(追思永念)

听说因为代码没"对齐"程序就奔了?(深度剖析)

【典藏】自制小型GUI界面框架(设计思想篇)