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表示。

對于ClassicalFrame，DLC的長度有效范圍為0~8，對應的發送數據長度為0~8 bytes，如果DLC長度≥8，則發送數據長度為8 byte。

對于FD frame，DLC不僅可以等于0~8，還可以等于9~F，對應的數據長度分為12、16、20、24、32、48、64。如下所示：

對于ClassicalFrame，如果設置DLC = 4，實際在總線上傳輸的數據長度是4 byte還是8 byte?答：4 byte。雖然可以這樣設置，但是工程實際中，很少這樣用，一幀報文只傳輸4個數據或者更少，會降低有效數據負載，效率低。

注意：假設傳輸一個ClassicalFrame，雖然總線只傳輸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時刻，接收端中斷收到連續幀$2BXxXx...，由于同一中斷（均是接收中斷，優先級一樣）正在執行，2BXx Xx...數據暫時不能處理；

t3時刻，3E 80數據處理完成，同時收到連續幀$2CXx Xx...，如果$2BXx Xx...和$2CXx Xx...使用同一個硬件緩存區，會導致連續幀$2CXx Xx...覆蓋連續幀$2BXxXx...的工況。所以，為避免接收丟幀，接收緩存區一般會配置多一些，一般工程中會將資源全部使用或者用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超時回到默認會話。



審核編輯：劉清