CAN DLC与实际发送数据长度有何关系

Q1、Prepare Bus-Sleep Mode进入Network Mode条件

A1：CAN网络管理中，Prepare Bus-Sleep Mode进入Network Mode可以通过三种方式，如下所示：

由CanNm_RxIndication()方式进入，即：在PBSM（Prepare Bus-Sleep Mode）下收到网络管理报文方式进入；

由CanNm_PassiveStartUp()方式进入。调用CanNm_PassiveStartUp()接口，表明网络需要被动唤醒，收到网络管理报文也属于被动接收，和CanNm_RxIndication()方式进入不一样吗？这里说一下个人理解：在PBSM模式下，ECU依然有接收报文的能力，如果接收到NM Msg，可以通过CanNm_RxIndication()接收，唤醒网络；如果收到特定的应用报文（比如：包含KL15信号的应用报文）或者诊断报文，也想把网络唤醒，显然非网络管理报文不会通过CanNm_RxIndication()接口接收，如果想让非网络管理唤醒网络，此时就可以让上层主动调用CanNm_PassiveStartUp()接口，进而唤醒网络；

由CanNm_NetworkRequest()方式进入，同CanNm_PassiveStartUp()方式，此方式也属于上层请求行为。不同于CanNm_PassiveStartUp()方式，此方式表明当前节点需要通信，需要主动唤醒网络。比如前面提到的一种情况：VFC置位时，即可主动调用CanNm_NetworkRequest()接口进入RMS状态。

Q2：CAN DLC与实际发送数据长度关系

A2：DLC（Data Length Code），一帧CAN报文中，发送数据的长度，用4个Bit表示。

对于Classical Frame，DLC的长度有效范围为0~8，对应的发送数据长度为0~8 bytes，如果DLC长度≥8，则发送数据长度为8 byte。

对于FD frame，DLC不仅可以等于0~8，还可以等于9~F，对应的数据长度分为12、16、20、24、32、48、64。如下所示：

对于Classical Frame，如果设置DLC = 4，实际在总线上传输的数据长度是4 byte还是8 byte?答：4 byte。虽然可以这样设置，但是工程实际中，很少这样用，一帧报文只传输4个数据或者更少，会降低有效数据负载，效率低。

注意：假设传输一个Classical Frame，虽然总线只传输4 byte数据，但是CAN模块消耗的硬件资源（RAM），实际是8 byte（eg：tc3xx）。

发送一帧CAN报文，对应一个Tx Buffer Element，在Tx Buffer Element中，根据发送CAN报文的类型决定消耗的DB（Data Buffer）大小，如下所示：
 

一帧CAN报文消耗多大的DB呢？DB空间的消耗，由TXESC.TBDS决定，因此，DB最小需要8 byte。如下所示：

什么意思呢？就是在硬件配置阶段，即使配置DLC = 4，但是一帧CAN报文也必须消耗8 byte的硬件RAM资源。而数据发送到总线时，只发送4 byte的数据。

Q3：$3E 80发送时机

A3：$3E 80的主要作用在于维持节点的会话状态，即：将节点维持在非默认会话。工程中，基于UDS软件升级过程中，Tester或者Gateway节点会使用功能寻址周期性发送$3E 80。何时发送$3E 80更合适呢？

本文主要想讨论$36服务过程中，何时发送$3E 80更恰当。软件升级过程中，一个$36 Block会发送大量数据，即：多帧传输，在多帧传输的过程中，发送一个$3E 80是否可行？答：可以，但是会带来风险。为什么这样说呢？多帧传输过程，一般使用物理寻址，针对特定节点升级，在多帧传输的过程中，发送一帧功能寻址的$3E 80，且中断接收，如果处理3E 80的中断例程耗时过多，导致连续帧会被延迟处理，连续帧被延时时间过长会导致接收丢帧的问题，即：下一个连续帧覆盖被延时处理的连续帧。以500Kbps通信的经典CAN为例，如果允许上位机/Gateway节点连续发送，1ms内可以发送三帧报文，也就是说：如果接收端没有在300us左右的时间内处理完连续帧，就可能会导致连续帧覆盖的问题，即：接收端接收丢帧。
 

如上，讨论一种工况：

t0时刻，接收端中断收到$2A XxXx...（接收完成），进入中断例程处理$2A XxXx...数据（主要是通知上层Copy数据）；

t1时刻，接收端中断收到$3E 80，进入中断例程处理3E 80数据；

t2时刻，接收端中断收到连续帧$2B XxXx...，由于同一中断（均是接收中断，优先级一样）正在执行，2B Xx Xx...数据暂时不能处理；

t3时刻，3E 80数据处理完成，同时收到连续帧$2C Xx Xx...，如果$2B Xx Xx...和$2C Xx Xx...使用同一个硬件缓存区，会导致连续帧$2C Xx Xx...覆盖连续帧$2B XxXx...的工况。所以，为避免接收丢帧，接收缓存区一般会配置多一些，一般工程中会将资源全部使用或者用FIFO方式接收。

理想工况，这种连续帧插入3E 80的行为不会出现问题(中断例程不要处理大量逻辑），但在工程实际中，偶尔会遇到并行发送功能寻址$3E 80，导致连续帧发送问题的Bug。

一般在处理多帧发送过程中，如果上位机或者Gateway节点发送功能寻址的$3E 80，会选择在连续帧结束时（发送完最后一帧连续帧）发送。

注意：需求中，有时会约束$36服务的P4 server_max为5000ms，即：只允许接收节点（Server）回复一个NRC0x78，为什么呢？如果S3超时时间设置为5000ms，且$3E 80放在连续帧的最后发送，当前Block传输用时接近5000ms，如果再不发送一帧$3E 80，则其他节能可能会因S3超时回到默认会话。



审核编辑：刘清