良许Linux教程网 干货合集 嵌入式固件升级防变砖的几种方法

嵌入式固件升级防变砖的几种方法

汽车软件中,Boot程序主要作用就是刷新App程序。在实际项目开发中,Boot程序往往也是客户需求的一部分,并且通常会有详细的软件开发计划。有些项目还会将Boot程序与其他Boot程序区分开来,并称其为CB(Customer Boot)。

对于已经下线的控制器,在供应商或客户手中进行测试时,只能通过CB来刷新App程序。如果需要CB自刷新,则需要采用额外的方法。

以下是五种Boot自更新方式的优缺点,供大家参考:

  1. 方式一:SB更新CB

根据图1-a的软件架构,有些项目采用两级Boot架构:SB+CB。Start Boot只需要检查CPU最小系统,与具体项目的外围电路无关,通常由供应商自行维护,在Pilot项目早期就应该完成开发。

由于程序启动顺序是SB->CB->App,因此在SB中增加刷新逻辑便可以更新CB。通常情况下运行CB来更新App程序,但特殊情况下,如果程序启动后一直停留在SB中,也可以通过更新CB的方式来更新App程序。

该种方式的优点在于实现简单,不需要额外的硬件资源,但缺点是需要考虑各级Boot的兼容性,同时也存在代码兼容性的问题,需要在项目初期规划好。

优点:

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

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

缺点:

1.需要较大的Flash空间在SB里存放刷新逻辑,项目SOP后又要禁止这种刷新方式,造成额外的浪费。

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

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

image-20231030221802515
image-20231030221802515

**
**

方式二、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-20231030221806306
image-20231030221806306

方式三、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-20231030221809925
image-20231030221809925

**
**

方式四、借助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-20231030221813196
image-20231030221813196

**方式五、借助额外Flash空间

**

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

\1. 图5-b,运行CB,刷入ReBoot到额外Flash。

\2. 图5-c,运行ReBoot,更新CB。

\3. 运行新的CB,破坏ReBoot(全部擦除,或只擦除ReBoot有效性标志)

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

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

image-20231030221816630
image-20231030221816630

**小结:

**

本质上只有三种:

\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-20231030221820210
image-20231030221820210

考虑CPU至少具备两个启动地址的情况,如图1-a,当且仅当启动地址1有效时(App为空),程序启动后自动进入Boot。如图1-b,当且仅当启动地址2有效时(不带Boot测试),程序启动后自动进入App。

如图1-c,当启动地址1,2都有效势,程序优先从地址1启动,在Boot里检查App程序有效时,再靠跳转指令Jump到启动地址2,开始运行App。

image-20231030221823143
image-20231030221823143
image-20231030221826743
image-20231030221826743

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

如图 2-a,运行Reboot更新CB途中断电。重新上电后,如图2-b,由于启动地址1的内容是在刷新开始就被更新了是有效的,程序会进入CB运行,但是CB不完整,必然运行出错,程序不会跳入ReBoot里,从而不能再刷新(即刷死)。

假设从擦除完旧CB开始到刷入新CB完成的时间有10S,在此期间掉电的可能性也不能忽略。

对策一、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-20231030221834440
image-20231030221834440

对策二、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-20231030221840622
image-20231030221840622

小结:

对策一简单可靠,经过实际测试验证,完全可以满足稳定刷新ECU的要求。

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

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

作者: 良许

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

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

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

微信扫一扫关注我们

关注微博
返回顶部