Cherry007 发表于 2022-11-23 20:33:25

五种单片机固件自更新的方法/Boot

汽车软件Boot程序的主要作用是刷新App程序。在一个具体客户项目中,Boot也是客户需求的一部分,跟随项目也有软件开发计划(有的为了和其它Boot区分,把项目上的Boot称作CB, Customer Boot)。
对于已经下线盒盖的控制器,无论是在供应商或者客户手里测试,只能通过CB刷新App。如果需要CB自刷新,就需要额外的方法。
1、规范:
整车厂只有对App程序刷新的规范,没有对Boot自刷新的规范。因为规范是针对量产车的,售后只负责App程序的升级,不对Boot升级(也不允许Boot升级)。
所以,Boot的自刷新只存在于项目开发阶段,且由供应商自行提供方案。本文分析五种Boot自更新方式的优缺点。




方式一,SB更新CB:
如图1-a,有的软件架构是两级Boot:SB+CB,Start Boot只检查CPU最小系统,与具体项目的**电路无关,它独立于客户需求,由供应商自行维护,在Pilot项目早期就应开发完成。因为程序启动顺序是SB->CB->App,这样在SB里增加刷新逻辑可以更新CB。通常情况下运行CB更新App程序,特殊情况下程序启动后一直停留在SB里,更新CB。

优点:
1.逻辑结构简单清晰,软件分工明确。
2.一次刷新,操作简易。

缺点:
1.需要较大的Flash空间在SB里存放刷新逻辑,项目SOP后又要禁止这种刷新方式,造成额外的浪费。
2.软件分三级启动,结构复杂,开发和维护成本较高。对于不需要SB的控制器是一种负担。
3.万一SB也需要更新怎么办?按照这种策略,还得做个SSB?显然不现实。




方式二、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烧写程序。




方式三、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更新阶段掉电后控制器瘫痪的风险 。




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




方式五、借助额外Flash空间
相比方式四,需要一块和CB一样大小的额外Flash空间,刷新分三步:
图5-b,运行CB,刷入ReBoot到额外Flash。
图5-c,运行ReBoot,更新CB。
运行新的CB,破坏ReBoot(全部擦除,或只擦除ReBoot有效性标志)

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

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




小结:
本质上只有三种:
依赖启动程序SB(方式一),当CPU的Flash资源很富余且项目需要两级Boot时,用该方法最节省时间。
借助RAM(方式二、三)
借助Flash(方式四、五)。只需要单级Boot(CB)时,可以容忍因Boot刷新瘫痪必须要给控制器开盖带来时间,人力,物力的成本损耗的情况下用方式二,三较方便。

只需要单级Boot(CB)时,不允许或不方便控制器开盖,但可以容忍Boot更新步骤繁多时间较长的情况下用方式四、五最可靠。
综上,工程师需要根据整体软件架构,CPU资源,时间人力物料等成本因素综合考虑一种适合自己产品及项目的Boot自刷新方法。




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

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

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




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








方式四控制器刷死情况分析:
如图 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所示。




对策二、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最终定型后,应该把这个跳转逻辑关闭。




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



页: [1]
查看完整版本: 五种单片机固件自更新的方法/Boot