【ISO14229_UDS刷写】-1-$34诊断服务RequestDownload理论部分

已于 2023-05-27 12:20:03 修改
阅读量2.4k 收藏 14
点赞数 2
CC 4.0 BY-SA版权
分类专栏： UDS/OBD诊断/刷写 # Bootloader刷写 文章标签： bootloader UDS诊断刷写
于 2023-05-27 00:08:40 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qfmzhu/article/details/130895695

总目录：（单击下方链接皆可跳转至专栏总目录）

《UDS/OBD诊断需求编辑工具》总目录https://blog.youkuaiyun.com/qfmzhu/article/details/123697014

目录

1 $0x34 RequestDownload诊断服务描述

2 0x34服务请求消息

2.1 0x34服务请求消息定义

2.2 0x34服务请求消息子功能参数$ Level（LEV_）定义

2.3 0x34服务请求消息数据参数定义

3 0x34服务肯定响应消息

3.1 0x34服务肯定响应消息定义

3.2 0x34服务肯定响应消息数据参数定义

4 0x34服务支持的否定响应代码（NRC_）

5 示例：0x34 RequestDownload服务消息流

附录：H.1 addressAndLengthFormatIdentifier示例值

结尾

优质博文推荐阅读（单击下方链接，即可跳转）：

点击返回「《Autosar从入门到精通-实战篇》总目录」

点击返回「《Autosar_BSW高阶配置》总目录」

点击返回《嵌入式硬件/软件开发刷写/烧录文件》专栏

RequestDownload（0x34） service请求下载服务

服务

SID

描述

RequestDownload

读取DTC信息

0x34

client请求协商从client到server的数据传输。

1 $0x34 RequestDownload诊断服务描述

requestDownload服务被client用来启动从client到server的数据传输（下载）。

在server收到requestDownload请求消息后，server应采取所有必要的行动来接收数据，然后再发送一个positive response message肯定响应消息。

重要的是 - server和client应满足ISO 14229-1的7.5章节中规定的请求和响应消息行为。

2 0x34服务请求消息

2.1 0x34服务请求消息定义

表393 - 请求消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

RequestDownload Request SID

请求下载请求SID

M

0x34

RD

#2

dataFormatIdentifier

数据格式标识符

M

0x00 – 0xFF

DFI_

#3

addressAndLengthFormatIdentifier

地址和长度格式标识符

M

0x00 – 0xFF

ALFID

#4

:

#(m-1)+4

memoryAddress[] = [

byte#1 (MSB)

:

byte#m ]

M

:

C1

0x00 – 0xFF

:

0x00 – 0xFF

MA_B1

:

Bm

#n-(k-1)

:

#n

memorySize[] = [

byte#1 (MSB)

:

byte#k ]

M

:

C2

0x00 – 0xFF

:

0x00 – 0xFF

MS_B1

:

Bk

C1：这个参数的存在取决于addressAndLengthFormatIdentifier的地址长度信息参数。

C2：该参数的存在取决于addressAndLengthFormatIdentifier的memory size长度信息。

2.2 0x34服务请求消息子功能参数$ Level（LEV_）定义

此服务不使用子功能参数。

2.3 0x34服务请求消息数据参数定义

表394 - 请求消息数据参数定义

定义

dataFormatIdentifier数据格式标识符

这个数据参数是一个字节的值，每个nibble单独编码。high nibble指定 " compressionMethod压缩方法"，low nibble指定 " encryptingMethod加密方法"。值0x00指定既不使用compressionMethod也不使用encryptingMethod。除了0x00以外的值是由vehicle manufacturer车辆制造商决定的。

addressAndLengthFormatIdentifier地址和长度格式标识符

该参数是一个字节值，每个nibble单独编码（见H.1的示例值）：

位7 - 4: memorySize参数的长度(字节数)

位3 - 0: memoryAddress参数的长度（字节数）。

memoryAddress内存地址

参数memoryAddress是要写入数据的server memory的起始地址。这个地址使用的字节数由addressAndLengthFormatIdentifier的low nibble（bit 3 - 0）定义。memoryAddress参数中的Byte#m总是在server中被引用的地址中LSB（least significant byte）。地址中MSB（most significant byte）可以作为memory identifier使用。

一个使用memory identifier的例子是一个具有16位寻址和memory address重叠的双processor server (当一个给定的地址对任何一个处理器都有效，但产生了不同的physical memory device或使用了内部和外部flash）。在这种情况下，memoryAddress参数中一个未使用的字节可以被指定为memory identifier，用于选择所需的memory device。该功能的使用应按照车辆制造商/系统供应商的规定。

memorySize内存大小

这个参数应被server用来比较memory size和TransferData service期间传输的数据总量。这增加了programming编程的安全性。用于该大小的字节数由addressAndLengthFormatIdentifier的high nibble（第7-4位）定义。如果使用了数据压缩，memory size是否代表压缩或未压缩的大小是由车辆制造商决定的。

3 0x34服务肯定响应消息

3.1 0x34服务肯定响应消息定义

表395 - 肯定响应消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

RequestDownload Response SID

请求下载响应SID

M

0x74

RDPR

#2

lengthFormatIdentifier

M

0x00 – 0xF0

LFID

#3

:

#n

maxNumberOfBlockLength = [

byte#1 (MSB)

:

byte#m ]

M

:

M

0x00 – 0xFF

:

0x00 – 0xFF

MNROB_ B1

:

Bm

3.2 0x34服务肯定响应消息数据参数定义

表396 - 响应消息数据参数定义

定义

lengthFormatIdentifier长度格式标识符

这个参数是一个字节的值，每个nibble单独编码：

位7-4：maxNumberOfBlockLength参数的长度（字节数）。

位3-0：由文件保留，要设置为'0'。

该参数的格式与请求信息中包含的addressAndLengthFormatIdentifier参数的格式兼容，只是lower nibble必须被设置为'0'。

maxNumberOfBlockLength最大块长度

这个参数被requestDownload肯定响应消息用来通知client在server的每个TransferData请求消息中包含多少数据字节（maxNumberOfBlockLength）。这个长度反映了完整的消息长度，包括service identifier和TransferData请求消息中的数据参数。这个参数允许client在开始向server传输数据之前适应server的接收缓冲区大小。server需要接受长度等于其报告的maxNumberOfBlockLength的transferData请求。接受何种长度小于maxNumberOfBlockLength的transferData请求（如果有的话）是由server决定的。请注意，一个给定区块内的最后一个transferData请求可能被要求小于maxNumberOfBlockLength。server不允许写入不包含在transferData消息中的额外数据字节（即填充字节）（无论是以压缩或未压缩的格式），因为这将影响后续transferData请求数据写入的memory address。

4 0x34服务支持的否定响应代码（NRC_）

对于这项服务，应执行以下negative response code否定响应代码。表397中记录了每个响应代码会发生的情况。如果错误情况适用于server，应使用列出的negative response否定响应。

表397 - 支持的否定响应代码

NRC

描述

助记符

0x13

incorrectMessageLengthOrInvalidFormat消息长度不正确或格式无效

如果信息的长度有误，则应发送该NRC。

IMLOIF

0x22

conditionsNotCorrect条件不正确

如果server在接收软件或标定模块的下载过程中收到该服务的请求，应返回该NRC。如果在下载模块的过程中，server和client之间出现数据大小不匹配，就会出现这种情况。

CNC

0x31

requestOutOfRange请求超出范围

如果出现以下情况，将返回这个NRC：

指定的dataFormatIdentifier是无效的。

指定的addressAndLengthFormatIdentifier是无效的。

指定的memoryAddress/memorySize是无效的。

ROOR

0x33

securityAccessDenied安全访问被拒绝

如果在收到对该服务的请求时，server是安全的（对于支持SecurityAccess服务的server），应返回这个NRC。

SAD

0x70

uploadDownloadNotAccepted上传下载不被接受

该NRC表明，由于某些故障条件，无法完成向server的memory下载的尝试。

UDNA

评价顺序记录在图26中。

Key

1)至少5个（SI+DFI_+ALFID+最小MA_+最小MS_）。

2)长度可以从addressAndLengthFormatIdentifier中计算出来。

图26 - NRC处理请求下载服务

5 示例：0x34 RequestDownload服务消息流

详见以下博文：

【ISO14229_UDS刷写】-6-$34,$35,$36,$37诊断服务用于downloading下载/uploading上载数据的消息流示例icon-default.png?t=N4P3https://blog.youkuaiyun.com/qfmzhu/article/details/130895979

附录：H.1 addressAndLengthFormatIdentifier示例值

表 H.1 包含 addressAndLengthFormatIdentifier 的high和low nibble的值组合示例。需要考虑以下几点：

⎯对于“manageable memorySize”或“memoryAddress range”标记为“not applicable”的值，不允许使用，并且必须通过否定响应消息被server拒绝。

⎯此参数允许具有适用的“manageable memorySize”和“memoryAddress range”的值。

表H.1 - addressAndLengthFormatIdentifier示例

Byte Value

Description

bit 7-4 (high nibble) number of memorySize bytes

bit 3-0 (low nibble) number of memoryAddress bytes

bytes used for memorySize parameter

manageable size

bytes used for memoryAddress parameter

addressable memory

0x00

not applicable

not applicable

not applicable

not applicable

0x01

not applicable

not applicable

1

256 Byte - 1

0x02

not applicable

not applicable

2

64 KB - 1

0x03

not applicable

not applicable

3

16 MB - 1

0x04

not applicable

not applicable

4

4 GB - 1

0x05

not applicable

not applicable

5

1,024 GB - 1

0x06 – 0x0F

:

:

:

:

0x10

1

256 Byte

not applicable

not applicable

0x11

1

256 Byte

1

256 Byte – 1

0x12

1

256 Byte

2

64 KB – 1

0x13

1

256 Byte

3

16 MB – 1

0x14

1

256 Byte

4

4 GB – 1

0x15

1

256 Byte

5

1,024 GB – 1

0x16 – 0x1F

:

:

:

:

0x20

2

64 KB

not applicable

not applicable

0x21

2

64 KB

1

256 Byte – 1

0x22

2

64 KB

2

64 KB – 1

0x23

2

64 KB

3

16 MB – 1

0x24

2

64 KB

4

4 GB – 1

0x25

2

64 KB

5

1,024 GB – 1

0x26 – 0x2F

:

:

:

:

0x30

3

16 MB

not applicable

not applicable

0x31

3

16 MB

1

256 Byte – 1

0x32

3

16 MB

2

64 KB – 1

0x33

3

16 MB

3

16 MB – 1

0x34

3

16 MB

4

4 GB – 1

0x35

3

16 MB

5

1,024 GB – 1

0x36 – 0x3F

:

:

:

:

0x40

4

4 GB

not applicable

not applicable

0x41

4

4 GB

1

256 Byte – 1

0x42

4

4 GB

2

64 KB – 1

0x43

4

4 GB

3

16 MB – 1

0x44

4

4 GB

4

4 GB – 1

0x45

4

4 GB

5

1,024 GB - 1

0x46 -0xFF

:

:

:

:

以上摘自《ISO 14229-1:2013》。

结尾

获取更多“汽车电子资讯”和“工具链使用”，

请关注优快云博客“汽车电子助手”，做您的好助手。

UDS服务——RequestDownload（0x34）
诊断协议那些事儿's blog
06-22 872
0x34请求下载服务(Request Download)，客户端使用请求下载服务启动从客户端到服务器的数据传输(下载)。在服务器接收到requestDownload请求消息后，服务器应在发送积极响应消息之前采取所有必要的操作来接收数据。本服务没有子服务。
《UDS协议从入门到精通（UDS速查手册）》（完结撒花版）
热门推荐
车载系统攻城狮
10-12 5万+
专栏总目录，文中介绍了UDS协议相关的基础知识和一些术语，给出了详细介绍6大类26种服务的跳转目录。
UDS诊断（ISO14229-1） 34服务
m0_56208280的博客
01-15 1万+
34服务，即 RequestDownload（请求下载）服务，客户端利用 requestDownload（请求下载）服务启动客户端到服务器之间的数据传输（下载）。
【UDS诊断】——0x34、0x36、0x37服务
LOVE135149的博客
08-26 3473
Client端使用Routine Control服务来执行定义的步骤序列并获取特定序列的相关结果。该服务有极大的灵活性。Service31的典型用途可以包括擦除内存、重置定义的数据、覆盖正常服务控制策略以及控制ECU值随时间变化的功能。通过Service31可以启动特定序列、停止运行该特定序列、请求运行结果。该服务以往常用于ECU在做Software Update时，应用于检查刷写条件是否满足、传输数据完整性以及独立性检测。
跟我学UDS(ISO14229) ———— 0x34(RequestDownload)
永远的菜鸡小詹的博客
06-28 6132
  客户端请求从客户端到服务器的数据传输。服务器收到 requestDownload 请求消息后，服务器应在发送肯定响应消息之前采取所有必要的措施来接收数据。在这里，ISO 14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。我所在项目的要求是：进入ProgrammingSession 会话模式下，并对安全访问进行解锁之后才能进行数据的传输。 诊断请求格式  具体的格式如下： 参数 memoryAddress 与 memorySize 的长度均取决于
【ISO14229_UDS_0x34服务详解】
weixin_43722921的博客
08-16 3254
本文介绍了0x34服务(RequestDownload，请求下载服务)的使用说明
UDS诊断ISO14229新手入门篇
weixin_45387165的博客
09-21 1254
这个命令的格式稍微复杂一点。sub-function = 0x06 用于读取某个 DTC 及其相关的环境数据，此时 parameter 为 4 个 byte，前三个 byte 用于标识我们要读取的 DTC，第四个 byte 用于标识要读取的环境数据的范围，UDS 规定使用 FF 来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括 DTC 状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此 DTC 产生时的测量数据。
UDS 14229-1标准中34、36、37服务标准的讲解。
weixin_49226455的博客
08-02 1983
UDS 14229-1标准中的刷写34、36、37服务共同构成了ECU刷写的完整流程。
UDS诊断服务列表.pdf
11-14
UDS（统一诊断服务）是汽车领域中广泛使用的一套标准通信协议，主要用于汽车ECU...了解和运用这些UDS诊断服务是汽车电子技术领域的一个重要部分，它对于诊断车辆故障、程序更新、系统监控以及满足法规要求至关重要。
UDS 官方推荐刷写Firmware流程
yeweiliang_93的博客
02-03 1750
UDS 官方推荐刷写Firmware流程
UDS $34服务，学习笔记
m0_50837859的博客
03-26 1178
Tester向目标ECU请求下载服务上述图片是AUTOSAR官方文档内容。这是第二个字节的参数，其中高4个bit表示压缩方法，低4个bit表示加密方法，一般情况就是0x00请求刷写地址和长度格式，高4个bit表示下面的memorySize参数占几个字节，低4个bit表示下面的参数占几个字节。就是memorySize和各占4个字节。请求刷写的首地址，这个参数占几个字节由参数的低4个bit决定的请求刷写的字节长度，这个参数占几个字节由参数的高4个bit决定的。
UDS_RequestDownload(0x34)服务
weixin_68852042的博客
11-08 839
DS的第六类诊断服务：存储数据传输。该类型服务包含SID如下：RequestDownload (0x34)：请求下载数据，诊断仪向ECU请求下载数据RequestUpload (0x35)：请求上传数据，诊断仪向ECU请求上传数据TransferData (0x36)：数据传输，诊断仪向ECU传数据（下载），或者ECU向诊断仪传数据（上传）RequestTransferExit (0x37)：数据传输完成，请求退出。
UDS 34/36/37 服务
qwe0405080615的博客
02-09 9229
UDS 34/36/37 服务
UDS 诊断 - RequestDownload（请求下载）（0x34）服务
耳朵东金子千的博客
09-12 1793
字节参数名称Cvt字节值#1RequestDownload （请求下载） 请求 SIDM0x34#2dataFormatIdentifier（数据格式标识符）M#3addressAndLengthFormatIdentifier（地址和长度格式标识符）M#4#(m-1)+4byte#m ]MC1#n-(k-1)#nbyte#m ]MC2C1：此参数的存在性取决于 addressAndLengthFormatIdentifier 的地址长度信息参数。
uds服务-上传下载功能单元【34、36、37】
yunhuhude的博客
02-14 2796
0x34 00-FF 44 数据格式标志符，【00-FF】，左半元组表示压缩方法，右半元组表示加密算法，如果没有应用压缩或者加密，相应位为0 44的bit7~4表示memorysize参数的长度 bit3~0表示memoryadress参数的长度TransferData （0x36）—— 数据传输这个服务通常是用来下载/上传数据时用的，数据的传输方向由不同的服务控制：0x34服务表示下载，0x35服务表示上传。0x36服务包含了一个blockSequenceCounter，在多个服务请求序列失败的时候以提高
汽车诊断之UDS入门-数据传输服务0x34,0x36,0x37
weixin_44842720的博客
09-28 4177
数据传输服务0x34,0x36,0x37
【车载开发系列】UDS诊断---请求下载（$0x34）
千月星跡
12-16 1158
【车载开发系列】UDS诊断—请求下载（$0x34） UDS诊断---请求下载（$0x34）【车载开发系列】UDS诊断---请求下载（$0x34）一.概念定义二.产生背景三.报文格式1）请求报文2）肯定响应3）否定响应 一.概念定义 请求下载就是RequestDownload（34h）。也是一个比较常用的服务。 诊断工具使用此服务初始化从诊断工具到ECU的数据传输（下载）。 接收到此服务的请求报文时，ECU应在发送肯定响应报文前，采取所有必要动作用于数据接收。 二.产生背景 车ECU中用于缓存诊断服务数据的缓
0x34RequestDownload请求下载
不断debug，优化中……
06-02 644
iso14229 系列学习
ISO14229 -1 UDS诊断服务记录-001：0x34\0x36\0x37\0x31\0x19\0x14服务报文格式介绍
梦想技术家
05-09 2490
高位表示“Compression Method”，低位表示“Encryption Method”。0x00表示不使用Compression Method和Encryption Method，非0x00值由主车厂自定义。Compression Method：压缩方法Encryption Method：加密方法bit 3-0表示memoryAddress参数字节数，bit 7-4表示memorySize参数字节数。（一般为0x44表示4个字节地址，4个字节数据长度）
uds诊断app刷写bootloader刷写
最新发布
02-26
### 使用UDS诊断服务进行Bootloader刷写 #### 所需工具 要执行基于统一诊断服务（UDS）的Bootloader刷写操作，需要准备以下工具： - 支持UDS协议的诊断设备或软件环境。 - 符合ISO 14229标准的通信接口硬件，如CAN适配器。 - 刷写所需的固件文件（Bootloader二进制镜像）。 这些工具能够确保按照规范与ECU建立稳定可靠的连接并传输必要的指令和数据[^1]。 #### 操作步骤 ##### 进入编程会话模式 由于大多数情况下，默认状态下不允许直接访问用于刷写的命令集，在开始刷写之前，应先请求进入编程会话模式。此过程涉及向ECU发送`DiagnosticSessionControl (0x10)`服务请求，并指定目标为编程会话（Programming Session）。这一步骤对于激活后续可用于刷写的其他功能至关重要[^2]。 ```python # Python伪代码示例：发起编程会话控制请求 uds_client.send([0x10, 0x02]) # 发送 DiagnosticSessionControl 请求至 Programming Session response = uds_client.receive() if response != [0x50, 0x02]: raise Exception("Failed to enter programming session.") ``` ##### 安全认证 为了防止未经授权的操作，许多现代ECU实现了多级安全机制来保护其内部资源免受非法篡改。因此，在尝试加载新的Bootloader版本前，必须通过相应的安全验证程序。通常采用`SecurityAccess (0x27)`服务来进行身份验证，具体方法取决于制造商设定的安全算法和密钥交换逻辑[^3]。 ```python # Python伪代码示例：执行安全访问挑战/响应序列 challenge_request = [0x27, 0x01] uds_client.send(challenge_request) challenge_response = uds_client.receive() key = calculate_key_based_on_challenge(challenge_response) access_request = [0x27, 0x02] + key uds_client.send(access_request) final_response = uds_client.receive() if final_response[:2] != [0x67, 0x02]: raise Exception("Security access failed.") ``` ##### 下载新Bootloader映像 一旦获得了适当权限，则可以通过调用`TransferData (0x36)`等相关服务逐步上传待安装的新Bootloader映像到临时存储区。在此期间还需定期确认接收状态以保证整个过程顺利完成。最后利用`RequestDownload (0x34)`启动实际的数据传送流程[^4]。 ```python # Python伪代码示例：初始化下载并分批传输数据包 block_size = get_optimal_block_size() # 获取最佳块大小 total_blocks = len(firmware_image) / block_size request_download_command = construct_request_download_message(total_blocks * block_size) uds_client.send(request_download_command) verify_positive_acknowledgment(uds_client.receive()) for i in range(int(total_blocks)): data_chunk = firmware_image[i*block_size : (i+1)*block_size] transfer_data_command = build_transfer_data_packet(i + 1, data_chunk) uds_client.send(transfer_data_command) verify_positive_acknowledgment(uds_client.receive()) ``` ##### 应用更新后的Bootloader 当所有预期字节都被正确传送到目的地之后，还需要发出特别的服务请求让ECU知道何时应该切换到刚刚接收到的新版Bootloader运行环境中去。这一环节往往涉及到`RoutineControl (0x31)`或其他类似的专用命令，用来指示ECU重启并从新位置引导系统启动。 ```python # Python伪代码示例：触发ECU重置并启用新版Bootloader reset_and_activate_new_bootloader_command = prepare_reset_sequence_for_activation() uds_client.send(reset_and_activate_new_bootloader_command) wait_until_ecu_responds_with_initialization_status() ``` #### 注意事项 在整个过程中有几个关键点值得注意： - **安全性**：严格遵守各阶段的安全校验措施，避免因误操作而导致不可逆损坏； - **兼容性**：确保所使用的工具链完全匹配目标ECU型号及其配置选项； - **备份恢复方案**：建议事先做好充分准备工作，包括但不限于创建现有系统的完整副本以便出现问题时快速回滚； - **环境监测**：持续监控外部因素如电源供应状况、网络连通情况等，减少外界干扰带来的风险。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车电子助手

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值