良许Linux教程网 干货合集 剖析MCU的IAP升级软件设计思路

剖析MCU的IAP升级软件设计思路

作为从事软件开发的人,我们都了解程序的升级过程。升级软件的方式有多种,今天我们来讨论一下软件升级的设计思路。

一、ISP/ICP/IAP 名称解释

在学习单片机的过程中,经常会遇到 IAP、ISP、JTAG等与在线编程相关的专业名词。可能很多人对这些名词依然感到困惑,下面我给大家简单介绍一下:

  1. ICP -(In-circuit programmer)

ICP 代表在电路中编程,这种方式无需在单片机内部存储程序。只需上电即可对程序存储区域进行编程。我们通常使用的 JTAG 或 SWD 等方式就属于这种方式。

  1. ISP – (In-system programmer)

ISP 代表在系统中编程,通过单片机专用的串行编程接口进行编程。也就是说,单片机需要具备外部运行条件,如需要有晶振等。例如,我们平时使用的 STM32 单片机,通过设置 boot 引脚来设置相应的启动模式,然后通过串口等方式对内部 Flash 进行升级。可以说,这种方式是厂家在芯片内部固化了一个 BootLoader 程序。

  1. IAP – (In-application programmer)

IAP 代表在应用程序中编程。这个名词在学习过程中应该是大家比较熟悉的。它相当于自定义一个 BootLoader 程序,通过编程设计实现各种升级方式,如串口、CAN 以太网等,非常灵活。实际上,这个 BootLoader 程序也是我们自己设计的程序,可以看作是一个 App 程序,通过划分职责对自身进行更新和升级。这种方式也是我们今天讨论的主题。

二、MCU软件升级设计思路

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

1)IAP升级V1.0

升级软件设计图:

image-20231211203732447
image-20231211203732447

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

image-20231211203735190
image-20231211203735190

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

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

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

2)IAP升级V2.0

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

image-20231211203738726
image-20231211203738726
image-20231211203741585
image-20231211203741585

解析一下:上面两张图的原理是一样的,都是把接收到的新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程序了。

3)IAP升级V3.0

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

image-20231211203828790
image-20231211203828790

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

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

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !

137e00002230ad9f26e78-265x300
本文由 良许Linux教程网 发布,可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
良许

作者: 良许

良许,世界500强企业Linux开发工程师,公众号【良许Linux】的作者,全网拥有超30W粉丝。个人标签:创业者,CSDN学院讲师,副业达人,流量玩家,摄影爱好者。
上一篇
下一篇

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部