Q1、Prepare Bus-Sleep Mode進入Network Mode條件

A1：CAN網(wǎng)絡管理中，Prepare Bus-Sleep Mode進入Network Mode可以通過三種方式，如下所示：

由CanNm_RxIndication()方式進入，即：在PBSM（Prepare Bus-Sleep Mode）下收到網(wǎng)絡管理報文方式進入；

由CanNm_PassiveStartUp()方式進入。調(diào)用CanNm_PassiveStartUp()接口，表明網(wǎng)絡需要被動喚醒，收到網(wǎng)絡管理報文也屬于被動接收，和CanNm_RxIndication()方式進入不一樣嗎？這里說一下個人理解：在PBSM模式下，ECU依然有接收報文的能力，如果接收到NM Msg，可以通過CanNm_RxIndication()接收，喚醒網(wǎng)絡；如果收到特定的應用報文（比如：包含KL15信號的應用報文）或者診斷報文，也想把網(wǎng)絡喚醒，顯然非網(wǎng)絡管理報文不會通過CanNm_RxIndication()接口接收，如果想讓非網(wǎng)絡管理喚醒網(wǎng)絡，此時就可以讓上層主動調(diào)用CanNm_PassiveStartUp()接口，進而喚醒網(wǎng)絡；

由CanNm_NetworkRequest()方式進入，同CanNm_PassiveStartUp()方式，此方式也屬于上層請求行為。不同于CanNm_PassiveStartUp()方式，此方式表明當前節(jié)點需要通信，需要主動喚醒網(wǎng)絡。比如前面提到的一種情況：VFC置位時，即可主動調(diào)用CanNm_NetworkRequest()接口進入RMS狀態(tài)。

Q2：CAN DLC與實際發(fā)送數(shù)據(jù)長度關系

A2：DLC（Data Length Code），一幀CAN報文中，發(fā)送數(shù)據(jù)的長度，用4個Bit表示。

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

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

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

注意：假設傳輸一個ClassicalFrame，雖然總線只傳輸4 byte數(shù)據(jù)，但是CAN模塊消耗的硬件資源（RAM），實際是8 byte（eg：tc3xx）。

發(fā)送一幀CAN報文，對應一個Tx Buffer Element，在Tx Buffer Element中，根據(jù)發(fā)送CAN報文的類型決定消耗的DB（Data Buffer）大小，如下所示：

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

什么意思呢？就是在硬件配置階段，即使配置DLC = 4，但是一幀CAN報文也必須消耗8 byte的硬件RAM資源。而數(shù)據(jù)發(fā)送到總線時，只發(fā)送4 byte的數(shù)據(jù)。

Q3：$3E 80發(fā)送時機

A3：$3E 80的主要作用在于維持節(jié)點的會話狀態(tài)，即：將節(jié)點維持在非默認會話。工程中，基于UDS軟件升級過程中，Tester或者Gateway節(jié)點會使用功能尋址周期性發(fā)送$3E 80。何時發(fā)送$3E 80更合適呢？

本文主要想討論$36服務過程中，何時發(fā)送$3E 80更恰當。軟件升級過程中，一個$36 Block會發(fā)送大量數(shù)據(jù)，即：多幀傳輸，在多幀傳輸?shù)倪^程中，發(fā)送一個$3E 80是否可行？答：可以，但是會帶來風險。為什么這樣說呢？多幀傳輸過程，一般使用物理尋址，針對特定節(jié)點升級，在多幀傳輸?shù)倪^程中，發(fā)送一幀功能尋址的$3E 80，且中斷接收，如果處理3E 80的中斷例程耗時過多，導致連續(xù)幀會被延遲處理，連續(xù)幀被延時時間過長會導致接收丟幀的問題，即：下一個連續(xù)幀覆蓋被延時處理的連續(xù)幀。以500Kbps通信的經(jīng)典CAN為例，如果允許上位機/Gateway節(jié)點連續(xù)發(fā)送，1ms內(nèi)可以發(fā)送三幀報文，也就是說：如果接收端沒有在300us左右的時間內(nèi)處理完連續(xù)幀，就可能會導致連續(xù)幀覆蓋的問題，即：接收端接收丟幀。

如上，討論一種工況：

t0時刻，接收端中斷收到$2A XxXx...（接收完成），進入中斷例程處理$2A XxXx...數(shù)據(jù)（主要是通知上層Copy數(shù)據(jù)）；

t1時刻，接收端中斷收到$3E 80，進入中斷例程處理3E 80數(shù)據(jù)；

t2時刻，接收端中斷收到連續(xù)幀$2BXxXx...，由于同一中斷（均是接收中斷，優(yōu)先級一樣）正在執(zhí)行，2BXx Xx...數(shù)據(jù)暫時不能處理；

t3時刻，3E 80數(shù)據(jù)處理完成，同時收到連續(xù)幀$2CXx Xx...，如果$2BXx Xx...和$2CXx Xx...使用同一個硬件緩存區(qū)，會導致連續(xù)幀$2CXx Xx...覆蓋連續(xù)幀$2BXxXx...的工況。所以，為避免接收丟幀，接收緩存區(qū)一般會配置多一些，一般工程中會將資源全部使用或者用FIFO方式接收。

理想工況，這種連續(xù)幀插入3E 80的行為不會出現(xiàn)問題(中斷例程不要處理大量邏輯），但在工程實際中，偶爾會遇到并行發(fā)送功能尋址$3E 80，導致連續(xù)幀發(fā)送問題的Bug。

一般在處理多幀發(fā)送過程中，如果上位機或者Gateway節(jié)點發(fā)送功能尋址的$3E 80，會選擇在連續(xù)幀結束時（發(fā)送完最后一幀連續(xù)幀）發(fā)送。

注意：需求中，有時會約束$36服務的P4 server_max為5000ms，即：只允許接收節(jié)點（Server）回復一個NRC0x78，為什么呢？如果S3超時時間設置為5000ms，且$3E 80放在連續(xù)幀的最后發(fā)送，當前Block傳輸用時接近5000ms，如果再不發(fā)送一幀$3E 80，則其他節(jié)能可能會因S3超時回到默認會話。



審核編輯：劉清