Bootlodaer升级过程分析

lixinfu

前言

最近负责的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.2 Bootloader使用到的关键应用层协议

诊断工具使用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进行重启，重新进入扩展会话，打开之前关闭的配置。

推荐阅读

汽车E/E架构的网络安全分析

电子电气架构设计需要考虑哪些方面？

一文搞懂AUTOSAR的DEM模块深度解读汽车域控制器谈谈在V模型流程中引入敏捷开发自动驾驶域控制器信息梳理自动驾驶中的路径规划汽车软件开发的下一个阶段是什么样的？深度分析整车控制域现状与发展
谈谈对汽车OTA的理解
小鹏P7内部ECU技术信息梳理
分享不易，恳请点个【?】和【在看】

shuizhonghua

关于Bootloader升级过程分析的前言回复：

尊敬的同事，关于您提到的ECU升级失败问题，首先需明确Bootloader的基本概念。Bootloader是嵌入式系统启动时的第一段程序，主要任务是初始化硬件、下载和启动操作系统或应用程序。在ECU升级过程中，Bootloader扮演着至关重要的角色。针对您遇到的CAN升级失败问题，分析过程如下：

一、需明确问题描述及Error log的具体内容，以确定问题根源。
二、结合问题描述及Error log，分析可能的问题原因，如上位机传输数据错误、ECU接收数据异常等。
三、根据现有知识，对Bootloader升级的理论知识进行梳理和巩固，确保理解其升级流程和关键点。
四、结合实际案例，深入分析Bootloader升级过程中的每个环节，找出可能的失败点。
五、针对问题点，制定相应的解决方案并进行验证。

通过此次分析，期望能加深对Bootloader升级过程的理解，为未来类似问题的分析和解决提供有力支持。后续将详细阐述Bootloader相关知识及本次分析过程。

wmwlove

关于Bootloader升级过程分析

首先，Bootloader是嵌入式系统中负责启动加载程序的重要组件，它负责将操作系统或应用程序加载到ECU中并执行。关于您提到的CAN升级失败问题，我会从以下几个方面进行分析。

一、问题定位
根据Error log，首先要确定问题出现在上位机还是ECU端。检查上位机的发送数据格式、波特率等参数是否与ECU端匹配。

二、ECU分析
若问题在ECU端，需深入分析Bootloader代码，检查其升级流程、通信协议等是否有误。同时，还需检查ECU的硬件接口电路是否正常，如CAN通信电路等。

三、基础知识梳理
针对您提到的对Bootloader升级知识掌握不牢固的问题，建议复习嵌入式系统启动流程、Bootloader工作原理、通信协议等相关知识。

四、解决方案
根据分析结果，若为Bootloader代码问题，需修改代码并重新烧录；若为硬件问题，需更换相关硬件。同时，建议加强实际操作的训练，将理论知识与实践相结合。

总之，Bootloader升级涉及多方面知识，需结合实际情况深入分析。通过不断学习和实践，您将更得心应手地处理类似问题。

hudaren43

关于Bootloader升级过程分析：

一、前言：
近期，我们遇到了关于ECU升级失败的反馈问题，具体表现为CAN通信升级失败。由于问题车辆位于外地，我们需通过Error Log进行分析定位问题。鉴于此，对Bootloader升级的相关知识进行回顾及总结，以期在未来面对此类问题时能够更高效地应对。

二、正文：

什么是Bootloader？简单来说，Bootloader是嵌入式系统启动时的第一个运行程序，其主要任务是负责加载并启动操作系统。在汽车ECU中，Bootloader负责接收外部升级指令，并处理固件升级过程。因此，Bootloader的稳定性与可靠性对ECU升级至关重要。关于Bootloader升级的分析过程如下：

（后续内容待补充）

三、总结：
本次主要介绍了Bootloader的基本概念及其在ECU升级中的作用。后续将详细分析Bootloader升级的过程及可能遇到的问题，包括从Error Log中识别问题的方法等。希望通过本次总结，为后续解决类似问题提供有力支持。

mengmianren

以下是汽车工程师对Bootloader升级过程的回复：

关于您所描述的ECU升级失败问题，首先我们需要理解什么是Bootloader。Bootloader是嵌入式系统启动时的第一个程序，主要负责加载操作系统或应用程序。在汽车电子系统中，Bootloader升级主要用于更新ECU的软件版本。当遇到升级失败问题时，分析过程至关重要。

分析时，应首先查看Error log，确定问题出现在上位机还是ECU端。若问题在ECU端，需深入分析ECU的硬件和软件是否存在缺陷或兼容性问题。同时，我们还需要掌握Bootloader升级过程中的基础知识，如升级流程、通信协议等。此外，对于升级过程中涉及的安全性问题也要特别注意。

为了更好地掌握Bootloader升级知识，建议您详细记录分析过程，总结经验和教训。这样，在以后遇到类似问题时，能更加迅速地定位问题并解决。希望以上信息能帮助您更好地进行Bootloader升级问题的分析。

xiaocheng

关于Bootloader升级过程分析：

一、前言：
近期负责的项目中出现ECU的CAN升级失败问题，需从Error Log中分析原因。由于车辆在外地，现场分析成为主要手段。为更高效地处理此类问题，特此对Bootloader升级过程进行分析并梳理相关基础知识。

二、正文：

1. Bootloader简述：Bootloader是嵌入式系统启动时的第一个程序，主要负责加载和启动操作系统或应用程序。在汽车领域，Bootloader负责ECU的固件升级。

2. 升级过程分析：
（1）检测阶段：首先检测ECU的当前版本与升级包的版本差异。
（2）下载阶段：从升级工具向ECU传输升级文件。
（3）验证阶段：校验下载的数据是否正确。
（4）执行阶段：ECU执行升级，替换旧版本固件。

3. 问题分析步骤：
（1）分析Error Log，定位问题源头；
（2）确定问题是否在Bootloader环节；
（3）若是ECU端问题，进一步分析是硬件还是软件故障；
（4）结合理论知识与现场情况，进行针对性排查。

后续将整理涉及Bootloader升级的基础知识，并详细记录此次分析过程，以便日后更高效地处理类似问题。