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超時回到默認會話。
審核編輯:劉清
-
CAN
+關注
關注
57文章
2762瀏覽量
464005 -
網絡管理
+關注
關注
0文章
122瀏覽量
27703 -
上位機
+關注
關注
27文章
944瀏覽量
54908
發布評論請先 登錄
相關推薦
評論