基于UDS的Bootloder详解

Bootloader是所有支持重编程的ECU必须具备的软件功能,在ECU运行过程中,执行的是应用软件和应用数据,仅当应用软件或应用数据无效或者上电之初,或者要求对其进行升级或特殊测试的时侯,才会运行Bootloader软件。

Bootloader是所有支持重编程的ECU必须具备的软件功能,在ECU运行过程中,执行的是应用软件和应用数据,仅当应用软件或应用数据无效或者上电之初,或者要求对其进行升级或特殊测试的时侯,才会运行Bootloader软件。

应用软件和应用数据可以同时编程或者相互独立编程,通常在ECU在刷入bootloader后,bootloader是无法再次更新的,除非拆件,不过现在这越来越多的主机厂要求Bootloader也要支持刷写。Bootloader存储于被保护的flash区域,即使发生潜在错误时,控制器的应用软件始终可以刷新。

01 Bootloader安全机制

为确保刷写的安全,ECU需设计安全机制,避免以下几种情况:

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

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

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

d.软件之间不兼容;

1、安全访问

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

2、 刷新预条件

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

3、完整性校验

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

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

4、一致性检查

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

5、有效性检查

ECU内部有一个标志位,用于标识应用软件是否有效。如果刷新完整性检查和一致性检查都正确时,ECU才会设置应用软件的标志位为有效。只有标志位为有效时,应用软件才可以运行。

6、刷新文件格式

刷新文件格式为Intel格式bin、s19、hex。

02 ECU启动时序

在每次上电/复位后,ECU首先执行Bootloader代码。Bootloader首先执行一些基本的初始化,然后检查刷新请求标志位是否为有效,如果刷新请求标志位有效,即使应用程序是有效的,Bootloader也会继续运行。如果当前没有刷新请求,即刷新请求标志位为无效,则检查应用软件的状态,如果应用软件是有效的,则应用软件代码将被执行,如果应用软件是无效的,则继续执行Bootloader代码,如图1所示。

基于UDS的Bootloder详解-第1张图片

图1 ECU启动时序

03 Bootloader启动时序

图2描述了Bootloader启动时序。在应用模式下,使用了两种不同的诊断会话模式:默认会话和扩展会话。

在Bootloader模式下,使用了三种不同的诊断会话模式:默认会话,扩展会话和刷新会话。

如果ECU在正确的条件下收到“10 02”指令,ECU将外部刷新请求标志位设置为有效,并执行ECU重启。

基于UDS的Bootloder详解-第2张图片

图2 Bootloader启动时序

上电/复位后,ECU首先执行Bootloader引导代码,然后检查外部刷新请求标志位:

  • 如果外部刷新请求标志位为有效,那么即使应用程序是有效的,Bootloader也会继续进一步执行,在此情况下,ECU直接进入编程会话。
  • 如果外部重编程请求标志位为无效,则继续检查应用软件的标志位状态:
  • 如果应用软件是有效的,则启动应用模式;
  • 如果应用软件无效,ECU停留在Bootloader模式下的默认会话模式。

在Bootloader模式下,有以下几种方式,会导致ECU重启:

  • Ø 无论当前处于何种会话模式,“11h 01h”都会引导ECU重启;
  • Ø 在扩展会话模式或编程会话模式下,S3定时器超时会导致ECU重启;
  • Ø 在编程会话模式下,“10h 01h”会导致ECU重启。

03 刷新时序

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

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

如果在预刷新、主刷新和后刷新步骤过程中,出现刷写中断,则全部时序需被再次执行。

1、预刷新步骤

预刷新步骤用来为要下载的ECU做重刷新前的CAN网络准备。此步骤也包含了提高下载速度的准备。此步骤的请求报文能采用的是物理寻址,或功能寻址。预刷新步骤,如图3所示。

基于UDS的Bootloder详解-第3张图片

图3 预刷新步骤

a)  诊断会话控制10h 03h:为了禁止ECU间的正常通信和禁止DTC设置,预刷新需要切换到扩展会话,通过功能寻址发送给所有的ECU。

b)  例程控制“检查刷新预条件”31h 01h xxh xxh:通过此例程来检查ECU刷新条件,从而确保系统安全,如果有任何不安全的因素,ECU将拒绝刷新。

注意:如果ECU在未收到“检查刷新预条件”例程(31 01 xx)的情况下,收到“10h 02h”请求,ECU将拒绝进入Bootloader,并且发送否定响应。

c)  控制DTC设置85h 02h:诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求。此请求使用一个单帧请求报文,通过功能寻址发送给所有的ECU。

d)  通信控制28h 03h 03h:诊断仪通过通信控制(28h)服务请求,禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmissionand the reception”,通信类型置为“application and network management messages”。此请求使用一个单帧请求报文,通过功能寻址发送给所有的ECU。

e)  读取数据22h xxh yyh:在禁止正常通信后,读取被刷新的ECU的状态(如:刷新的应用软件和数据)。从被刷新的ECU读取服务器标识数据,如应用软件标识、应用数据标识、Bootloader软件标识。

2、主刷新步骤

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

图4描述了在主刷新步骤中执行的各个服务。

基于UDS的Bootloder详解-第4张图片

图4 主刷新步骤

a)  诊断会话控制10h 02h:通过物理寻址发送10h 02h,然后写入刷写标志位,最后ECU重启进入Bootloader,在BootLoader中需先发送肯定响应再执行跳转到刷新模式动作。

b)  安全访问27h 03h/04h:刷写必须通过安全访问。安全访问(27h)服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前,通过安全访问过程是强制的,确保只有合法的诊断仪或上位机能对ECU进行下载操作。

为了缩短重刷新时间,上电可直接执行安全访问服务。

c)  驱动下载34h,36h,37h,31h:通常ECU的flash中不会存储flash读写驱动时,因此首先将执行flashdriver的下载。下载应该按照如下时序来进行:请求下载、传输数据、请求传输退出。下载完所有字节后,用“检查刷新完整性”例程(31h 01h F0h 01h)来检查所有的字节都正确传输。

d)  写入数据2Eh F1h 5Ah:在擦除内存例程之前,将“指纹”写到ECU内存中是强制的。“指纹”标识了是哪个诊断仪对ECU内存做了修改。使用F1h5Ah数据标识符而不是引导软件指纹、应用软件指纹、应用数据指纹这些数据标识符。每个逻辑块(除了驱动)下载前,诊断仪将首先写“指纹”,在下载完逻辑块后,ECU将识别之前下载的程序是哪个逻辑块(即逻辑块序号),并根据逻辑块的序号将它存储。在追踪指纹信息时,诊断仪将发报文“22hF1h 5Bh”,ECU将通过“62h F1h 5Bh…”,返回每一个逻辑块的指纹信息。

e)  例程控制——“擦除内存”31h 01h FFh 00h:为了允许应用软件和数据下载,ECU的内存将被擦除。此步骤通过例程控制服务(31h)来执行擦除内存。如果擦除内存例程被调用执行,那么应用软件的标志位将被置为无效。

f)  下载过程34h,36h,37h:应用软件或者数据的每一个连续的数据块下载到ECU非易失性内存中,都是遵循下面的服务顺序完成数传输:

  1. Ø 请求下载(34h);
  2. Ø 传输数据(36h);
  3. Ø  请求退出传输(37h)。

单个应用软件或数据块可能需要多个数据传输(36h)请求报文来完成传输(当数据块长度超出网络层缓存大小时,就会出现这种情况)。

g)  例程控制——“检查刷新完整性”31h 01h F0h 01h:此例程用来检查逻辑块的完整性。

h)  例程控制——“检查刷新一致性”31h 01h FFh 01h:一旦完成所有的应用软件或数据块/模块的下载,诊断仪将开始一个例程来触发ECU检查重刷新的一致性。

i)  电控单元复位11h 01h:诊断仪使用物理寻址,发送一个复位类型为硬复位的ECU复位(11h)服务请求报文到CAN网络上。
通过ECU复位服务请求将使ECU结束重刷新过程,返回到正常的操作模式。内存驱动代码必须从RAM缓存中完全清除,避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

3、后刷新步骤

基于UDS的Bootloder详解-第5张图片

图5 后刷新步骤

a)  诊断会话控制10h 01h:诊断仪或上位机发送默认会话的诊断会话控制(10h)服务请求报文到CAN网络上。所有的ECU接收到诊断会话控制(10h),而进入到默认会话模式。此请求通过功能寻址发送,请求发送给所有包含在编程事件中或因此而进入非默认会话模式的ECU。跳转到默认会话模式,表示通信控制(28h)服务和控制DTC设置(85h)服务也将复位到默认状态。

b)  清除诊断信息14h FFh FFh FFh:如果重编程ECU在编程步骤被重启,当编程ECU运行在默认会话模式时,网络上其它的ECU仍然在不能正常通信状态,此时,一些可能被存储在编程ECU中的诊断信息就应该通过物理寻址的清除诊断信息(14h)服务来清除。

免责声明:本文来自汽车ECU开发,著作权归作者所有,如有侵权请联系本平台处理。商业转载请联系作者获得授权,非商业转载请注明出处。内容投诉
零帕网 » 基于UDS的Bootloder详解
您需要 登录账户 后才能发表评论

发表评论

欢迎 访客 发表评论