UDS_14229-1中关于刷写(下载&上传)的服务及其NRC详解

总结说明:

说明1:

以下载为例,uds中的下载是指,使用诊断仪或刷写工具,对指定的ECU,传输程序的过程。

刷写过程

1:0x34服务,刷写工具和ECU之间协商,刷写是否可行,即一些关键参数

2:0x36服务,下载数据传输与接收,并校验的过程

3:请求退出刷写流程

说明2:从服务角度整体看

0x34 :指client请求server下载数据的服务,通常用于请求服务器下载APPSoftware软件,传输数据方向:client-->server

0x35:指client请求server上传数据的服务,通常用于请求服务器上传部分数据到client,传输数据方向:server-->client

0x36:即,执行0x34/0x35服务的执行,不过针对不同的服务其具体执行方式存在差异,下文详细说明。

0x37:请求退出上传与下载。

不知道这样理解对不对,大家姑且听一下,类似于捂手建立连接,执行上传与下载,断开连接的过程,类似于TCP连接数据传输。

说明3:从服务PDU角度看

从内容定义上来看,0x34/0x35比较类似:都是在于服务器协商传输数据的格式,长度,地址等信息,服务器也会在报告对应自身的状态,肯定响应中还会包含“能接受最大数据缓存,或能发送的最大数据长度等信息”。否定响应中指示错误原因。

0x36服务主要传输数据;

0x37服务主要是执行停止服务

2:0x34服务

2.1:0x34服务(请求)

#1,0x34服务,长度:1Byte,由client发出,没什么好讲的

#2,数据格式表示符,长度:1Byte,人为的分为两部分,高半字节(规定数据压缩方式),和低半字节(规定数据加密方式)。

高半字节4bit位:

                           0000(bin):表示不压缩

                           0001(bin):表示压缩

                           0010-1110:保留

低半字节4bit

                           0000(bin):表示不加密

                           0001(bin):表示加密

                           0010-1110:保留

整合起来看

                     0x 34 00:表示既不需要压缩,也不需要加密

                     0x 34 10:表示需要压缩,不需要加密

                     0x 34 01:表示不需要压缩,需要加密

                     0x 34 11:表示既需要压缩,需要加密

本人私下记忆位压缩加密标识符这样更好记忆

#3:地址长度格式标识符,1Byte。指示的是存储器地址用几个字节表示,最好的理解可以直接理解为地址指针长度(低半字节),长度是指请求传输BLOCK的大小用几个字节表示(高半字节)。

我个人是按照长度地址格式标识符记忆的(长度对应高半字节,地址对应地址长度)

我们知道不同存储器的地址占用的大小是不一致的,如256Byte的存储器,字节地址从0x00-0xFF即可表示。即一个字节长度的指针,便可以覆盖所有存储单元

1kbyte的存储器,则需要2Byte长度的指针。

传输BLOCK的大小大小(低半字节),存储器大小用几个字节表示

0x34 00 11:表示地址只占用一个字节,存储器大小只用一个字节

最终请求 0x34 00 11 12(存储器地址)15 (传输BLOCK的大小

0x34 00 22 ==0x 34 00 22 00 12 (存储器地址)00 15传输BLOCK的大小

0x34 00 12 == 0x34 00 12  00 12 15

#4:存储器地址 ,字节数m由前一个字节的低4bit决定

存储器地址 获取是从S19,HEX等刷写文件中直接获取的。发送给服务器,表示的是,以该值为起点,刷写,配合后面的存储器大小(也就是刷写BLOCK的长度)

存储器地址的最高有效位,还可以作为存储器的标识符。这是什么意思?当系统存在外置flash存储器或ROM时。为了和内置flash存储器或ROM做区分,最高有效位=00,表示申请写入内置存储器,最高有效位=01,表示写入外置存储器。

2.2 拓展话题:压缩、存储器地址,存储器大小是什么意思?

本人关于压缩了解多一点,加密确实不怎么理解。

先看一个刷写文件(注意需要使用HEXview打开)

 看图标注起来的,

可以看到整个文件被划分为3个Block,每个Block都标注了起始地址,结束地址,和长度

0x34服务的存储器地址:就是对应BLOCK的起始地址。存储器大小就是一个Block的长度

查看刷写报文:以BLOCK1刷写为例

诊断地址: PCI  0x 34 00 44 80 13 80 20(起始地址)00 00 C7 FC 04(长度信息)

2.3:0x34服务(应答)

**1)肯定响应:

连接完,0x34请求报文,我们看0x34服务的肯定应答

诊断地址:单帧指示+报文长度(PCI,一个字节) 74  20(指示能接收0x36服务的字节长度,占用的字节数)02 FF(块长度)

其中20 也同样的分为高半字节,和低半字节。高半字节指示‘指示能接收0x36服务的字节长度,占用的字节数’。低半字节,全部置0。

02 FF 是指示了接下来的0x36服务,一次能发送的最大长度。

**2)否定响应:

7F 34 NRC,出现否定应答时,表明服务器不支持请求下载的服务

支持的NRC如下图所示:

其中

22 表示服务器,在接收0x36服务发送来的数据,或校验数据时,再次接收到新的0x34(请求下载的服务,就会发送此NRC代码),表明下载不会被新的请求中断。

31 表示  0x34 后面的4个参数,至少存在一个无效的情况。这些参数是否支持,需要在程序中配置好,当服务器接收到0x34服务后,会分析这些参数,如果这些参数被服务器认定为不合格,则返回此NRC

70:暂时我也不知道是指啥?

段落小结:

*1)0x34服务是根据Block来划分的,一个Block就要对应一个0x34的请求与响应,下一个Block,就要开启一个新的0x34服务

**2)0x34服务,也是为了接下来的0x36(请求数据传输),服务的,协商好后。0x36服务直接使用0x34服务,已经协商好的协议和参数,进行传输工作。

3:0x36服务

3.1 0x36服务请求报文

基于0x34服务,我们已经知道0x34服务,已经将数据格式(压缩与否,加密与否),数据地址,数据长度,0x36服务能够发送最大长度都已经定义好!

于是0x36,就在0x34的基础上,只管数据发送即可

0x36服务请求报文格式

关注,第二个参数,块计数器,循环规则01-FF,再从00-FF.这一点上倒是和网络层的CF编号,有点异曲同工之处,也不知道是出于什么样的考虑。

3.2 0x36应答

肯定响应

重点图中这段话,包含一个校验和,那么这段校验和,是几个字节,采用什么样的算法,这些都由汽车制造商定义。

ECU在接收到这个校验和后,会对数据应用同样的方法进行计算,如果数据正确,则返回0x36的正响应,否则则根据下表给出负响应。

肯定响应,还有几种比较特殊的情况。

**状态1)重传状态

当0x36服务全部发送完成后,如果刷写工具,没有及时收到,肯定或否定响应请求。则刷写工具会自动重发上一次的0x36服务,Block参数和传送的数据和上一次传送一致。

此时根据服务器,是否已经正确接收0x36数据,会选择不同的肯定应答策略。

1:ECU已经正确接收数据,且校验值,正确,只是没来的及及时发出肯定响应。那么此时ECU将会在接收到的第一帧后,立即发送一个肯定响应。

2:ECU确实,没有接收到正确的数据,则ECU则会,正常的接收所有数据,之后按照正常逻辑发送一帧肯定响应报文。

否定响应

*1NRC:0x13)

NRC1:0x36服务的NRC响应码,与其他的服务还有点不一样。其他服务基本都是在接收完所有报文信息后(包括续帧的最后一帧),然后计算接收实际报文数量,与请求报文N_PCI中报文长度是否一致。(注意这里的细节,在计算报文长度时,续帧中的N_PCI,也就是续帧的第一个Byte,是不包含在总长度中的)。

0x36服务有一个比较特殊的地方,当0x34肯定响应的最后两个字节,是0x01 FF,表明服务器最大能接收511(10进制)个Byte的数据。

此时如果0x36服务发送首诊=  诊断ID: 12  00 36 01 XX XX XX .......N_PCI中的报文长度是0x 200

是>0x 1 FF 的,则此请求也要回复否定响应0x13。

思考题1:我们知道通常情况下,只有接收完全部的帧数据后,才会返回0x13,0x36服务是否也一样?

答:是一致的,也是报文数据全部接收后返回NRC 0x13

思考题2:多帧请求报文中,如果ECU返回的流控阵首字节 返回0x32,表示缓存溢出。这和0x36服务中的NRC 0x13有没有区别。

答:区别大了,流控帧中的0x32,是指硬件层面,或者说是网络层,设置的一个缓存器,缓存器,最大容量比如是4000Byte,但是发出的首诊N_PCI指示的长度为4090Byte。则此时在首诊发出后,则返回的流控帧,指示内存溢出。

*2NRC:0x24)

触发状态,没有发送0x34/0x35的情况下,直接发送0x36,则返回此NRC,此处还有一个知识点

当0x36服务特定时间内,没有收到肯定响应时。会重传一遍,此时不能认为是

*3NRC:0x31)

触发条件,比如首诊0x36报文,后的Block是0x05,此时就会报NRC:0x31

*4NRC:0x71)

传送数据挂起
须发送该返回代码若:
该响应代码指明由于错误数据传送操作被叫停。
2) 下载模块长度与 请求下载 服务请求报文发送的 memorySize 参数的要求不符。

前提条件:0x34服务确定了memorySize = 00 00 00 FF

但是,实际上0x36,服务只发送了0x33个数据,则会触发该NRC,此时说明刷写工具,对HEX

,S19文件解析或发送程序出现错误。

这个NRC算是0x36服务一个独有的NRC,

*5NRC:0x72)

一般性编程错误
发送该返回代码若下载数据期间服务器在擦除或编程永久存储器设备(如 Flash 存储器)
的存储单元时检测到错误。

*6NRC:0x73)

错误的块顺序计数器
若服务器ECU 检测到 blockSequenceCounter 的顺序错误,则发送该返回代码。 若TransferData
的重复请求报文块顺序计数器等于先前TransferData 请求报文的,则ECU不会报出此NRC。

*7NRC 92/93

编程电压,过高(92)或过低(93)。一定要注意这里不是指ECU设计过程中人为定义的:高压,低压,过压和欠压。而是指下载时,存储器在写入数据时,允许的最大和最小的电压。具体的值需要查阅相关芯片手册

段落小结:

4:0x37服务

请求传送退出 (37 hex) 服务,一般没有额外参数,结构如下图,也很简单
### 回答1: iso-14229是一项用于汽车电子系统通信的协议,其全称为ISO14229 Unified Diagnostic Services(UDS)on Controller Area Network(CAN)。该协议旨在为车辆的诊断、维护和修复提供标准化的方法。ISO 14229定义了诊断服务和通信的标准化消息格式,包括诊断数据、错误码、故障清除等,以使不同车辆的系统实现得到统一和互操作性。 ISO14229 UDS协议栈是用于实现ISO 14229诊断协议的软件组件。该协议栈的实现可分为物理层和软件层两个部分,其物理层是指使用CAN总线对车辆的执行单元进行通信,而软件层则是指实现ISO 14229标准的协议堆栈。该协议栈具有标准化、可重用和可配置的特点,可在不同的客户平台上使用。 ISO 14229的文档是对该协议的规范和说明,包括协议的基本架构、消息格式、错误码表、会话层和传输层的细节等。该文档是实现ISO 14229协议的必要依据,可用于开发UDS协议栈的开发人员和车辆诊断工程师。 源码.zip则是UDS协议栈的实现源代码,包括物理层和软件层代码。开发人员可根据该源码了解UDS协议栈的实现细节和技术实现,并根据需求进行二次开发。 综上所述,ISO-14229_14229_UDS协议栈_UDS-ISO-14229_ISO14229文档_ISO 14229_源码.zip等组件,是用于实现汽车电子系统诊断的标准化协议,可为车辆的维护和修复提供规范的方法。开发人员和车辆诊断工程师可根据这些组件进行UDS协议栈的开发和实现。 ### 回答2: ISO-14229是用于诊断汽车电子控制单元(ECU)的标准协议。该协议旨在提供一种标准化的方法,让技术人员可以使用相同的工具和流程诊断不同制造商的汽车。 14229 UDS是该标准的通信协议栈。UDS指协议栈定义的通用诊断服务,该服务可用于访问ECU的内部数据和状态。ISO14229文档提供了UDS协议栈的详细规范,以及相关的数据格式和命令集合。 此外,文档和源代码可以帮助工程师实现符合ISO-14229标准的诊断工具或ECU,提高汽车诊断系统的质量和效率。源码.zip则是UDS协议栈的代码包。 总之,ISO-14229标准和UDS协议栈提供了一种标准化的、可靠的汽车诊断协议。它们有助于提高汽车技术人员的工作效率,同时减少汽车诊断工具和软件的开发成本。 ### 回答3: ISO-14229是一种用于汽车电子系统的通讯协议。它定义了诊断通信的规范和协议,允许车辆厂商和供应商使用这些规范和协议来开发和测试车载电子控制单元。其UDS协议栈是实现ISO-14229的关键技术之一,能够为客户端提供远程访问ECEs的可能性。 ISO-14229规定了接口:UDS(Unified Diagnostic Service),用于与电子控制单元(ECU)之间进行通讯。 UDS协议栈则实现了UDS协议的接口,可以自动进行诊断和测试,发生故障时还能产生错误报告。 相应地, ISO14229文档描述了在ISO14229-1文档定义的UDS协议的特定应用,与ISO15765-2的特定要求相结合。 它还包括了EVITA Light文档的安全方面。 源码.zip文件则包含了UDS协议栈的源代码,可以在开发与应用使用,实现对汽车电子控制单元的简便对话操作。 总之,ISO-14229及其UDS协议栈实现了车载控制电子单元的标准化通讯,可简化车辆诊断和维护过程,提高效率和可靠性。同时,相应的规范、文档和源代码也为相关人员提供了方便和支持。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值