Bootloader刷写流程、刷写测试、自更新方案梳理

Bootloader(以下简称Boot)是所有支持重编程的ECU必须具备的软件功能，正常情况下，ECU中运行的是应用软件。只有在收到10 02诊断指令或者在Boot跳转到App失效，ECU会运行在Boot中。

之前Boot是无法再次更新的，也就是说出厂后，Boot的软件版本就是固定的，除非是拆件。

不过现在越来越多的主机厂要求Boot也要支持刷写，即使发生潜在错误时，Boot也可以更新修复。另外现在越来越多的ECU实施AB区的刷写方案。

下面主要从Boot启动流程、ECU刷写流程、升级测试、Boot自更新方案三方面来梳理。

01. Boot的启动流程

ECU上电后，首先执行Boot。Boot首先完成一些基本的初始化，例如CAN驱动，IO模块，初始化完成后，开始检查刷新请求标志位是否为有效，如果刷新请求标志位有效，则等待刷写指令。如果刷新请求标志位无效，则检查应用软件的状态，如果应用软件是有效的，则应用软件代码将被执行，如果应用软件是无效的，则继续执行Bootloader代码。

当ECU运行在应用软件，当收到进入编程会话指令，ECU将外部刷新请求标志位设置为有效，并执行ECU重启，如下图所示。重启后则按照之前上述的流程检查。

02. 刷写流程

刷新时序分为三个编程步骤：

预刷新步骤：刷新前的CAN网络准备；
主刷新步骤：下载应用软件或应用数据；
后刷新步骤：重同步CAN网络。

1. 预刷新步骤

预刷新步骤如下所示。

1、唤醒ECU，唤醒的方法和策略由汽车制造商制定；

2、为了关闭DTC存储和运行0x28服务关闭相关的通信，需运行0x10服务跳转至扩展会话，

3、进入扩展会话后，汽车制造商可以进一步进行特定数据链路的初始化；

4、运行0x31服务对刷写条件进行检查，例如低压电是否在正常范围内等。除了条件检查之外，还会有一些安全机制，保证刷写安全，避免以下几种情况：

a. 来自非法源的下载动作；

b. 当前刷新条件不满足；

c.下载错误的应用软件或应用数据到ECU；

d.软件之间不兼容；

措施主要包括以下几种：

安全访问：ECU通过诊断0x27服务，SEED&KEY机制进行安全访问服务限制，保证ECU免遭未授权的编程动作影响。

刷新预条件：ECU确保刷新时处于安全状态，条件不满足（如高压上电、低压异常或车速不为零）时，刷新服务请求将被拒绝。

完整性校验：ECU对即将下载到flash的程序或数据进行完整性检查，当一个逻辑模块下载后，使用CRC32算法验证当前逻辑块的所有数据字节是否被正确传输和写入。

通过“检查编程完整性”例程控制激活ECU完整性校验。当ECU接收到此服务请求时，Bootloader将计算下载数据字节的CRC32值，并将计算结果与诊断仪请求报文中发送的校验值进行比较。

一致性检查：不兼容的软件不能配合使用，如果配合使用可能会使功能异常或产生致命性错误。为此，ECU通过验证软件兼容性来检查刷新程序的一致性，包括应用软件与Bootloader软件、应用数据与应用软件检验等。

5、为了防止刷写过程中出现异常误触发DTC存储，运行0x85服务关闭DTC的存储；

6、该步骤提供给汽车制造商一个接口，可以通过0x31服务启动或关闭ECU的故障安全响应(failsafe reaction);

7、为了提高刷写速度，降低刷写程序时总线负载率，通过运行0x28服务关闭无关报文，比如应用报文和网络管理报文；

8、在关闭部分通信之后，通过0x22服务读取被刷ECU的状态(应用软件和数据)、软件指纹信息等；

9、为了减少刷写的时间，可以通过0x87服务提高CAN总线的波特率。

2. 主刷新步骤

在预刷新步骤之后，是主刷新步骤。主刷新时序是单个ECU刷新事件的应用，因此所有服务的请求都使用物理寻址。

其中：

1、运行0x10服务进入programmingSession；

2、运行0x27服务进入特定的安全等级；

3、运行0x2E服务将指纹信息写入ECU；

4、运行0x34、0x36、0x37服务将永久存储区写入默认值；

5、运行0x31服务检查步骤4是否成功，另外一种方法是通过0x37的响应确定是否成功；

6、运行0x31服务对特定的Flash进行擦除；

7、分别运行0x34、0x36、0x37服务将Flash driver下载至内存中；

8、运行0x31服务检查Flash driver下载是否成功；

9、分别运行0x34、0x36、0x37服务将软件和数据下载至ECU的flash中；

10、运行0x31服务检查步骤9是否下载成功；

11、运行0x31服务验证程序是否能正常运行，例如checksum、标志位等；

12、在下载完软件和数据后，汽车制造产商需要一些特定的操作，比如写入VIN码等。

3. 后刷新步骤

该步骤主要通过0x11服务对ECU进行复位或者通过0x10服务切换至默认会话，如图3所示，如果在预编程中中调整了波特率，须通过特定的操作将波特率调整至正常值。通常操作是运行0x11服务使ECU复位，回到正常状态。

03. 刷写测试用例

刷写功能开发完之后，通常都是要按照测试用例进行测试的，那一般都要做哪些测试呢，才能证明刷写功能是OK的呢？主要分为4部分测试。

首先是模拟诊断仪正常刷写，测试用例主要包括下图所示，图中测试用例还考虑了标定数据的刷写。

然后是错误注入测试，其前提是错误刷写不损坏系统Boot，当重新上电后，DUT可以正常更新应用程序。用例如下所示。

再之后是刷写完整性测试，测试用例如下所示。

最后就是刷写流程以及预条件测试，主要测试3E服务，前置条件，刷写失败等，测试用例如下图所示。

04. Boot自更新

Boot自更新的需求现在也是越来越多，主要为了修复Boot软件中存在的Bug。以下有几种Boot自更新的方案。

1. Supplier Boot(SB) + Customer Boot(CB)

通常情况下，供应商都有自己的平台软件，包括Boot和Appl。而各主机厂都有自己不同的软件升级规范，为了适配主机厂的需求，通常的做法是加一层Customer Boot来实现客户的需求。那软件的运行顺序就是SB->CB->Appl，如图1所示。这种做法可以简单、快速的满足CB也可以更新。

不过这种方式，通常情况下通过SB更新CB是通过供应商自己定义的升级流程，并且通过自己的上位机来实现升级。也就意味着这种方式只适应项目开发阶段，因为供应商的升级流程无法接入到整车的OTA流程。

这种方式的优点就是简单，能很快地适配客户的需求，而且即使面向不同的客户，只需要简单的更改CB就可以满足需求，适应性比较好。但是缺点就是会浪费Flash空间。

2. 将Boot先放到RAM中运行，然后更新Boot的Flash区域

这种方式只需要一份Boot，其具体方案是，在Boot的链接文件中，将程序和数据映射到特性的RAM空间，然后在控制器上电时，首先将Boot的代码和数据搬运到RAM中，程序运行在RAM中，当收到更新Boot的需求时(这里需要上位机在发送更新指令的时候，区别是更新Boot还是App，比如通过在0x31服务写入不同的标志位进行区分)，通过RAM中的程序以及上位机下载的Flash Driver，将Boot的Flash区域进行更新。

这种方式的优点就是节省Flash空间，而且如果客户想把Boot自更新的功能保留到量产之后，也是可以的，因此控制器的升级是完全遵循主机厂的要求的。

不过这种方式有个缺点，就是在更新过程中，不能断电，一旦断电，控制器就会变成板砖，需要换件。另外程序运行在RAM中，对踩内存这种行为更加敏感。

不过在整车上，出现意外断电的情况应该很少。首先升级之前会检查低压蓄电池的电压水平，甚至对新能源车来说，可以启动DCDC，来保证12V的稳定供应。

3. 两个CB+minBoot

这种方案下，有两个CB和一个miniBoot，miniBoot的作用很简单，就是根据引导区的标志位来决定切换到哪个Boot。

其具体的运行方式是，当软件收到Boot更新指令时，软件复位，首先跳转到miniBoot，在miniBoot中，根据引导区标记（标记所需运行的Boot号，比如1代表Boot1,2代表Boot2）跳转到相应的Boot，假设当前运行是Boot1，在Boot1中根据刷新指令，将Boot2的Flash区域进行更新，更新完之后，将引导区标记写为2，然后软件复位，那么下次运行的时候就会切换到Boot2运行了。