《UDS协议从入门到精通》系列——图解0x34：请求下载

Tip📌：本文描述中但凡涉及到其他UDS服务的，将陆续提供链接跳转方式以便快速了解他们。（各服务介绍持续更新中…）

学习UDS基础知识以及其他相关内容？>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<

一、简介

1.1 为何需要上传下载类服务？

  参加过嵌入式软件开发工作的同志应该知道，MCU中的资源是有限的。在复杂的车载操作系统中，为了尽可能的降低汽车开发成本，在ECU的芯片选型上通常也比较严格，软件开发代码的编写也会考虑资源的利用效率，比如芯片RAM空间的使用情况。

  例如用于缓存ECU诊断数据的那块buffer通常是有限的，为了向ECU中写入数据，可以使用我们前面提到过的0x2E服务（通过ID写数据）。但当要写入的数据块很大时（最常见的就是升级ECU软件，通常数据量是要上KByte甚至MByte的），为诊断数据定义的buffer已经不能满足使用需求。于是，上传下载类服务应运而生，他们主要用于大块数据的读取或写入。

1.2 0x34服务的作用

  该服务用于启动数据传输服务，传输方向是Tester（Client）→ 目标ECU（Server），向目标ECU发送该请求的主要作用就是告知目标ECU“我（Tester）准备向你传输数据了，请你（目标ECU）准备接收数据”。

  目标ECU正确收到该请求消息后，可以发送响应告诉Tester自己是否允许传输数据，以及自己的接受能力是多大，如果可以传输，目标ECU应采取一切必要措施接收数据，然后再发送肯定响应消息。

二、数据包格式

2.1 服务请求格式

  该服务不支持sub-function。部分参数的含义如下所示：

  dataFormatIdentifier（1Byte）：这个单字节里面标识了数据格式相关的信息，每半个字节分别编码，高半字节指定 “数据压缩方法”，而低半字节则指定“数据加密方法”。如果该字节取值为0x00，则表示既不使用加密方法也不适用压缩方法，其他取值情况有整车制造商或者供应商决定，可以用约定好用不同的取值代表数据是否有压缩，是否有加密，用的又是什么算法等等。

  addressAndLengthFormatIdentifier（1Byte）：该参数含义在图中标识的已经比较清晰，不再赘述。比如memoryAddress参数占用m个字节，memorySize参数占用n个字节，则该参数取值为0x(nm)。

  memoryAddress（mByte）：对于即将启动的数据传输，该参数指明了向ECU内存写入数据的逻辑地址。比如Tester请求将数据写入ECU内存地址为0x12345678的地方（该地址占4个字节），则memoryAddress值为0x12345678，对应addressAndLengthFormatIdentifier参数低4Bits值为0x04。

  memorySize（nByte）：对于即将启动的数据传输，该参数指明了向ECU内存写入数据的字节数。比如Tester请求写入ECU数据的字节数为0x01234567（即memorySize占4字节），则memorySize值为0x01234567，对应的addressAndLengthFormatIdentifier高4Bits值为0x4。

2.2 服务响应格式

2.2.1 肯定响应

  lengthFormatIdentifier（1Byte）：该字节每半个字节单独编码，高4Bits为maxNumberOfBlockLength有效字节长度，低4Bits保留为0。

  maxNumberOfBlockLength：字节长度不定，取值长度取决于lengthFormatIdentifier的高半字节，表示0x36服务一次传输一个block的最大的字节数。比如该参数取值为0x202，则使用0x36服务时，一次最多发送字节数为0x202（字节数：0x202 >= 36 （1Byte）+ parameter（x个Bytes））。

2.2.2 否定响应

  可能出现的NRC及其含义如下：

NRC	含义
0x13	消息长度错误
0x22	当前条件不满足
0x31	请求参数不受支持，参数错误
0x33	未通过安全访问
0x70	由于某些故障导致无法下载到目标ECU的指定内存中（比如没有执行擦除就直接写入）

  NRC的处理流程如下所示（即推荐的错误情况检查顺序）：

三、通信示例

  本小节不做通信示例。因为通常0x34、0x36、0x37三个服务是放在一起使用的，学习完这三个服务之后将做一个详细的通信示例，以便更好地了解整个数据传输过程。

>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<