鉴于篇幅原因，上篇没有多描述ECU刷写过程中所执行的那些动作。这里通过实例以及UDS建议刷写序列内容，一起解读刷写过程中的内容。
如下图，ISO 14229对于刷写过程所需Action所给出的推荐步骤。
1、 若ECU当前处于Application中，想要完成对ECU的刷写，需进入到对应的Boot模式下。在诊断范畴，通过会话模式（10 02 Programming Session）切换进入Boot模式。在Bootloader代码作用下完成对ECU的刷写动作；
2、 出于对ECU的保护，需要安全认证后才有刷写ECU的权力。在UDS协议中推荐使用Service 27（Security Access Service），解锁成功后允许对ECU进行下一步的刷写行为；
3、 Fingerprint在UDS中的定义是：车辆制造商特定于在任何数据（例如应用程序软件）下载到ECU之前，将“指纹”写入服务器内存中。“指纹”标识谁修改了服务器内存。如下图定义DID 0xF198为Fingerprint，里面包含3个信息：
1) Serial number of flash tool：刷写上位机工具序列号；
2) Repair Shop Identification： 维修店识别号；
3) Programming Date：更新软件的时间（年月日）
通过2E服务将Fingerprint写入到ECU内存中。
4、 在ECU软件刷写时，若内存中没有存储擦除驱动，需要下载擦除驱动。通过特定的下载序列进行下载：
RequestDownload (…)：请求下载，UDS协议中定义格式如下：
Service 34请求以及响应格式如上所表述。下图以实际例子来说明Service 34的帧格式：
根据上面介绍：
0x00可知该块数据没有采用加密和压缩方法；
0x44表示数据存放的地址和数据长度都是用4Bytes表示；
0x00000030数据存放的起始地址；
0x0484该块数据的大小；
TransferData：UDS协议中定义该服务请求和响应格式如下：
RequestTransferExit：请求退出传输
5、 Routine Control用于检查下载是否完整，关于Routine Control，UDS协议中格式定义如下：
其中对应SubFunction定义如下：
其中通过Routine DID定义一系列检测动作（也可称例程）验证数据下载结果。而对于SubFunction（01/02/03）分别表示对于检测例程的开始执行、停止执行和请求执行结果。
例如定义DID 1314 Check Programming Integrity ：通过数学方法计算data内容中CRC值，校验刷写前后数据是否一致；
DID 5201 Check Programming Dependencies：校验刷写后的数据，查看版本号是否一致？内容是都一致？
步骤6、7、8跟上述动作一致，个人认为这里UDS协议将Driver区分开（一个负责擦除内存，一个负责在内存上写入数据）。
9、对ECU所需更新的App data进行下载（例如：校验和、签名、DTC、硬件/软件兼容性等）；
步骤10、11是验证下载结果。
12、写入ECU培训信息，比如VIN码、软硬件版本号等
以上是个人对于ECU刷写整体流程的认识。
由于现阶段车企对OTA越发重视，所以要求Bootloader功能具有很高的稳健性，能够保证在不同极端条件下都可以对ECU进行刷写。因此Bootloader刷写测试的重要性越来越凸显。如下举常见几种测试策略，方便大家理解：
1) 在刷写过程中突然中断刷写，后再继续刷写，检测ECU Bootloader处理策略；
2) 在刷写过程中突然掉电，后上电继续刷写，检擦ECU Bootloader处理策略；
3) 在一定电压阈值内进行刷写，检测ECU处理策略；
4) 刷写过程中，只对ECU内存进行擦除，不写入ECU App数据内存，看看ECU Bootloader处理策略；
……
内容纯属个人见解，欢迎留言交流，我会及时回复！
感兴趣可关注微信公众号：汽车控制器诊断技术
-----------------------------------------
作者简介 | 穿拖鞋的汉子
汽车电子工程师
来，每天进步一点点！
扩宽自己人生的护城河！
转播
