Bootloader(以下简称Boot)是所有支持重编程的ECU必须具备的软件功能，正常情况下，ECU中运行的是应用软件。只有在收到10 02诊断指令或者在Boot跳转到App失效，ECU会运行在Boot中。
之前Boot是无法再次更新的，也就是说出厂后，Boot的软件版本就是固定的，除非是拆件。不过现在越来越多的主机厂要求Boot也要支持刷写，即使发生潜在错误时，Boot也可以更新修复。另外现在越来越多的ECU实施AB区的刷写方案。下面主要从Boot启动流程、ECU刷写流程、升级测试、Boot自更新方案三方面来梳理。
01.
ECU上电后，首先执行Boot。Boot首先完成一些基本的初始化，例如CAN驱动，IO模块，初始化完成后，开始检查刷新请求标志位是否为有效，如果刷新请求标志位有效，则等待刷写指令。如果刷新请求标志位无效，则检查应用软件的状态，如果应用软件是有效的，则应用软件代码将被执行，如果应用软件是无效的，则继续执行Bootloader代码。当ECU运行在应用软件，当收到进入编程会话指令，ECU将外部刷新请求标志位设置为有效，并执行ECU重启，如下图所示。重启后则按照之前上述的流程检查。▲图 Bootloader启动时序[来源网络，侵删]
02.
1、唤醒ECU，唤醒的方法和策略由汽车制造商制定；
2、为了关闭DTC存储和运行0x28服务关闭相关的通信，需运行0x10服务跳转至扩展会话，
3、进入扩展会话后，汽车制造商可以进一步进行特定数据链路的初始化；
4、运行0x31服务对刷写条件进行检查，例如低压电是否在正常范围内等。除了条件检查之外，还会有一些安全机制，保证刷写安全，避免以下几种情况：
安全访问：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总线的波特率。
在预刷新步骤之后，是主刷新步骤。主刷新时序是单个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码等。
该步骤主要通过0x11服务对ECU进行复位或者通过0x10服务切换至默认会话，如图3所示，如果在预编程中中调整了波特率，须通过特定的操作将波特率调整至正常值。通常操作是运行0x11服务使ECU复位，回到正常状态。
03.
刷写功能开发完之后，通常都是要按照测试用例进行测试的，那一般都要做哪些测试呢，才能证明刷写功能是OK的呢？主要分为4部分测试。首先是模拟诊断仪正常刷写，测试用例主要包括下图所示，图中测试用例还考虑了标定数据的刷写。
然后是错误注入测试，其前提是错误刷写不损坏系统Boot，当重新上电后，DUT可以正常更新应用程序。用例如下所示。
最后就是刷写流程以及预条件测试，主要测试3E服务，前置条件，刷写失败等，测试用例如下图所示。
04.
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的稳定供应。这种方案下，有两个CB和一个miniBoot，miniBoot的作用很简单，就是根据引导区的标志位来决定切换到哪个Boot。
其具体的运行方式是，当软件收到Boot更新指令时，软件复位，首先跳转到miniBoot，在miniBoot中，根据引导区标记（标记所需运行的Boot号，比如1代表Boot1,2代表Boot2）跳转到相应的Boot，假设当前运行是Boot1，在Boot1中根据刷新指令，将Boot2的Flash区域进行更新，更新完之后，将引导区标记写为2，然后软件复位，那么下次运行的时候就会切换到Boot2运行了。
▲图 2个CB+miniBoot方案
这种方案的优势就是可以保证刷新过程中断电不会导致控制器变成板砖，而且也可以在SOP之后继续使用。缺点也很明显，空间占用率比较大，软件复杂，需要三个Boot。
-end-
