01
BootLoader概述
1.1 Boot Loader设计目的
车载控制器软件需要满足两方面的要求:
1)、功能方面的需求:用户需要的基本功能实现;
2)、更新及升级需求:对于售后的要求,车辆上市后针对软件缺陷修复及后续功能扩展等要求。
刷写App程序存在两种方式:
2)、将Application数据通过总线(CAN、LIN、CANFD或以太网)按照一定格式传输给ECU。
对于实车,直接连接烧录器或仿真器这种方式极不方便且花费较大,再者安全性不高。因此,产品很少存在烧录接口。从经济使用的角度来讲,普遍采用第二种方式。
1.2 Boot Loader基本功能
Boot Loader又称为引导加载程序,引导加载程序是系统上电后运行的第一段软件代码,常被用来加载系统或者更新系统等。因此,大部分的Boot Loader存在两种不同的操作模式:
1)启动模式
启动加载(BootLoading)模式也称为自主模(Autonmous)式,即BootLoader从目标机上某个固态存储设备上将操作系统加载至RAM中运行,整个过程中并没有用户的介入。
2)下载模式
在下载(DownLoading)模式下,目标机上的Boot Loader将通过串口连接或者网络连接等通信手段下载文件,如下载内核映像和根文件系统映像等。通常文件会保存在RAM中,然后将其写入目标地址完后系统的更新等。
02
BootLoader基本需求设计
2.1 Boot Loader功能概述
两个SWC:
1)、启动管理——控制器的启动管理等
2)、应用程序——ECU软件下载升级及标定数据再编程等
四个服务模块:
1)、内存管理——软件更新主要是将Flash中的Application及标定数据重编程,内存擦除与重写驱动必不可少的模块;
2)、CAN协议栈——软件更新媒介
3)、看门狗模块——软件运行保护
4)、安全模块——软件数据保护,下载数据校验等
2.2 ECU启动时序
Bootloader是所有支持重编程的ECU必须具备的软件功能,在ECU运行过程中,执行的是应用软件和应用数据,仅当应用软件或应用数据无效时,或者要求对其进行升级或特殊测试时,Bootloader软件才被激活。启动过程如下图所示:
2.3 软件执行安全机制设计
2.3.1 应用软件运行安全性
应用软件和应用数据可以同时编程或者相互独立编程,不允许Boot Loader在软件运行时被非法修改。因此,Bootloader软件存储于被保护的存储器区域,即使发生潜在错误时,控制器始终保证可重新编程。
基于软件运行安全性考虑,flash diver不会存在放在flash中,避免正常程序在发生错误时可能的非法修改。在需要执行应用程序或应用数据需要时,首先将flash diver下载至ram中,然后执行相应的更新。
基于以上考虑,将Boot Loader划分为:
PBL(Primary Boot Loader):用于启动过程中的状态管理及下载软件等,下载 SBL、更新应用软件及应用数据
SBL(Secondary Boot Loader):本质为Flash Diver(可被用来修改写在flash中生产信息校验信息等),下载完成后重新启动将会被清除
##SBL也可是运行在RAM中的另一个完整Boot Loader,以上将其认为flash driver
2.3.2 软件更新安全机制设计
为确保下载的安全,ECU需设计安全机制,避免以下几种情况:a. 来自非法源的下载动作;b. 当前编程条件不满足;c. 下载错误的应用软件或应用数据到ECU;d. 软件之间不兼容;
解决措施:
1)、安全访问——ECU通过SEED&KEY机制进行安全访问服务限制,保证ECU免遭未授权的编程动作影响。
2)、预编程条件——ECU确保编程时处于安全状态,条件不满足(如高压上电或车辆运行)时,编程服务请求将被拒绝。
3)、完整性校验——ECU对即将下载到存储器的程序或数据进行完整性检查,当一个逻辑模块下载后,使用CRC32算法验证当前逻辑块的所有数据字节是否被正确传输和写入。通过“检查编程完整性”例程控制激活ECU完整性校验。当ECU接收到此服务请求时,Bootloader将计算下载数据字节的CRC32值,并将计算结果与诊断仪请求报文中发送的校验值进行比较。
4)、一致性检查——不兼容的软件不能配合使用,如果配合使用可能会使功能异常或产生致命性错误。为此,ECU通过验证软件兼容性来检查编程程序的一致性,包括应用软件与Bootloader软件、应用数据与应用软件检验等。
5)、有效性检查——ECU内部有一个标志位,用于标识应用软件是否有效。如果编程完整性检查和一致性检查都正确时,ECU才会设置应用软件的标志位为有效。只有标志位为有效时,应用软件才可以运行。
03
BootLoader重编程流程设计
3.1 BootLoader重编程会话跳转设计
在应用模式下,使用了两种不同的诊断会话模式:默认会话模式和扩展会话模式。
在Bootloader模式下,使用了三种不同的诊断会话模式:默认会话模式,扩展会话模式和编程会话模式。
如果ECU在正确的条件下收到“$10 $02”指令,ECU将重编程请求标志状态位设为有效,并执行ECU重启。
上电/复位后,ECU首先执行Bootloader引导代码,然后检查外部编程请求标志位:
1)、如果外部编程请求标志位为有效,那么即使应用程序是有效的,Bootloader也会继续进一步执行,在此情况下,ECU直接进入编程会话模式。
2)、如果外部重编程请求标志位为无效,则继续检查应用软件的标志位状态:(a)、 如果应用软件是有效的,则启动应用模式;(b)、如果应用软件无效,ECU停留在Bootloader模式下的默认会话模式。
在Bootloader模式下,ECU重启方式:
1)、无论当前处于何种会话模式,“$11 $01”都会引导ECU重启;
2)、 在扩展会话模式或编程会话模式下,S3定时器超时会导致ECU重启;
3)、在编程会话模式下,“$10 $01”会导致ECU重启。
3.2 BootLoader重编程时序设计
编程时序分为三个编程步骤:
预编程步骤:编程前的CAN网络准备;
主编程步骤:下载应用软件或应用数据;
后编程步骤:重同步CAN网络。
如果在预编程、主编程和后编程步骤过程中,任何物理寻址的请求及响应不满足要求,则全部时序需再次执行。
3.2.1 预编程步骤
预编程步骤用来为要下载的ECU做重编程前的CAN网络准备。此步骤也包含了提高下载速度的准备。此步骤的请求报文能采用的是物理寻址,或功能寻址。如下图所示:
a)、诊断会话控制 $10 $03:为了禁止ECU间的正常通信和控制DTC设置,预编程需要启动非默认会话模式。通过使用会话类型为扩展会话模式的诊断会话控制($10)服务来完成。此请求使用一个单帧请求报文,通过功能寻址发送给所有的ECU。
b)、例程控制“检查编程预条件” $31 $01 $XXXX:通过此例程来检查ECU编程条件,从而确保系统安全,如果有任何不安全的因素,ECU将拒绝编程。
注意:如果ECU在未收到“检查编程预条件”例程($31 $01 $XXXX)的情况下,收到“$10 $02”请求,ECU将拒绝进入Bootloader模式,并且发送否定响应。
c)、控制DTC设置 $85 $02:诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求。此请求使用一个单帧请求报文,通过功能寻址发送给所有的ECU。
d)、通信控制 $28 $03 $03:诊断仪通过通信控制($28)服务请求,禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmission and the reception”,通信类型置为“application and network management messages”。此请求使用一个单帧请求报文,通过功能寻址发送给所有的ECU。
3.2.2 主编程步骤
在预编程步骤之后,是主编程步骤。主编程时序是单个ECU编程事件的应用,因此所有服务的请求都使用物理寻址。
a)、诊断会话控制 $10 $02:在收到一个寻址方式为物理寻址,子功能为编程会话的诊断会话控制($10)服务后,ECU启动Bootloader,并分配编程所需的所有资源。ECU需先发送肯定响应,再执行跳转到编程模式动作。
b)、安全访问 $27 $XX/XX:编程事件必须通过安全访问。安全访问($27)服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前,通过安全访问过程是强制的,确保只有合法的诊断仪能对ECU进行下载操作。
c)、驱动下载 $34,$36,$37,$31:当ECU的非易失性存储单元中没有存储内存驱动时,将执行内存驱动的下载。下载应该按照如下时序来进行:请求下载、传输数据、请求传输退出。下载完所有字节后,用“检查编程完整性”例程($31 $01 $XX $XX)来检查所有的字节都正确传输。
d)、写入数据 $2E $XXXX:在擦除内存例程之前,将“指纹”写到ECU内存中是强制的。“指纹”标识了是哪个诊断仪对ECU内存做了修改。使用XXXX数据标识符而不是引导软件指纹、应用软件指纹、应用数据指纹这些数据标识符。每个逻辑块(除了驱动)下载前,诊断仪将首先写“指纹”,在下载完逻辑块后,ECU将识别之前下载的程序是哪个逻辑块(即逻辑块序号),并根据逻辑块的序号将它存储。在追踪指纹信息时,诊断仪将发报文“$22 $XXXX”,ECU将通过“$62 $XXXX”,返回每一个逻辑块的指纹信息。
e)、例程控制——“擦除内存” $31 $01 $XXXX:为了允许应用软件和数据下载,ECU的内存将被擦除。此步骤通过例程控制服务($31)来执行擦除内存。如果擦除内存例程被调用执行,那么应用软件的标志位将被置为无效。
f)、下载过程 $34 $36 $37:应用软件或者数据的每一个连续的数据块(也叫段,可能是一个完整的应用软件或者数据,也可能是应用软件或者数据的一部分)下载到ECU非易失性内存中,都是遵循下面的服务顺序完成数传输:请求下载($34)、传输数据($36)、请求退出传输($37)。
注:单个应用软件或数据块可能需要多个数据传输($36)请求报文来完成传输(当数据块长度超出网络层缓存大小时,就会出现这种情况)。
g)、例程控制——“检查编程完整性” $31 $01 $XXXX:此例程用来检查逻辑块的完整性。
h)、例程控制——“检查编程一致性” $31 $01 $XXXX:一旦完成所有的应用软件或数据块/模块的下载,诊断仪将开始一个例程来触发ECU检查重编程的一致性。
i) 、电控单元复位 $11 $01:诊断仪使用物理寻址,发送一个复位类型为硬复位的ECU复位($11)服务请求报文到CAN网络上。
备注:通过ECU复位服务请求将使ECU结束重编程过程,返回到正常的操作模式。内存驱动代码必须从RAM缓存中完全清除,避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。
3.2.3 后编程步骤
a)、诊断会话控制 $10 $01:诊断仪发送一个会话类型为默认会话的诊断会话控制($10)服务请求报文到CAN网络上。所有的ECU接收到诊断会话控制($10),而进入到默认会话模式。此请求通过功能寻址发送,请求发送给所有包含在编程事件中或因此而进入非默认会话模式的ECU。跳转到默认会话模式,表示通信控制($28)服务和控制DTC设置($85)服务也将复位到默认状态。
b)、清除诊断信息 $14 FF FF FF:如果重编程ECU在编程步骤被重启,当编程ECU运行在默认会话模式时,网络上其它的ECU仍然在不能正常通信状态,此时,一些可能被存储在编程ECU中的诊断信息就应该通过物理寻址的清除诊断信息($14)服务来清除。
版权声明:本文为CSDN博主「摸鱼的攻城狮」的原创文章,转载请附上原文出处链接及本声明。
编辑:jq
-
编程
+关注
关注
88文章
3614浏览量
93693 -
ecu
+关注
关注
14文章
886浏览量
54485 -
CAN网络
+关注
关注
1文章
44浏览量
16927
原文标题:技术|基于UDS的BootLoader设计——架构设计及规范
文章出处:【微信号:e700_org,微信公众号:汽车工程师】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论