良许Linux教程网 干货合集 单片机固件自更新的方法

单片机固件自更新的方法

随着物联网的普及,许多嵌入式控制器产品都提供了固件升级的功能,比如汽车软件中的引导程序。在某个具体的客户项目中,引导程序也是客户需求的一部分,作为项目的一部分,通常会有软件开发计划(有时为了与其他引导程序区分,项目中的引导程序被称为CB,即客户引导程序)。

对于已经部署的控制器,无论是在供应商还是客户手中进行测试,都只能通过CB来更新应用程序。如果需要CB自动更新,就需要额外的方法。

根据规范,整车厂只有对应用程序进行刷新的规范,没有对引导程序自动更新的规范。因为规范通常是针对量产车辆的,售后服务只负责应用程序的升级,不允许或负责引导程序的升级。

因此,引导程序的自动更新仅存在于项目开发阶段,并由供应商自行提供解决方案。本文将分析五种引导程序自动更新方式的优缺点。

第一种方式,SB更新CB:

如图1-a所示,某些软件架构采用两级引导程序:SB+CB。启动引导程序仅检查CPU的最小系统,与具体项目的外围电路无关,它独立于客户需求,由供应商自行维护,在项目早期应该完成。由于程序启动顺序是SB->CB->应用程序,因此可以在SB中添加刷新逻辑来更新CB。通常情况下,运行CB以更新应用程序,但在特殊情况下,程序启动后会一直停留在SB中,以便更新CB。

优点:

  1. 逻辑结构简单清晰,软件分工明确。

  2. 一次刷新,操作简易。

缺点:

  1. 需要在SB中占用较大的Flash空间来存放刷新逻辑,在项目标准操作程序(SOP)后又必须禁止此种刷新方式,造成额外资源浪费。

  2. 软件分为三级启动,结构复杂,开发和维护成本较高。对于不需要SB的控制器,这是一种负担。

  3. 如果SB也需要更新,怎么办?按照这种策略,还得再做一个SB?显然不现实。

image-20240329225539690
image-20240329225539690

方式二、RAM+Flash Reboot更新

如图2-a,不存在SB情况下,程序启动顺序是CB->App。需要刷新Boot时,首先把Reboot程序下载到不用的RAM里(图2-b),然后在RAM环境下运行ReBoot,下载新的CB(图2-c)

优点:

\1. 不需要额外的Flash空间,Boot程序运行只需要少量的RAM,因此为App设计的RAM临时可以保存Reboot程序。

\2. RAM擦写速度很快,则下载ReBoot的速度会很快。

缺点:

在CB更新过程中万一CPU掉电,重新上电后Reboot内容全无,CB已经破损,程序不能正常启动,控制器瘫痪,只能开盖用JTAG烧写程序。

image-20240329225542971
image-20240329225542971

方式三、RAM+RAM ReBoot更新(对方式二的改进)

首先把ReBoot(蓝色)+NewCB(紫色)一起都下载到RAM里(图3-a),然后运行ReBoot,擦除CB Flash区域,将RAM中NewCB复制到CB Flash区域(这一步内部完成)。最后,重新上电复位,RAM中的ReBoot和NewCB自动丢失,程序从新的CB开始运行。

优点:

1.相比方式二少了一步刷新(因为ReBoot和CB是绑在一起的)。

2.相比方式二CB更新全部在CPU内部执行,不受外界干扰,耗时更短。

缺点:

\1. 相比方式二需要更大的RAM空间存储ReBoot+NewCB。

\2. 和方式二一样存在CB更新阶段掉电后控制器瘫痪的风险 。

image-20240329225547308
image-20240329225547308

方式四、借助App程序Flash空间

刷新分三步:1.图4-b运行CB,擦除App,把ReBoot下载到App区域。2.图4-c运行ReBoot,擦除旧CB,刷入新CB。3.图4-d运行新CB,刷回App。

优点:

1.不需要额外的Flash和RAM资源。

2.稳定可靠,通过优化设计,可以保证在任何一个步骤突然掉电,上电后可以继续操作,控制器不会刷死。(详细设计方法请看附录)

3.对CB做稍微改造就可以成为Reboot程序,开发快速。

缺点:

1.步骤繁多,为了更新CB必须要先擦除App,最后恢复App,至少三次刷新。对不熟悉步骤的操作者容易搞混乱。

2.整体刷新时间会较长,两次Boot+一次App

image-20240329225550339
image-20240329225550339

方式五、借助额外Flash空间

相比方式四,需要一块和CB一样大小的额外Flash空间,刷新分三步:

  1. 图5-b,运行CB,刷入ReBoot到额外Flash。
  2. 图5-c,运行ReBoot,更新CB。
  3. 运行新的CB,破坏ReBoot(全部擦除,或只擦除ReBoot有效性标志)

优点:相比方式四,不需要破坏App程序,也省去了这部分更新时间。

缺点:相比方式四,需要额外的Flash空间,且必须是独立的Block。

image-20240329225553952
image-20240329225553952

小结:

本质上只有三种:

  1. 依赖启动程序SB(方式一),当CPU的Flash资源很富余且项目需要两级Boot时,用该方法最节省时间。
  2. 借助RAM(方式二、三)3.借助Flash(方式四、五)。只需要单级Boot(CB)时,可以容忍因Boot刷新瘫痪必须要给控制器开盖带来时间,人力,物力的成本损耗的情况下用方式二,三较方便。
  3. 只需要单级Boot(CB)时,不允许或不方便控制器开盖,但可以容忍Boot更新步骤繁多时间较长的情况下用方式四、五最可靠。

综上,工程师需要根据整体软件架构,CPU资源,时间人力物料等成本因素综合考虑一种适合自己产品及项目的Boot自刷新方法。

附录:

《Boot自刷新方式四(借助Flash)的具体实现方法》

背景:

对于方式四借助Flash刷新【不存在刷死风险,在任何一个步骤中控制器突然掉电,上电后可以继续操作。】的结论,是有条件的。笔者给出这个结论是从最理想的前提思考的,即只要控制器中至少有一个Boot存在(即使一个是坏的),程序就可以从任何一正常的Boot启动运行。这里就有一个问题,CPU怎么判断哪个Boot是好的,哪个是坏的?现在分析一下存在控制器刷死这种风险的情况和几种对策方案。

两级启动地址介绍:

如下图示,CPU上电后程序按地址顺序,检查BootSector的有效性,如果BOOT_ID合法则从指定的地址开始执行,否则检查下一个BootSector。

image-20240329225556869
image-20240329225556869

考虑CPU至少具备两个启动地址的情况,如图1-a,当且仅当启动地址1有效时(App为空),程序启动后自动进入Boot。如图1-b,当且仅当启动地址2有效时(不带Boot测试),程序启动后自动进入App。如图1-c,当启动地址1,2都有效势,程序优先从地址1启动,在Boot里检查App程序有效时,再靠跳转指令Jump到启动地址2,开始运行App。

image-20240329225559918
image-20240329225559918
image-20240329225603643
image-20240329225603643

方式四控制器刷死情况分析:

如图 2-a,运行Reboot更新CB途中断电。重新上电后,如图2-b,由于启动地址1的内容是在刷新开始就被更新了是有效的,程序会进入CB运行,但是CB不完整,必然运行出错,程序不会跳入ReBoot里,从而不能再刷新(即刷死)。假设从擦除完旧CB开始到刷入新CB完成的时间有10S,在此期间掉电的可能性也不能忽略。

image-20240329225606990
image-20240329225606990

对策一、Boot有效性标志与启动地址重合

考虑最普遍情况,CPU只能整块(Block)的擦出(16K,32K,64K…),可以最少4字节单位写,没有顺序限制,现在CB只用了一个Block。现在调整刷新顺序:擦出成功后,先刷新橙色区域,最后一步刷新启动地址1有效性标志(灰色区域)。这样,即使在更新橙色区域过程中掉电。

重新上电后,程序依然从启动地址2开始运行,即重新运行Reboot继续等待刷新CB指令,如图3-a所示。具体操作时也不需要更改下载流程,使用$34,36服务按顺序从上位机传输数据到CPU中,先把启动地址1的有效性标志放到RAM里,当把橙色区域都下载到Flash后,再从RAM里把启动地址1的有效性标志写到Flash里(这一步10ms以内即可完成,完全可以忽略在此时间内掉电的可能性)

如果最后一步启动地址1刷新成功,再重新上电后,程序从启动地址1开始运行新的Boot。即启动地址1起了Boot有效性标志的作用(最先擦,最后写),如图3-b所示。

image-20240329225611027
image-20240329225611027

对策二、Boot有效性标志独立置尾,增加Boot有效性检查逻辑

如图4-a,把Boot分成2个段,Sec1里仅存放少量的启动自检查逻辑,当它检测到置于Sec2末尾的CB_ValidFlg无效时,即认为Boot是不完整的,则程序控制跳转到启动地址2继续运行ReBoot,重新刷新Boot。

如图4-b,当Sec1的逻辑检测到CB_ValidFlg有效时,即认为Boot刷新完成,则程序控制跳转入Sec2里,此时由于App(ReBoot)末尾的App_ValidFlg是无效的,程序并不会跳转入ReBoot里,接下来就可以刷入新的App了。

这种方法只需要对CB的逻辑和段分配做一下调整,不需要更改刷新顺序。Sec1里的启动自检查逻辑可以做的尽量小,则只要保证刷新Sec1段的过程中不掉电,控制器就不会刷死,大大降低风险。但是对量产软件,检查CB_ValidFlg无效就直接跳转入App是不合理的,所以当Boot最终定型后,应该把这个跳转逻辑关闭。

image-20240329225615135
image-20240329225615135

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

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

作者: 良许

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

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

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

微信扫一扫关注我们

关注微博
返回顶部