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