25:NRC78 表示请求报文被正确接收到,请求报文中所有的参数均是有效的,诞生所执行的动作未完成, ECU还未准备好接收另一个请求,返回否定响应 NRC=0x78,同时启动一个定时器,在 P2*Server 的时间后给予答复。如果动作完成回复响应结果,未完成且 P2*Server 到时后,继续返回否定响 NRC=0×78,并重启定时器。 注意: ...
requestCorrectlyReceived-ResponsePending (NRC78) 这个NRC表明请求消息被正确接收,并且请求消息中的所有参数都是有效的(如果执行引导软件,这些检查可以延迟到发送这个NRC之后),但是要执行的操作尚未完成,服务器还没有准备好接收另一个请求。一旦请求的服务被完成,服务器将发送一个积极的响应消息或一个与此不同的响应代...
请求的服务是功能寻址时,NRC为:服务不支持(0x11),当前会话服务不支持(0x7F),子功能不支持(0x12),当前会话子功能不支持(0x7E),请求超出范围(0x31),不管SPRMIB是否置位,都不会回复NRC。但前提是没有回复NRC 0x78的情况下。括号里面那句话很重要 也就是说,如果请求的是功能寻址,且NRC是上面5个中的任意一个...
当NRC 0x78被使用了,服务端最终都要给一个响应(正响应或否定响应),和SPRMIB的值是否置位无关,和是否是功能寻址,且NRC为0x11,0x7F,0x12,0x7E,0x31无关。 简单来说就是: 1)当服务端回复了NRC 0x78,即使SPRMIB是置位的也要回复正响应; 2)当服务端回复了NRC 0x78,即使发送的请求是功能寻址,且NRC为0x...
这里再讲一个NRC 0x78的,原文如下: 当NRC 0x78被使用了,服务端最终都要给一个响应(正响应或否定响应),和SPRMIB的值是否置位无关,和是否是功能寻址,且NRC为0x11,0x7F,0x12,0x7E,0x31无关。 简单来说就是: 1)当服务端回复了NRC 0x78,即使SPRMIB是置位的也要回复正响应; ...
0x78:已收到请求,但会晚点响应。 0x7E:当前会话下,该子功能不支持。 0x7F:当前会话下该服务不支持。 0x92:电压过高。 0x93:电压过低。 2️⃣ NRC码的优先级: 诊断服务的NRC优先级是指在不同情况下,诊断服务返回的否定响应代码(NRC)的优先级。在实际使用中,NRC的优先级对于诊断服务的正确执行非常重要。
首先Tester请求ECU进入编程回话(Programming session),但不希望ECU给出肯定响应。但是进入编程回话通常需要ECU复位,重新启动后进入Bootloader。这个过程所需要的时间会超过P2CAN_Server (通常为50ms)。所以ECU会先给出NRC为0x78的否定响应,用以通知Tester诊断请求已经正确接收了,正在处理,稍后给出响应。
b)P2*Client:诊断工具接收到 NRC 0x78 之后继续等待 ECU 响应的时间间隔 c)P2Server_max:ECU 在收到请求和给出响应之间的这个时间间隔,它描述了ECU 的反应速度,通常最大值为50ms d)P2* Server_max:ECU 发送 NRC 0x78 之后继续发送 下帧诊断响应报文的时间间隔 ...
P2* Client:诊断工具接收到 NRC 0x78 之后继续等待 ECU 响应的时间间隔。 P2Server_max :ECU 在收到请求和给出响应之间的这个时间间隔,它描述了ECU 的反应速度,通常最大值为50ms。 P2* Server_max:ECU 发送 NRC 0x78 之后继续发送 下帧诊断响应报文的时间间隔。
UDS诊断时间参数来源于行业标准的协议文档:ISO15765和ISO14229,除非客户自定义修改,否则基本是协议文档上默认的数值。 1 应用层时间参数 P2 Client:诊断工具成功发送诊断报文请求之后,等待ECU回复诊断响应的时间间隔。 P2* Client:诊断工具接收到 NRC 0x78 之后继续等待 ECU 响应的时间间隔。