前言
上一篇中講只有Transceiver、Controller處于正常工作模式以后才能有效的收發報文,進而才能識別報文的類型(NM Message、XCPMessage、Diagnostic Message、APPMessage)。但識別出這些報文需要一個前提:ECU上電同時整個主程序運行起來,且需要一定的時間去識別報文類型。
項目中,喚醒事件(也稱喚醒源)有效性驗證為什么要設置一段時間?ECU上電,整個主程序如何運行起來?
本篇就上述問題進行分析。
喚醒事件有效性驗證時間分析
在實際的網絡管理項目中,大家可能會遇到這樣的需求:收到有效喚醒事件(如:網絡管理報文),網絡激活,報文正常收發;如果收到的報文是非網絡管理報文,ECU需要保持一定時間后休眠(如:ECU保持5s,即5s內ECU處于供電狀態)。注意后者網絡仍然在BSM(BusSleepMode),只能此時間內接收報文,不能發送報文。如果ECU在該時間內收到有效喚醒事件(多數是網絡管理報文,也可能是有效的Power ON信號報文),網絡將激活,進而進行正常的報文收發。
注意:ECU喚醒是網絡喚醒的前提條件,ECU喚醒并不一定網絡喚醒,如果網絡激活(進入NormalMode)則ECU一定喚醒(RUN模式)。
為什么要ECU保持一段時間呢?這里說一下個人理解,ECU自身并不知道喚醒事件是不是有效,ECU只要被供電就從啟動文件指定的位置開始執行程序。如果要識別該喚醒事件是不是有效需要上層模塊(EcuM)識別,而EcuM從開始驗證到確認該事件的有效性需要調用底層模塊確認(如:Controller或者Transceiver),這需要時間,且EcuM的驗證和確認一般是異步執行,這也需要時間。上述時間其實并不長,項目不同執行的時間不等(每個項目初始化模塊數量和讀NVM時間不同),但多數在幾十毫秒內執行完,但又為什么會要求1s或者5s或者更長呢?個人理解:ECU被喚醒,整個冷啟動(可以理解為與電壓相關的啟動)花費了“較長”的時間,廢了這么大勁立馬Shutdown有點“過分”,如果ECU下電又被干擾起來還需要重頭再來(各個模塊、外設初始化、讀NVM等),既然這樣還不如等待一段時間確定沒有有效喚醒事件以后,ECU再走Shutdown流程,進而避免ECU頻繁的喚醒->休眠->喚醒,注意是ECU,不是網絡被喚醒->休眠->喚醒,網絡只有有效喚醒源才能激活。
ECU上電,程序運行過程分析
ECU如果要正常的運行程序,則需要供電,之后程序開始執行:啟動文件->BootLoader->Application,進入“main”函數,也就是我們熟知的用戶代碼程序。用戶代碼程序包含ASWC的runnable以及各個模塊的mainhandler(如:CanTrcv_30_Tja1145_MainFunction),這些程序在OS的調度下周期性或者事件觸發執行,這也是上層模塊可以收到消息和處理消息的基礎。
這里主要分析EcuM管理的上電到程序運行過程。AUTOSAR中,EcuM分為Flexible和Fixed兩種類型,因為Fixed并不支持多核且不靈活,本文主要討論Flexible類型的EcuM。
如上圖(1)所示,CInitCode一般是應用程序的main函數,即EcuM_Init在應用程序的main函數被調用,EcuM將控制ECU的啟動流程,EcuM調用StartOS,讓Os完成Task的激活。
EcuM_Init并不能完成MCU所有的初始化動作,在StartPreOS Sequence階段主要完成DET模塊(最先完成初始化,以便其它模塊可以上報開發錯誤)以及一些硬件外設的初始化,如MCU、Port、Internal Watchdog等(主要根據項目需求設置要初始化的外設模塊)。
如上圖,EcuM_StartupTwo將完成SchM(Os),BSW模塊的初始化,其中各個模塊的初始化(Can_Init、CanIf_Init等)在BswM中完成。程序所需的所有外設、模塊初始化之后,啟動Scheduler 定時,即周期性的執行BSW/SWCs任務,至此Application程序得以運行。
審核編輯:劉清
-
mcu
+關注
關注
146文章
17135瀏覽量
351022 -
AUTOSAR
+關注
關注
10文章
360瀏覽量
21557 -
ecu
+關注
關注
14文章
886瀏覽量
54485 -
DET
+關注
關注
0文章
3瀏覽量
8589
發布評論請先 登錄
相關推薦
評論