基于CAN总线的车载应用Bootloader设计

（湖北汽车工业学院 汽车动力传动与电子控制湖北省重点实验室，湖北 十堰 442002）

基于CAN总线的车载应用Bootloader设计

张成雨，杨朝阳，单志文

（湖北汽车工业学院 汽车动力传动与电子控制湖北省重点实验室，湖北 十堰 442002）

通过专用调试端口实现对开发后期ECU的应用程序更新，过程繁杂且稳定性不高。针对此问题提出一套基于统一诊断服务（Unified Diagnostic Services，UDS）协议并应用于英飞凌TC27xT平台的下位机Bootloader软件。软件采用车载CAN总线为通信介质，通过UDS下载服务流程，编制了Flash擦写函数，通过CAN通信实现了应用程序的更新和Map的映射，实现对车载ECU的在线更新升级。经过实际测试，最终结果表明：该Bootloader可正常完成程序启动加载，能比较准确、方便地将应用程序下载到控制单元。

CAN总线；UDS；Bootloader

开发后期汽车电子产品ECU利用专用设备来实现程序的更新极不方便，通过汽车车身网络利用Bootloader技术来实现ECU软件代码的更新是一种有效的解决方案［1］。Bootloader启动加载模式能正确引导程序的运行，而通过Bootloader下载模式实现应用数据下载，各类车载Bootloader启动加载是一种普遍模式，需要关注其下载模式的选择和进入。目前，部分车载Bootloader通过采用检测输入引脚电平信号引导进入下载模式，高电平进入用户程序，低电平则进入Bootloader下载模式［2］。文中着重考虑由外部请求触发的Bootloader程序下载模式；无外部请求时，由执行过程中的特殊操作比如硬件某引脚改动触发更新请求，进入Bootloader下载模式；避免程序进入死循环，避免只依靠重新在线编程再进行程序下载的低效。这种形式提高了软件稳定性，使其性能有所提高。

1 Bootloader系统设计

1.1 Bootloader介绍

ECU启动时用于完成初始化操作的代码称为Bootloader程序，整个系统的加载启动任务由Boot⁃loader来完成。通过运行这段程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境设定在一个合适的状态［3］，并决定是升级应用程序还是继续原有程序。现有技术条件下，Bootloader开发与硬件的关联十分强，其对于硬件的依赖度使得无法在技术的广泛适用性上做出统一，无法实现一个通用的汽车Bootloader，但针对特定硬件实现的技术路线和方法相通。文中基于CAN总线Bootloader系统的实现是基于上位机、USB转CAN和下位机的环境结构，如图1所示。上位机发送的数据经USB转CAN转换成CAN帧送入下位机的CAN接收缓冲区，下位机接收到消息应答将数据帧通过USB转CAN发送至上位机形成循环。系统主程序基本运行流程图如图2所示。

图1 Bootloader环境结构

图2 主程序启动流程图

启动引导功能是在Bootloader上电完成初始化之后的CAN通信循环等待接受到启动命令或者等待超时，将Flash中的应用程序加载到RAM中执行。程序下载功能是在Bootloader接收到下载程序的命令时，将应用程序代码从上位机下载下来并将其写入Flash中存储起来。

1.2 TC27xT的内存空间

TC27xT单片机支持局部地址寻址和全局地址寻址。单独对Flash进行操作时采用全局寻址的模式，对RAM和EEPROM进行操作时使用局部地址寻址［4］。TC27xT程序的存储单元（Program Memory Unit，PMU）将芯片存储区域划分为4 MB的程序存储区（PFlash0为2 MB，PFlash1为2 MB）、1 MB的数据存储区（DFlash0为1 MB，DFlash1为64 kB）和32 kB的初始启动存储区（BROM）。PFlash存储程序，DFlash存储数据，初始启动存储区存储芯片自带启动代码，存储空间划分如图3所示。

图3 存储空间划分图

2 UDS通信协议

UDS（Unified Diagnostic Services）诊断服务通过读取数据流服务的形式，获取ECU内部状态信息用于分析诊断情况，例如程序刷写次数、车辆配置信息、软硬件版本信息、ECU标定状态等。以故障码的形式存储故障，主要存储硬件故障、EE⁃PROM故障、配置不匹配、ECU未标定等故障。文中系统基于UDS的Bootloader在线刷新详情如表1所示，其操作是需要依照UDS协议规则来处理会话，用到相关的UDS服务有ECU识别、数据接收、数据传递、Flash擦除、数据写入及擦写保护等［5］。

表1 数据更新功能相关UDS服务

3 Bootloader系统具体实现

Flash存储空间由Bootloader程序和应用程序共同占据，将Bootloader系统分为如图4所示模块。

图4 Bootloader系统构架

3.1 安全模式的设计

安全模式主要负责安全访问及下载验证，文中依照IOS19229中安全访问（SecurityAccess 0x27）服务来提供下载验证：1）上位机向ECU发出信号re⁃questSeed申请种子Seed，ECU随机返回种子数；2）上位机回收Seed处理后得出有效密钥Key，然后返还给ECU，Bootloader得到访问ECU的授权［4］。

3.2 Flash驱动的设计

Flash相应函数模块如表2所示。Flash擦写之前需验证操作的合法性，程序下载时把Flash驱动复制到ECU的RAM中，应用程序下载完毕清除RAM中的数据，ECU进入正常工作状态。Flash驱动不能由DAvE配置直接生成，需根据具体单片机用户文档编写。Flash驱动有擦除和写入功能。

表2 Flash函数的定义

函数TRICORE_PFLASH_EraseSector主要用来实现选择擦写的扇区以及完成数据的擦除工作，TRICORE_PFLASH_ProgramPage函数主要在页地址处写入指定数据。Flash部分还有其他函数如TRICORE_PFLASH_VerifyPage，主要用来调用后面的函数实现数据擦除。验证擦除完成后即可把数据写入相关寄存器中。

3.3 CAN驱动的设计

CAN驱动的底层配置包括CAN初始化及CAN的发送和接收模块，初始化可分为中断、看门狗、时钟等，由开发工具DAvE完成，配置过程如图5所示。数据的接收和发送主要由CAN_vGetMsgObj和CAN_vTransmit函数实现。函数具体生成途径在DAvE中的MultiCAN Controller模块中实现，如图6所示。CAN的数据发送功能具体由通信协议实现，在CAN通信过程中，时钟模块中将CAN模块使能，选择小数分频并设置时钟为20 MHz。选择节点0，配置CAN接收和发送引脚，选择初始化引脚，波特率设为500 kBd。在报文列表中选择生成3个报文 M0、M1、M2，ID 分别为 0x121、0x122、0x123。报文数据长度都是8位，ID为标准ID。M0、M1报文从上位机到下位机，M3报文则是从下位机到上位机。ID定义见表3。

图5 DAvE配置CAN模块

图6 配置CAN收发模块

表3 通信ID定义

3.4 诊断协议的实现

Bootloader系统上位机最基本的命令可简化为建立连接、下载、断开，完成Bootloader的基本功能；而下位机需要根据相应情况进行应答。

协议实现有命令解析和命令处理2个过程。命令解析是指解析上位机传来的报文命令，命令处理则根据命令解析调用相应处理函数，将处理的结果返回给上位机［6］。文中协议中，命令解析是通过CAN ID和报文首字节命令代码来进行判断上位机将要执行的操作。命令处理过程包含调用函数执行操作和对所执行操作的结果返回成功或者失败的标志位，协议实现如图7所示。

应答报文只需在第1位填充上相应的肯定或否定应答代码即可，相应的应答代码见表4。

图7 协议解析过程

表4 应答命令表

4 调试及结果

系统在Eclipse for TriCore环境下完成集成开发，使用Hightech GUN编译器，写入生成的用户文件，在线编程过程如图8所示。将上位机与下位机通过ValueCAN连接，上位机软件登录时需要用户名及密码，这样做确保了数据的安全性［7］。从上位机发送数据模拟应用程序更新过程，最终下位机应答上位机的结果显示如图9所示。具体测试如下：1）设置连接方式为ValueCAN，波特率为500 kHz；2）ID设为0x121，发送数据为“0xFF，0，0，0，0，0，0，0”，等待应答；3）ID设为0x121，发送数据为“0xF0，0，0xFF，0xA0，0，0x80，0，0”，等待应答；4）ID设为0x122，读入测试文件，以5 ms为周期自动发送，等待应答；5）ID设为0x121，发送数据为“0xFE，0，0，0，0，0，0，0”，完成测试。

应答报文由M2（ID：0x123）从下位机发送给上位机。从图9可以看到：0x123应答“0x45”，表示已将应用程序成功写入下位机，未出现失败指令，系统刷写具备一定的稳定性。

在英飞凌配套的开发工具MTTTY中还可看到具体的数据写入地址，如图10所示，数据写入了指定位置，即0xA0008000，此次测试结果表明：该Bootloader可有效地将应用程序更新到指定下位机内，能准确地完成下载任务。

图8 在线编程

图9 下位机应答

图10 Flash中的测试数据

5 结束语

通常情况下，对于车载Bootloader而言，在单片机的启动加载状态下，Bootloader主要作用是完成系统控制权的主导和过渡，下载模式才是开发者最关注的技术要求。目前通过检测引脚电平信号引导进入Bootloader下载模式的软件系统，虽然操作简易，但功能不全重复操作率过高。

文中针对汽车Bootloader应用特点，结合CAN总线，实现了基于CAN总线的Bootloader，具体改进有：1）系统采用英飞凌32位芯片作为底层，数据处理能里以及Flash存储容量相比较传统16位的单片机，性能更优越；2）系统目的实现主要由外部请求触发进入Bootloader下载模式的机制，相较单靠检测引脚电平引导下载，可以避免系统轻易进入死循环，使得系统不单单依靠强制重新在线编程再去引导下载数据，优化了可操作性，完善了功能，效率也有所提高。

基于CAN Bootloader的在线编程系统较好地避免了频繁拆卸带来的不便和对程序更新专用工具的依赖，对准确完成数据交互、可靠实现ECU端程序的在线下载和更新有一定的价值。

［1］彭勇.汽车ECU固件远程更新的Bootloader设计与实现［D］.上海：同济大学，2014.

［2］曾其林，肖大伟，王志民，等.基于CAN Bootloader的整车控制器程序更新系统设计［J］.东方电气评论，2016，30（4）：20-23.

［3］瞿新吉.嵌入式系统的BootLoader技术浅析［J］.中国科技信息，2010（21）：103-104.

［4］王琦，黄悦鹏，邢正阳，等.基于CAN总线的Bootloader设计与实现［J］.微型机与应用，2015，34（18）：14-16.

［5］汪春华，白稳峰，刘胤博，等.基于CAN总线UDS服务BootLoader应用开发［J］.电子测量技术，2017，40（2）：166-170.

［6］杨佳宇.一种应用于汽车ECU的通用底层驱动软件设计［D］.吉林：吉林大学，2011.

［7］杨朝阳，罗永革，刘珂路.集成USB Thumb驱动器的车载数据采集系统设计［J］.湖北汽车工业学院学报，2007（3）：7-10.

Design of Bootloader for In-car Application Based on CAN Bus

Zhang Chengyu,Yang Zhaoyang,Shan Zhiwen
（Hubei Key Laboratory of Automotive Power Train and Electronic Control,Hubei University of Automotive Technology,Shiyan 442002,China）

The application update for the post-development ECU through a dedicated debug port is not only complex but also low-stability.A set of slave computer Bootloader software was proposed based on UDS diagnostic service protocols,and it was applied to the Infineon TC27xT platform.The CAN bus was used as the communication medium,the communication data interaction was completed by UDS.The firmware updating through CAN bus connection,together with memory mapping and a flash opera⁃tion library in the processor was realized.Eventually an upgrade of the online update to the car ECU was implemented.The system level test result shows that the Bootloader could update firmware to an ECU accurately and expediently.

CAN bus;UDS;Bootloader

U463.6；TP311.1

A

1008-5483（2017）04-0067-04

10.3969/j.issn.1008-5483.2017.04.015

2017-08-30

汽车零部件技术湖北省协同创新项目（2015XTZX0417）

张成雨（1992-），男，湖北十堰人，硕士，从事汽车电子方面的研究。E-mail:452796845@qq.com