汽车ECU的Bootloader升级过程分析

前言

最近负责的ECU报了CAN升级失败的问题，反馈到开发这边就是问题描述和一堆的Error log，因为发生问题的车辆在外地，这就需要我们从Error Log中找到问题所在（起码找到是上位机问题还是ECU端问题，如果是ECU的问题还要继续分析ECU为啥故障），因为以前的Bootloader升级知识还停留在理论阶段，到真正找问题的时候还是有很多模糊的地方的，终归还是对一些基础试着掌握的不牢固，这里把分析过程中需要的基础知识都列出来，同时把升级的分析过程也记录下来，希望以后分析Bootlodaer的升级问题时能更加得心应手。

正文

1.什么是Bootloader

MCU正常运行时总是从固定地方取指令，顺序运行，程序更新时需要使用烧录器等工具烧录，于是有人将程序设计成，由一个程序跳转到另一个程序，这个程序通常称作Bootloader，另一个叫做APP。

Bootloader程序常常具有通信接口和擦写内部存储空间的功能，可将需要更新的APP擦除，写入新的APP。有时会设计成相互跳转，技术也是可以实现的。有些为了保证程序不丢失，单独预留出备份区和出厂版本，出现某些错误时可以恢复到出厂版本或使用其他APP均可。

2.汽车ECU的Bootloader

汽车ECU也就是汽车控制器单元，专门用在汽车上。ECU经常会用在汽车零部件中，零部件密封性等要求都比较苛刻，并且装车，如果想取下零部件可能需要将车拆解才可以做到，这种行为是不被允许的，成本极高，操作复杂，因此大多主机厂（OEM）要求ECU具有升级功能，并且通过多年的积淀制定了行业标准UDS。

3.Bootloader刷写使用的协议

UDS（Unified Diagnostic Services，统一诊断服务）诊断协议是用于汽车行业诊断通信的需求规范，由ISO 14229系列标准定义。应用于OSI七层模型的应用层（第7层），它只规定了与诊断相关的服务需求，并未涉及通信机制，所以，它可以在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet）上实现。

ISO 14229 一个用于汽车行业诊断通信的需求规范，它只规定了与诊断相关的服务需求，并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO 15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO 14229也称为UDS（Unified Diagnostic Services）。

ISO 15765 协议是一种CAN总线上的诊断协议。ISO 15765 3 协议是按照 ISO 14229 1，描述了在 ISO 11898 定义的控制器局域网中统一诊断服务(UDS)的实施。它给所有汽车连接至CAN网络服务器及外部测试设备提供诊断服务及服务器存储器编程的需求。基于CAN总线的升级方式是目前汽车ECU升级的最主要升级方式。

ISO 17987 其中定义LIN通信相关部分。诊断通信用于建立诊断仪与ECU之间的通信连接，并负责将ECU中的诊断结果输送到诊断仪中。

UDS的作用非常广泛，几乎跟随ECU软件开发的全过程。

CAN Driver:最小化的CAN驱动。

TP：提供最小化的 CAN TP，实现ISO-15765-2传输协议。

Diag：诊断层，实现裁剪后适用Boot的诊断服务。

3.1基于CAN的传输层协议

分析升级过程的报文Log时，看到的都是最原始的报文数据（标准CAN：8 Byte，CANFD：8，12，16，20，24，32，48，64 Byte），所以我们不光要熟悉应用层的数据格式，也要熟悉传输层的数据格式。

如果使用标准CAN，则所有的报文数据都是8 Byte，如下图所示：

如果诊断应用层数据长度小于等于7 Byte，则使用单帧（SingleFrame, SF）数据，Byte 0的Bit0-Bit3为应用层协议数据长度，Bit4-Bit7为单帧固定标识00。

例如：

Request: 02 10 03 CC CC CC CC CC --> 单帧数据，协议数据长度SF_DL为2，协议数据为10 03，后面的CC为填充数据

Response: 06 50 03 00 32 00 C8 AA --> 单帧数据，协议数据长度SF_DL为6，协议数据为0 03 00 32 00 C8，后面的CC为填充数据

如果诊断应用层数据长度大于7Byte，则需要使用首帧（FF）+连续帧（CF）传输数据，首帧（FF）的Byte 0的Bit4-7为首帧的固定标识01，Byte 0的Bit0-Bit3+Byte 1为应用层协议数据长度。

Response: 10 14 62 F1 89 00 00 00 --> 首帧数据，协议数据长度为0x014（20）个字节，首帧协议数据长度固定6个字节，内容为 62 F1 89 00 00 00。

连续帧（CF）的Byte0的Bit4-Bit7为连续帧的固定标识20，Byte 0的Bit0-Bit3为SN编号（连续帧序号，共4bit，0--0xF循环），协议数据长度为7个Byte。

Respons: 21 00 00 00 00 00 B8 AC --> 连续帧的第一帧数据（0x21），协议数据为7个Byte，内容为00 00 00 00 00 B8 AC。

流控帧（FC）Byte0的Bit4-7为固定标识（11b），bit0-bit3为FS，Byte 1为BS（Block size），Bite 2为STmin（Seperation time）。

表1：标准CAN的传输层帧格式

如果使用标准CANFD，则数据长度是可变的如下图所示，这里不在赘述。

表2：CANFD的传输层帧格式

表3：CANFD下首帧或连续帧的最后一帧的帧长度

3.2Bootloader使用到的关键应用层协议

诊断工具使用0x34服务初始化从诊断工具到ECU的数据传输（下载）。接收到此服务的请求报文时，ECU应在发送肯定响应报文前，采取所有必要动作用于数据接收。

表4：0x34服务的请求帧数据格式

表5：0x34服务的积极响应帧数据格式

诊断工具使用0x36服务从诊断工具到ECU传输数据（下载）或者从ECU到诊断工具传输数据（上传）。

表6：0x36服务的请求帧数据格式

表7：0x36服务的积极响应帧数据格式

诊断工具使用0x37服务终止诊断工具与ECU的数据传输。

表8：0x37服务的请求帧数据格式

表9：0x37服务的积极响应帧数据格式

4.Bootloader中诊断升级流程

UDS服务设计复杂，Bootloader升级一般分为以下三步：

1）预编程：主要进行一些环境配置

2）编程：刷写过程

3）刷新完成：恢复配置

Bootloader可以保证在上述三个阶段任一问题出现都能再次进入该过程重新刷新。

4.1预编程阶段

在进入刷新之前，UDS的85服务和28服务，关闭DTC诊断同时停发非诊断报文。使整个CAN网络处于静默（Silent）状态。这是对整车网络进行操作的，一般都是以功能寻址（Functional addressing）的方式来发送。注意先用85服务关闭DTC，再使用28服务关报文。关闭DTC诊断是防止升级过程误报DTC（例如通信丢失DTC等），关闭CAN通信是为了降低总线负载，加快刷写速度。

4.2编程阶段

UDS设计了安全访问功能，安全访问是为了保证ECU数据的安全，实现方式是由ECU发送一个随机数种子到主机，主机通过对应ECU预先定义好的算法算出结果与ECU算出结果进行比对，结果一致则解锁成功通过安全验证。ECU解锁可以存在多个等级，安全要求越高则需要的安全等级越高（使用0x27服务实现）。

写时候先写DID指纹，标记写软件人的身份（按照主机厂要求），擦写下载等操作。

4.3编程结束

刷写完成之后，ECU进行重启，重新进入扩展会话，打开之前关闭的配置。

审核编辑 ：李倩