OTA-汽车软件Boot程序的几种自刷新方式（学习版）

本文探讨了汽车电子系统中BOOT程序的自刷新方法，包括SB更新CB、RAM+FlashReboot、RAM+RAMReBoot、借助App程序Flash空间和借助额外Flash空间五种方式。讨论了各自的优势和挑战，强调工程师需根据项目需求和资源选择合适的刷新策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

来自微信公众号：车端软件开发，大佬讲的很好，在此整理补充做个笔记

前景说明

汽车软件的BOOT程序，也被称为引导加载程序或启动加载程序，是汽车电子系统启动过程中的关键组成部分。它位于汽车电子系统的最底层，负责在系统启动时加载并初始化硬件设备、运行时环境以及操作系统映像。

具体来说，BOOT程序的主要功能包括：

将操作系统的核心映像加载到内存中，以便车辆电子控制单元（ECU）可以正常运行。
与远程程序下载端建立可靠的总线通信以获取要更新的应用程序。
解析应用程序编程文件（如S19、HEX、BIN等）获得其在非易失性存储器（NVM）中的地址和程序代码及数据。
运行NVM驱动将应用程序的代码和数据编程到NVM中并校验其完整性。

因此，BOOT程序对于汽车软件的正常启动和更新至关重要。

在一个具体客户项目中，Boot也是客户需求的一部分，跟随项目也有软件开发计划（有的为了和其它Boot区分，把项目上的Boot称作CB, Customer Boot）。

对于已经下线盒盖的控制器，无论是在供应商或者客户手里测试，只能通过CB刷新App。如果需要CB自刷新，就需要额外的方法。

规范：

整车厂只有对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。

在项目管理中，Pilot旨在通过实施初始试点项目来评估可行性和效果，然后决定是否继续或扩大项目。项目管理中的Pilot项目包括组建项目组、确定技术目标、制定项目计划、处理范围变化、控制实际进展等内容。

优点：

逻辑结构简单清晰，软件分工明确。
一次刷新，操作简易。

缺点：

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

        Flash空间是指Flash存储器所提供的存储空间。Flash存储器是一种非易失性存储器，具有断电后数据仍然保持的特点。它结合了ROM和RAM的长处，不仅具备电子可擦除可编辑（EEPROM）的性能，同时可以快速读取数据。Flash存储器可以进行擦写操作，允许多次写入数据，因此适合用于存储需要频繁更新的数据，如操作系统、固件和应用程序等。

RAM是一种易失性存储器，断电后数据会丢失，通常用于临时存储正在运行的应用程序和操作系统。
而ROM是一种只读存储器，数据在制造时被写入，无法修改或擦除，通常用于存储不需要修改的数据，如固件、引导程序和预设配置等。

        此外，Flash存储器通常具有较大的存储容量，可以存储大量的数据，因此常用于移动设备、数码相机和存储设备等需要大容量存储的场合。而ROM存储器的容量相对较小，常用于嵌入式系统、控制器和芯片等对存储容量要求不高的场合。

        在读写速度方面，Flash存储器采用了并行读写技术，可以同时读取和写入多个数据块，因此比ROM存储器的读写速度快。

总的来说，Flash空间提供了非易失性、可擦写、大容量且读写速度较快的存储解决方案

方式二、RAM+Flash Reboot更新

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

优点：

不需要额外的Flash空间，Boot程序运行只需要少量的RAM，因此为App设计的RAM临时可以保存Reboot程序。
RAM擦写速度很快，则下载ReBoot的速度会很快。

缺点：

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

JTAG（Joint Test Action Group）是一种国际标准测试协议，主要用于芯片内部测试及对系统进行仿真、调试。JTAG最初用于对芯片进行测试，其基本原理是在器件内部定义一个TAP（Test Access Port，测试访问口），通过专用的JTAG测试工具对内部节点进行测试。JTAG测试允许多个器件通过JTAG接口串联在一起，形成一个JTAG链，能实现对各个器件分别测试。如今，JTAG接口还常用于实现ISP（In-System Programmer，在系统编程），对FLASH等器件进行编程。

方式三、RAM+RAM ReBoot更新（对方式二的改进）

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

优点

相比方式二少了一步刷新（因为ReBoot和CB是绑在一起的）。
相比方式二CB更新全部在CPU内部执行，不受外界干扰，耗时更短。

缺点

相比方式二需要更大的RAM空间存储ReBoot+NewCB。
和方式二一样存在CB更新阶段掉电后控制器瘫痪的风险。（用RAM就会导致断电失效！）

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

刷新分三步：

图4-b运行CB，擦除App，把ReBoot下载到App区域。
图4-c运行ReBoot,擦除旧CB，刷入新CB。
图4-d运行新CB，刷回App。

优点

不需要额外的Flash和RAM资源。
稳定可靠，通过优化设计，可以保证在任何一个步骤突然掉电，上电后可以继续操作，控制器不会刷死。（详细设计方法请看附录）
对CB做稍微改造就可以成为Reboot程序，开发快速。

缺点

步骤繁多，为了更新CB必须要先擦除App，最后恢复App，至少三次刷新
整体刷新时间会较长，两次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（方式二、三），只需要单级Boot（CB）时，可以容忍因Boot刷新瘫痪必须要给控制器开盖带来时间，人力，物力的成本损耗的情况下用方式二，三较方便。
借助Flash（方式四、五）。只需要单级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最终定型后，应该把这个跳转逻辑关闭。