前言

汽車工程師對CAN收發(fā)器應該都比較熟悉，但是最近在復盤AUTOSAR架構下的CanTrcv模塊的時發(fā)現(xiàn)對CAN收發(fā)器及CanTrcv模塊還有幾個疑問：

（1）CanTrcv_SetOpMode被哪個模塊調用，在什么場景下調用？

（2）CanTrcv和EcuM的關系，在什么場景下CanTrcv會調用？

（3）不同類型的Can收發(fā)器主要使用場景是？

本文我們來一起探索并回答這些問題。

正文

1.CanTrcv_SetOpMode被哪個模塊調用，在什么場景下調用？

1.1 CanSM模塊切換CanTrcv模塊狀態(tài)

CanTrcv模塊在上電后的初始狀態(tài)配置，一般配置初始狀態(tài)為SLEEP狀態(tài)。而后，CanTrcv模塊的狀態(tài)通過其他模塊調用CanTrcv_SetOpMode來切換。如果沒有BswM的參與（Action中切換CanTrcv狀態(tài)），一般都是CanSM模塊調用CanIf_SetTrcvMode --> CanTrcv_SetOpMode來切換CanTrcv模塊的狀態(tài)。

CanSM的CANSM_BSM_S_PRE_NOCOM和CANSM_BSM_S_PRE_FULLCOM兩個狀態(tài)會調用

CanIf_SetTrcvMode切換CanTrcv模塊的狀態(tài)。

CANSM_BSM_S_PRE_NOCOM的子狀態(tài)CANSM_BSM_DeInitPnNotSupported會調用CanIf_SetTrcvMode將CanTrcv切換到Normal狀態(tài)后又立馬切換到StandBy狀態(tài)（Note: 不知道為啥有這個操作？）。

在CANSM_BSM_S_NOCOM狀態(tài)下如果檢查到有來自COM模塊的通信請求（T_FULL_COM_MODE_REQUEST）后會切換到CANSM_BSM_PRE_FULLCOM狀態(tài)，然后調用CanIf_SetTrcvMode將CanTrcv模塊狀態(tài)切換到NORMAL狀態(tài)。

1.2 BswM的Action切換CanTrcv模塊的狀態(tài)

如果CanSM對CanTrcv的模式狀態(tài)管理不能滿足項目實際的需求，我們可以通過BswM設計在滿足特定條件下調用CanTrcv_SetOpMode來快速切換CanTcv模式狀態(tài)。

1.3 EcuM的Callout函數(shù)中切換CanTrcv模塊的狀態(tài)

EcuM通過中斷或輪詢檢測到來自CAN收發(fā)器或控制器的喚醒事件后，就可以對該喚醒事件進行驗證。EcuM通過打開相應的CAN收發(fā)器和控制器來實現(xiàn)喚醒事件驗證。EcuM模塊調用集成代碼EcuM_StartWakeupSource來打開相應的CAN收發(fā)器和控制器。

注意：雖然控制器和收發(fā)器已打開，但CAN接口模塊（CanIf）不會將CAN消息轉發(fā)到任何上層模塊。只有當CanIf對應的PDU通道模式設置為“在線”時，才會轉發(fā)CAN消息。

ECU狀態(tài)管理器模塊將通過通信管理器模塊ComM繼續(xù)正常啟動CAN網絡。否則，它將調用EcuM_StopWakeupSources關閉CAN控制器和收發(fā)器。

2.CanTrcv和EcuM的關系，在什么場景下CanTrcv會調用EcuM_SetWakeupEvent?

在回答這個問題前，先介紹一下ECU系統(tǒng)設計相關的一些知識。

ECU在設計時根據(jù)具體需求可以在硬件上添加SBC或無SBC。如果ECU有SBC，ECU就是一個斷電系統(tǒng)。那么ECU在系統(tǒng)下電（Shutdown）流程的最后一步會調用SBC的服務接口斷掉MCU的電，整個MCU在休眠中是處于斷電狀態(tài)的。在外部信號（Can Transceiver/Lin Transceiver的INH引腳，Dio喚醒引腳 ）喚醒MCU時，SBC重新給MCU供電，MCU重新冷啟動。

如果ECU無SBC，ECU就是一個深度休眠系統(tǒng)。那么ECU在系統(tǒng)下電（Shutdown）流程的最后一步會調用MCU的服務進入到Deep Sleep深度休眠狀態(tài)（MCU陷入深度休眠狀態(tài)，程序不在運行，但是MCU還有電存在）。在外部信號（Can Transceiver/Lin Transceiver的INH引腳，Dio喚醒引腳 ）通過中斷喚醒MCU，MCU被喚醒后，程序可以選擇軟件復位，整個軟件重新運行，也可以選擇從上次停止的地方接著運行。

如果是深度休眠系統(tǒng)且ECU被喚醒后接著跑的話，我們可以通過配置（EcuM中enable sleep support，EcuM實現(xiàn)EcuM_EnbaleWakeupSource集成代碼，中斷函數(shù)中調用EcuM_CheckWakeup）最后在CanTrcv_CheckWakeup函數(shù)中調用EcuM_SetWakeupEvent來實現(xiàn)喚醒源檢測。

如果是斷電系統(tǒng)或者深度休眠系統(tǒng)被喚醒后軟件復位，那么上圖的整個交互過程就不存在了。程序重啟后需要在其他設計的模塊（CDD_WKSM）開啟喚醒源檢測，如果檢測到喚醒源就需要調用EcuM_SetWakeupEvent來設置喚醒源事件。

問題：CanTrcv和EcuM的關系，在什么場景下CanTrcv會調用EcuM_SetWakeupEvent?

答：如果是休眠系統(tǒng)且ECU被喚醒后繼續(xù)跑，則CanTrcv需要進行喚醒源檢測并調用EcuM_SetWakeupEvent設置喚醒源事件。如果是斷電系統(tǒng)，或者休眠系統(tǒng)且ECU被喚醒后軟件復位，則CanTrcv不用做喚醒源檢測，也不會調用EcuM_SetWakeupEvent設置喚醒源事件，需要自定義起碼模塊是西安喚醒源檢測。

3.不同類型的Can收發(fā)器主要使用場景是？

生產CAN收發(fā)器的廠商比較有名是NXP，Infineon，TI等，類型很多，收發(fā)器支持的功能也不近一樣。這里介紹NXP的三種比較有代表性的收發(fā)器，TJA1044,TJA1043,TJA1145。

TJA1044收發(fā)器相比基礎版本增加了standby的低功耗模式，此模式的功耗在10uA左右。同時CAN收發(fā)器處在standby模式時會開啟CAN總線喚醒功能，當CAN總線上有數(shù)據(jù)時，RXD會產生從高到低的跳變沿，此跳變沿可以被MCU用來做喚醒源。此種收發(fā)器一般用在KL30（長電）和KL15同時供電的產品上，如儀表，中控，導航等產品。

Standby模式下的功耗已經很低了，如果車廠要求功耗做的更低，或者要求支持本地喚醒，此時就需要使用帶sleep模式，INH引腳和wake引腳的收發(fā)器了。以TJA1043為例，當MCU配置TJA1043進入sleep模式之后，INH引腳拉低，LDO關閉輸出，MCU關閉不消耗電流。當CAN總線有喚醒信號，或者wake引腳有跳變沿，INH引腳被拉高，LDO打開輸出，MCU啟動并配置TJA1043進入Normal模式接收CAN報文。傳統(tǒng)的VCU，BMS等產品就使用了此收發(fā)器。

像T-BOX這類應用，一般對低功耗的要求更嚴格，如果使用TJA1043這類收發(fā)器，一旦被和自己不相關的CAN報文喚醒之后，需要軟件進行判斷處理，盡快的再次進入休眠模式。此時就對CAN收發(fā)器提出了新的功能需求，既局部網絡喚醒功能，相關標準為11898-6:2013。NXP支持該功能的收發(fā)器為TJA1145，可以通過SPI接口配置喚醒報文的速率，ID和數(shù)據(jù)，不滿足條件的CAN報文無法喚醒TJA1145。

需要提醒的是，TJA1145不支持CAN FD的局部網絡喚醒功能，如果TJA1145被用于CAN FD總線中，需要選用TJA1145T/FD and TJA1145TK/FD，其他型號接收到CAN FD的喚醒信號會識別為錯誤信號。

審核編輯：劉清