15765-3/14229-1-UDS刷写Bootloader笔记

本文笔记来自于ISO15765-3-2004中文版和1422-1-2013中文版，2020英文版， 感谢以上资源！笔记仅用于自己学习及大家参考~~

目录

9.7 上传/下载功能单元

9.7.1 请求下载服务（RequestDownload）(0x34)

9.7.2 请求上传服务（RequestUpload）(0x35)

9.7.3 传输数据服务（TransferData）（0x36）

9.7.4 请求传输退出服务（RequestTransferExit）（0x37）

UDS刷写流程

ECU启动时序：

bootloader会话模式切换：

重编程步骤：

预编程步骤：

主编程步骤：

后编程步骤：

142229-1给出的范例：

预编程：

主编程：

后编程：

---

先看UDS中的服务，承上面的笔记，介绍上传/下载服务

9.7 上传/下载功能单元

9.7.1 请求下载服务（RequestDownload）(0x34)

客户端请求从客户端向服务器(ECU)传输数据

dataFormatid：这个一般都给0。如果有加密的话需要考虑非零

一般用0x44

内存地址表示起始地址，长度为4字节，内存大小单位为字节，长度为4字节

肯定响应：

长度格式标识符为啥设置的是0x20呢？

最大信息组长度为啥设置的是0呢？好几个地方都这么设的

9.7.2 请求上传服务（RequestUpload）(0x35)

客户端请求服务器(ECU)到客户端的数据传输

和请求下载服务差不多。下载是从ECU到诊断仪。

9.7.3 传输数据服务（TransferData）（0x36）

客户端向服务器发送数据或服务器向客户端发送数据

块序列计数器和连续帧的编号一样，第一次都是从1开始，溢出后从0开始

传输请求参数记录就是要传输的数据。

一个块传输多少数据一般是ECU自己定义的，可以是128个byte

响应一般只有回复块序列计数器

9.7.4 请求传输退出服务（RequestTransferExit）（0x37）

客户端利用此服务终止数据传输

一般都没有这个参数，只需要回复SID就可以了。

UDS刷写流程

首先简单介绍一下bootloader，一般在ECU中存在两个程序(APP和bootloader)，分别划在ECU的不同rom地址，可以独立运行。APP主要就是应用程序逻辑的实现，bootloader主要用来引导ECU启动，更新APP。某些情况下APP可能失效，这时仍应可以上电触发bootloader刷写程序。

ECU启动时序：

在上电/复位后，ECU首先执行Bootloader代码。Bootloader执行一些基本的初始化，然后检查外部重编程请求标志位是否置为TURE。如果有重编程请求（标志被置为TURE），即使应用程序是有效的，Bootloader也会继续运行。如果当前没有重编程请求，则检查应用程序的状态：如果应用程序是有效的，则应用程序代码将被执行；如果应用程序是无效的，则继续执行Bootloader代码。

bootloader会话模式切换：

14229-1中给的参考：

实际应用中，大部分厂家都不允许直接从默认模式跳转到编程模式，如果直接发10 01 到10 02的话，会返回0x22不满足切换条件，而不是执行复位。

在Bootloader模式下，使用了三种不同的诊断会话模式：默认会话模式，扩展会话模式和编程会话模式。

从诊断会话的角度来说，要进入编程会话，必须通过扩展会话。这意味着ECU不支持直接从默认会话跳转到编程会话模式。同样地，ECU也不支持从编程会话直接跳转到扩展会话模式。

部分厂家的要求：

上电/复位后，ECU首先执行Bootloader引导代码，然后检查外部重编程请求标志位：

Ø 如果标志已被设置，那么即使应用程序是有效的，Bootloader也会继续进一步执行，在此情况下，ECU直接进入编程会话模式。

Ø 如果当前没有重编程请求，则检验应用程序的状态：

Ø 如果应用程序是有效的，则启动应用程序；

Ø 如果应用程序无效，ECU停留在Bootloader模式下的默认会话模式。

在Bootloader模式下，诊断会话转换规则与应用模式下相同。在Bootloader模式下，有以下几种方式，能导致ECU重启：

Ø 无论当前处于何种会话模式，“11 01”能引导ECU重启。

Ø 在扩展会话模式或编程会话模式下，S3定时器超时能引导ECU重启。

Ø 在编程会话模式下，“10 01”能引导ECU重启。

实际上ECU的APP可能不会在进入编程模式后就复位，可能在解锁完成后才进入boot,但boot也需要有解锁功能，比如app无效之后，只能运行boot的情况。这种其实是不符合规范要求的，在APP的扩展会话里里收到10 02就应该进boot去，再进行解锁。

重编程步骤：

1.预编程：做编程前的CAN网络准备

2.主编程：下载驱动和应用程序

3.后编程：恢复通讯，清除dtc

在刷写过程中，诊断仪需要定时发送功能寻址0x3e服务（诊断仪在线），防止在非默认会话模式中的S3定时器超时而导致ECU复位（或者是物理寻址发送，那样的话就要发很多ID了）

预编程步骤：

一般预编程执行步骤如下：

1.进入扩展模式（功能寻址）10 83 （83表示不需要服务器应答）

2.检查预编程条件（物理寻址）31 01 XX XX，针对要刷写的ECU。一般就是检查供电电压，车速这些，如果厂家没指定，那么由ECU自己定义。如果ECU不满足预编程条件，则收到10 02进入编程模式时，返回0x22不满足条件否定响应。

3.停止DTC设置（功能寻址），85 82（82表示不需要服务器应答）

4.禁止无关通讯（功能寻址），28 83 01（83表示发送和接收报文都禁止，且不需要服务器应答，01表示是应用软件报文，若第三位03则表示应用软件和网络管理报文都禁止）

5.读取版本号（物理寻址）22 XX XX ，诊断仪读取当前ECU版本信息。

波特率转换基本没有用到

主编程步骤：

一般主编程执行步骤如下：（都是针对刷写的ECU，所以用物理寻址，由诊断仪发送）

1.进入编程会话10 02 ，此时在APP中应该执行复位，然后进入boot中的编程模式

2.请求种子 27 0x(x根据主机厂给的等级来定)

3.发送密匙 27 0x key(x是请求种子的数字+1) key是经过种子加密算法计算得到的

4.解锁成功后，2E服务写入指纹信息。一般就是时间和设备号这些

5.下载flash驱动程序，34 36 37服务。因为bootloader里是不带驱动程序的，防止意外操作导致flash改变，程序出现异常，所以只在刷写的时候才允许操作flash。下载完成后一般还需要例程控制31服务进行完整性检查（CRC32校验）和依赖性检查（ecu指定，DID为FF01-14229-1规定）

6.擦除内存，由31服务执行，具体的DID按14229-1应该为FF00，按道理需要给定擦除的起始地址和大小，但是实际运用过程中好像是ECU自己判断的。

7.下载APP程序，34，36，37服务。下载完成后也需要例程控制31服务中的完整性检查（CRC32校验）和依赖性检查（ecu指定，DID为FF01-14229-1规定）

8.ECU复位，一般发送11 01进行复位，复位完成后Flash驱动程序将被清除。避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

后编程步骤：

1.主编程完成后，ECU复位，诊断仪发送进入扩展模式10 83（功能寻址，不需要ECU回复）

2.恢复通讯28 80 03（功能寻址，不需要ECU回复，03表示网络管理报文和应用报文都恢复）

3.开启DTC诊断85 81（功能寻址，不需要ECU回复）

4.清除刷写ECU的故障信息（物理寻址14 FF FF FF）

5.进入默认会话模式10 01（功能寻址）

以上，整个刷写过程就结束了。

142229-1给出的范例：

预编程：

延长会话翻译的不太好，应该是扩展会话

读取版本号没有在范例中给出

主编程：

后编程：

此处没有给出，进入扩展模式10 83恢复通讯28 80 03（功能寻址，不需要ECU回复，03表示网络管理报文和应用报文都恢复），开启DTC诊断85 81（功能寻址，不需要ECU回复），清除刷写ECU的故障信息（物理寻址14 FF FF FF）的流程