夜雨聆风之前ECU软件刷写过程中遇到过一个问题：测试人员用测试设备给某个ECU进行单件软件刷写测试时，为了保持ECU的非默认会话，他设置了2S间隔周期发送3E 80指令。但在36服务进行软件包下载时，出现了刷写中断的问题。
看了报文发现，原来他设置的3E 80指令不是用功能寻址诊断ID，而是用的被刷写ECU的物理寻址诊断ID。导致在ECU进行多帧数据接收时，被中途插入的物理寻址的单帧给打断了。改为功能寻址发送3E 80，问题就解决了。
那么多帧传输过程中都什么情况下会被打断呢？多帧传输的问题对软件刷写过程还是非常重要的，今天我们来探讨下。
在这之前，先书接上文，聊下DoCAN网络层时间参数及其超时行为。
网络层时间参数值
ISO15765-2中对网络层时间参数推荐值如下：
其中超时时间是该参数允许的最大值，参数计时器超过此值即认为参数超时。
网络层时间参数超时原因和行为
N_As超时
原因：发送方的数据链路层没有在规定时间内完成数据帧的发送（包括单帧、首帧、连续帧）。
行为：中止后续数据发送。
N_Ar超时
原因：接收方的数据链路层没有在规定时间内完成数据帧的发送（包括流控帧）。
行为：中止后续数据发送。
N_Bs超时
原因：发送方的网络传输层没有收到来自数据链路层的流控帧；或者接收方的网络传输层没有收到先前来自数据链路层的首帧。
行为：中止后续数据发送。
N_Cr超时
原因：接收方的网络传输层没有收到来自数据链路层的连续帧；或者发送方的网络传输层没有收到先前来自数据链路层的流控帧。
行为：中止后续数据接收。
接收到非预期数据后的行为
前面我们已经讨论了正常情况下单帧传输和多帧传输的数据发送流程，多帧传输中又包含首帧、流控帧、连续帧的固定顺序。
那么如果在多帧传输的过程中，发送方或接收方又意外接收到不符合正常顺序的N_PDU（N_PDU即之前说过的网络层的协议数据单元），该如何处理，会不会将正在传输的多帧数据全都破坏呢？下面我们看下ISO 15765-2中是如何要求的。
这里我们以被诊断ECU的角度来说。在诊断过程中，被诊断ECU有可能是多帧数据的接收方（比如软件刷写传输数据包时），也有可能是多帧数据的发送方（比如诊断仪读ECU软件版本号，且软件版本号较长需要多帧反馈时），当然也有可能此时没有进行多帧数据的发和收，其网络传输层处于空闲状态。因此ECU网络传输层有以下3种状态。
注：下面所说半双工和全双工单指CAN/CANFD ECU的网络传输层，配置为全双工的状态下，能同时支持多帧数据的接收和多帧数据的发送而互不干扰。
①ECU正在进行多帧数据发送时
接收到单帧N_PDU：忽略（半双工）；正常接收单帧，且不影响当前多帧的发送（全双工）。
接收到首帧N_PDU：忽略（半双工）；正常接收首帧并准备开始多帧数据的接收，且不影响当前多帧的发送（全双工）。
接收到连续帧N_PDU：忽略（半双工）；如果同时正在进行多帧数据的接收，参考下面要求（全双工）。
接收到流控帧N_PDU：忽略。
接收到未知的N_PDU：忽略。
②ECU正在进行多帧数据接收时
接收到单帧N_PDU：中断当前的多帧数据接收，开始处理新接收到的单帧数据。
接收到首帧N_PDU：中断当前的多帧数据接收，开始处理新接收的首帧，并准备开始新多帧数据的接收。
接收到连续帧N_PDU：正常接收，但需要检查连续帧中的SN编号是否正确。
接收到流控帧N_PDU：忽略（半双工）；如果同时正在进行多帧数据的发送，参考上面要求（全双工）。
接收到未知的N_PDU：忽略。
③ECU网络传输层处于空闲状态时
接收到单帧N_PDU：正常接收单帧。
接收到首帧N_PDU：正常接收首帧并准备开始多帧数据的接收。
接收到连续帧N_PDU：忽略。
接收到流控帧N_PDU：忽略。
接收到未知的N_PDU：忽略。
另外，针对功能寻址，功能寻址不允许发送多帧数据，ECU在多帧传输过程中接收到非预期的功能寻址的单帧数据时，应该忽略。
----------------------------------------------
欢迎点击下方链接查看往期精彩合集文章，谢谢关注~
点击下方合集，查看当前合集中更多文章~
