原文来源于:https://blog.csdn.net/weixin_40137252/article/details/111054011
汽车软件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空间，刷新分三步：
1. 图5-b,运行CB，刷入ReBoot到额外Flash。
2. 图5-c,运行ReBoot，更新CB。
3. 运行新的CB，破坏ReBoot（全部擦除，或只擦除ReBoot有效性标志）
优点：相比方式四，不需要破坏App程序，也省去了这部分更新时间。
缺点：相比方式四，需要额外的Flash空间，且必须是独立的Block。
小结：
本质上只有三种：
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。
考虑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的要求。
