【ISO14229_UDS刷写】-3-$36诊断服务TransferData理论部分

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

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

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

目录

1 $0x36 TransferData诊断服务描述

2 0x36服务请求消息

2.1 0x36服务请求消息定义

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

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

3 0x36服务肯定响应消息

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

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

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

5 示例：0x36 TransferData服务消息流

结尾

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

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

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

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

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

服务

SID

描述

TransferData

传输数据       

0x36

client向server发送数据（download下载）或从server请求数据（upload上传）。

1 $0x36 TransferData诊断服务描述

TransferData服务被client用来从client向server（download下载）或从server向client（upload上传）传输数据。

数据传输方向由前面的RequestDownload或RequestUpload服务定义。如果client发起RequestDownload，要下载的数据将包括在TransferData请求消息的参数transferRequestParameter中。如果client发起了一个RequestUpload，要上传的数据就包括在TransferData响应消息中的参数transferResponseParameter中。

TransferData服务请求包括一个blockSequenceCounter，以便在多个TransferData请求序列中的TransferData服务失败时改进错误处理。当收到RequestDownload (0x34)或RequestUpload (0x35)请求消息时，server的blockSequenceCounter应被初始化为1。这意味着在RequestDownload (0x34)或RequestUpload (0x35)请求消息之后的第一个TransferData (0x36)请求消息以一个blockSequenceCounter为起点。

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

2 0x36服务请求消息

2.1 0x36服务请求消息定义

表403 - 请求消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

TransferData Request SID

传输数据请求SID

M

0x36

TD

#2

blockSequenceCounter

块序列计数器

M

0x00 – 0xFF

BSC

#3

:

#n

transferRequestParameterRecord[] = [

transferRequestParameter#1

:

transferRequestParameter#m ]

C

:

U

0x00 – 0xFF

:

0x00 – 0xFF

TRPR_ TRTP_

:

TRTP_

C = Conditional有条件：如果下载正在进行，该参数是强制性的。

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

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

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

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

定义

blockSequenceCounter块序列计数器

BlockSequenceCounter参数值从RequestDownload(0x34)或RequestUpload(0x35)服务后的第一个TransferData请求的0x01处开始。它的值在每个后续的TransferData请求中都会增加1。当值为0xFF时，blockSequenceCounter会翻转，并在下一个TransferData请求信息中从0x00开始。

用例：

  • 如果一个下载数据的TransferData请求在server中被正确接收和处理，但positive response message没有到达client，那么client将确定一个应用层超时，并将重复相同的请求（包括相同的blockSequenceCounter）。server将收到重复的TransferData请求，并可以根据所包含的blockSequenceCounter来确定这个TransferData请求是重复的。server将立即发送positive response message，而不将数据再次写入其memory中。
  • 如果server没有正确接收到下载数据的TransferData请求，那么server将不会发送positive response message。client将确定应用层超时，并重复相同的请求（包括相同的blockSequenceCounter）。server将收到重复的TransferData请求，并可以根据包含的blockSequenceCounter确定这是一个新的TransferData。server将处理该服务，并将发送positive response message。
  • 如果一个上传数据的TransferData请求被server正确接收和处理，但positive response message没有到达client，那么client将确定应用层超时，并将重复相同的请求（包括相同的blockSequenceCounter）。server将收到重复的TransferData请求，并可以根据所包含的blockSequenceCounter来确定这个TransferData请求是重复的。server将立即发送positive response message，在其内存中再次访问先前提供的数据。
  • 如果server没有正确接收到上传数据的TransferData请求，那么server将不会发送一个positive response message。client将确定应用层超时，并重复相同的请求（包括相同的blockSequenceCounter）。server将收到重复的TransferData请求，并可以根据所包含的blockSequenceCounter来确定这是一个新的TransferData。server将处理该服务并发送positive response message。

transferRequestParameterRecord传输请求参数记录

该参数记录包含server所需的参数，以支持数据传输。该参数的格式和长度由汽车制造商决定。

例子：对于下载，transferRequestParameterRecord包括要传输的数据。

3 0x36服务肯定响应消息

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

表405 - 肯定响应消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

TransferData Response SID

传输数据响应SID

M

0x76

TDPR

#2

blockSequenceCounter

块序列计数器

M

0x00 – 0xFF

BSC

#3

:

#n

transferResponseParameterRecord[] = [

transferResponseParameter#1

:

transferResponseParameter#m ]

C

:

U

0x00 – 0xFF

:

0x00 – 0xFF

TREPR_

TREP_

:

TREP

C = Conditional有条件的：如果上传正在进行，这个参数是强制性的。

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

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

定义

blockSequenceCounter块序列计数器

这个参数是请求信息中blockSequenceCounter参数的回显。

transferResponseParameterRecord传输响应参数记录

该参数应包含client所需的参数，以支持数据的传输。该参数的格式和长度由汽车制造商决定。

例子：对于下载，参数transferResponseParameterRecord可以包括由server计算的校验和。对于上传，参数transferResponseParameterRecord包括上传的数据。对于下载，参数transferResponseParameterRecord不应重复transferRequestParameterRecord的内容。

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

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

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

NRC

描述

助记符

0x13

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

如果消息的长度不对（例如，消息长度不符合requestDownload服务的肯定响应中返回的maxNumberOfBlockLength参数的要求），则应发送该NRC。

IMLOIF

0x24

requestSequenceError请求序列错误

server应使用此响应代码：

-如果收到对该服务的请求时，RequestDownload或RequestUpload服务未被激活；

-如果RequestDownload或RequestUpload服务处于活动状态，但server已经收到由活动的RequestDownlod或RequestUpload服务中的memorySize参数决定的所有数据；

注：server应接受重复传输数据请求消息，该消息的blockSequenceCounter等于前一个传输数据请求消息中包含的blockSequenceCounter。

RSE

0x31

requestOutOfRange请求超出范围

如果出现以下情况，则应返回该NRC：

- TransferRequestParameterRecord包含额外的控制参数（例如额外的地址信息），并且该控制信息无效。

- TransferRequestParameterRecord与requestDownload或requestUpload服务参数maxNumberOfBlockLength不一致。

- TransferRequestParameterRecord与server的memory排列限制不一致。

ROOR

0x71

transferDataSuspended转移数据暂停

如果下载模块的长度不符合requestDownload服务的请求消息中发送的memorySize参数的要求，应返回该NRC。

TDS

0x72

generalProgrammingFailure一般编程失败

如果在下载数据期间，server在erasing擦除或programming编程永久存储设备（如Flash Memory）中的一个memory位置时检测到一个错误，则应返回该NRC。

GPF

0x73

wrongBlockSequenceCounter错误的块序列计数器

如果server检测到blockSequenceCounter的顺序有误，则应返回这个NRC。

注意：server应接受重复TransferData请求消息，其blockSequenceCounter等于前一个TransferData请求消息中包含的blockSequenceCounter。

WBSC

0x92 / 0x93

voltageTooHigh / voltageTooLow电压太高/电压太低

如果在server的主电源引脚上测得的电压超出了将数据下载到server的永久存储器（如Flash Memory）的可接受范围，则应视情况发送该返回代码。

VTH / VTL

评价顺序记录在图28中。

Key

1)如果正在进行RequestUpload（SI + BSC），必须是2、

2)如果正在进行RequestDownload (SI + BSC + 最小TRPR_)，则至少为3。

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

5 示例：0x36 TransferData服务消息流

详见以下博文：

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

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

结尾

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

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

UDS诊断看这篇就够了，吐血整理
04-03 10万+
1 简介与概述 不同诊断通信协议的开发，调整，实施和维护会给车辆制造商，系统供应商和ECU供应商带来不必要的成本。为了解决此问题，将不同的技术协议和数据通信原理编译为一个国际ISO标准，通常称为统一诊断服务（ISO 14229-1）。 UDS ISO 14229-1：2013（UDS）和ISO 15765-3：2004（基于在CAN上的诊断）是互补标准，共同指定“ 基于CAN上的UDS”应用层协.........
汽车UDS诊断详解及Vector相关工具链使用说明——2.6.2 数据传输服务（0x36）
weixin_42967006的博客
06-08 3017
1. 概述 36服务就是用来在诊断仪和ECU之间传输数据的，有两个方向：在下载流程中，是诊断仪发送的请求报文中包含数据，在上传流程中，是ECU返回的肯定响应中包含数据。 36服务必须在34或35服务后开始执行。 在传输数据的时候，因为网络层传输能力大小的限值，大多数情况下要传输的数据都不能用一次请求和响应传输完成，要分成多个36服务来传输，我们通常把每个36服务请求或响应中传输的数据叫做一个数据块。 2. 请求报文格式 36服务的请求报文格式如下： transferRequestParameterRec
UDS-TransferData(传输数据)（0x36）服务
lj__1111的博客
05-13 3520
1、作用：客户端利用传输数据服务从客户端向服务器或从服务器向客户端传输 数据。 2、请求消息定义 A_Data byte Parameter name Cvt Hex value Mnemonic #1 TransferData Request SID M 0x36 TD #2 blockSequenceCounter M 00-FF BSC #3 : #n transferRequestParamet
UDS诊断（ISO14229-1） 36服务
m0_56208280的博客
01-17 7309
36服务，即 TransferData（传输数据）服务，客户端利用 TransferData（传输数据）服务从客户端向服务器（下载）或从服务器向客户端（上传）传输数据。
【车载开发系列】UDS诊断---数据传输（$0x36）
千月星跡
12-19 1094
【车载开发系列】UDS诊断—数据传输（$0x36） UDS诊断---数据传输（$0x36）【车载开发系列】UDS诊断---数据传输（$0x36）一.概念定义二.报文格式1）请求报文2）肯定响应3）否定响应 一.概念定义 数据传输 TransferData（36h） 诊断工具使用此服务从诊断工具到 ECU 传输数据（下载）或者从 ECU 到诊断工具传输数 据（上传）。 在ISO14229当中定义了上传和下载两个部分，但大多数车企都只使用下载功能。 二.报文格式 1）请求报文 BlockSequenceC
UDS服务基础篇之36
wto9109的博客
04-03 2335
继小T前不久系统性的总结了一份80多页的<UDS诊断服务宝典>，获得了非常多的小伙伴的认可与支持，如何免费获取见文末说明。今天小T跟大家介绍剩余部分在刷写过程中常用的36诊断服务。你知道36服务是干什么的吗？36服务是怎样的请求与诊断格式？36服务在使用的过程中需要注意哪些问题？这篇，我们来一起探索并回答这些问题。
【UDS诊断】——0x34、0x36、0x37服务
LOVE135149的博客
08-26 2831
Client端使用Routine Control服务来执行定义的步骤序列并获取特定序列的相关结果。该服务有极大的灵活性。Service31的典型用途可以包括擦除内存、重置定义的数据、覆盖正常服务控制策略以及控制ECU值随时间变化的功能。通过Service31可以启动特定序列、停止运行该特定序列、请求运行结果。该服务以往常用于ECU在做Software Update时，应用于检查刷写条件是否满足、传输数据完整性以及独立性检测。
汽车电子基于ISO14229的ECU刷写架构中重复blockSequenceCounter数据包处理机制设计：确保数据传输鲁棒性和协议合规性
最新发布
04-09
内容概要：本文探讨了车载刷写架构中 ECU 收到相同 blockSequenceCounter 数据包的情况，基于 ISO14229 标准，详细解释了 UDS 诊断服务（特别是 34、36 和 37 服务）在 ECU 刷写过程中的作用。文章重点分析了 ...
UDS诊断ISO14229新手入门篇
weixin_45387165的博客
09-21 1181
这个命令的格式稍微复杂一点。sub-function = 0x06 用于读取某个 DTC 及其相关的环境数据，此时 parameter 为 4 个 byte，前三个 byte 用于标识我们要读取的 DTC，第四个 byte 用于标识要读取的环境数据的范围，UDS 规定使用 FF 来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括 DTC 状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此 DTC 产生时的测量数据。
UDS诊断服务列表.pdf
11-14
UDS（统一诊断服务）是汽车领域中广泛使用的一套标准通信协议，主要用于汽车ECU...了解和运用这些UDS诊断服务是汽车电子技术领域的一个重要部分，它对于诊断车辆故障、程序更新、系统监控以及满足法规要求至关重要。
UDS 官方推荐刷写Firmware流程
yeweiliang_93的博客
02-03 1669
UDS 官方推荐刷写Firmware流程
《UDS协议从入门到精通》系列——图解0x36：数据传输
车载系统攻城狮
10-30 2453
UDS数据上传下载类之0x36-数据传输，图解请求+响应包格式，快速上手！！
UDS34、36服务实例：诊断仪34服务请求下载30字节
qq_45571840的博客
04-25 1037
诊断仪34服务请求下载30字节
UDS 34/36/37 服务
qwe0405080615的博客
02-09 9142
UDS 34/36/37 服务
【ISO14229_UDS_0x36服务详解】
weixin_43722921的博客
08-30 2698
本文介绍了ISO14229_0x36服务(TransferData，数据传输服务)的使用说明。
ISO 14229-3和ISO 15765-3的区别是什么?
热门推荐
microcosmv的博客
07-01 1万+
一，ISO14229的组成 ISO14229第二版即2013版中描述： Item Description Part 1: Specification and requirements Part 2: Session layer services Part 3: Unified diagnostic services on CAN implem...
34/36/37服务（ECU升级数据的传输）
qiu421的博客
09-12 1351
关于ECU升级数据的传输，是通过34（请求下载）、36（传输数据）、37（请求退出传输）这3个服务来完成的。关于升级文件中一个块的传输流程如下（假设正常升级，即没有否定响应的情况）：诊断仪通过34服务传输该块的起始地址、该块的数据长度信息；进行下载请求；ECU收到34服务的下载请求后，通过74肯定响应报文通知诊断仪，其（诊断仪）接下来的每个数据传输的报文中（36服务）应包含多少数据字节。诊断仪则根据该返回的参数对自身的发送能力进行调整；
UDS NRC负响应码
Later equals never
03-06 2098
HEX Name Description 01 ISOSAEReserved ISO 保留，暂时未定义 ... 0F 10 GeneralReject 一般性拒绝。通常在无法准确描述错误时发出 11 serviceNotSupported 服务不支持。多出现在服务未被定义 12 sub-functionNotSupported 子功能不支持。多出现子功能未被定义 13 ncorrectMessageLengthOr
0x36transferData 数据传输
不断debug，优化中……
06-02 734
这意味着RequestDownload（0x34）或RequestUpload（0x35）请求消息后面的第一个TransferData（0x36）请求消息以blockSequenceCounter开头。如果客户端发起请求下载，则要下载的数据包含在TransferData请求消息中的参数transferRequestParameter中。服务器将收到重复的TransferData请求，并可以根。 如果在服务器中没有正确接收到下载数据的TransferData请求，则服务器不会发送肯定的响应消息。
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、付费专栏及课程。

余额充值