Q1、Prepare Bus-Sleep Mode進(jìn)入Network Mode條件

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

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

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

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

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

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

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

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

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

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

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

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

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

Q3：$3E 80發(fā)送時(shí)機(jī)

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

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

如上，討論一種工況：

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

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

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

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

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

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

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



審核編輯：劉清