前言
最近遇到一個(gè)CAN報(bào)文超時(shí)Notification不上報(bào)導(dǎo)致ECU不休眠的偶發(fā)問(wèn)題,本文分享解決問(wèn)題的思路及影響報(bào)文超時(shí)上報(bào)的機(jī)制,希望能給各位讀者一點(diǎn)啟發(fā)。
參考文檔:
1.Specification of CommunicationAUTOSAR Release 4.3.0
本文使用的AUTOSAR配置工具為:Vector公司的Davinci
正文
1.問(wèn)題描述
背景:ECU下電的兩個(gè)必要條件是:本地硬線IGN== IgOff && CAN報(bào)文中的點(diǎn)火信號(hào)等于IgOff,如果包含點(diǎn)火信號(hào)的CAN報(bào)文丟失,則判斷該報(bào)文是否Timeout。
問(wèn)題場(chǎng)景描述
初始狀態(tài):IgOn,CAN報(bào)文中點(diǎn)火信號(hào)等于IgOn
執(zhí)行動(dòng)作:IgOff,直接拔掉CAN工具(等同于所有報(bào)文掉線)
問(wèn)題表現(xiàn):偶發(fā)ECU不能休眠下電
初步分析:ECU不能下電時(shí)的Log中顯示,IgOff后點(diǎn)火信號(hào)一直還是IgOn且沒(méi)有收到點(diǎn)火信號(hào)所在報(bào)文的Timeout標(biāo)志。
進(jìn)一步分析:點(diǎn)火信號(hào)所在報(bào)文的超時(shí)標(biāo)志是在Com模塊配置的PDU的Signal的Callout函數(shù)中置位的,也就是說(shuō)問(wèn)題發(fā)生的時(shí)候報(bào)文超時(shí)的Callout沒(méi)有被調(diào)用。
所以該問(wèn)題的直接原因就是:IGN信號(hào)所在的報(bào)文偶發(fā)報(bào)文丟失不上報(bào)Timeout。
2.嘗試的復(fù)現(xiàn)辦法
按照上訴步驟嘗試20次復(fù)現(xiàn)問(wèn)題,無(wú)論是從ECU表現(xiàn)(ECU休眠,電流接近為0)來(lái)看還是Debug斷點(diǎn)調(diào)試(報(bào)文Timeout的Callout進(jìn)入)來(lái)看都是正常的,無(wú)法復(fù)現(xiàn)問(wèn)題……
思考:是不是下電流程或者某種機(jī)制導(dǎo)致Com的超時(shí)判斷不再運(yùn)行導(dǎo)致的,而且這個(gè)機(jī)制有效的時(shí)候正好在超時(shí)判斷之前就會(huì)導(dǎo)致這個(gè)問(wèn)題。如果是這樣的話,我們把報(bào)文的超時(shí)時(shí)間配置更大,這個(gè)問(wèn)題應(yīng)該就會(huì)必現(xiàn)。
把超時(shí)時(shí)間配置為10 S,果然這個(gè)問(wèn)題必現(xiàn)了 !
3.原因分析
Step 1: 先看下正常的ComTimeoutNotification的調(diào)用棧(方便分析是哪里出問(wèn)題導(dǎo)致的)。
正常情況下,Com_MainFunctionRx_ComMainFunctionRx àCom_MainFunctionRxInternal àCom_RxDlMon_MainFunctionRx àCom_RxDlMon_CallTimeOutNotifications調(diào)用各個(gè)Notification
-
模塊
+關(guān)注
關(guān)注
7文章
2613瀏覽量
47012 -
CAN
+關(guān)注
關(guān)注
57文章
2663瀏覽量
462448 -
ecu
+關(guān)注
關(guān)注
14文章
853瀏覽量
54219 -
報(bào)文
+關(guān)注
關(guān)注
0文章
34瀏覽量
4004
原文標(biāo)題:AUTOSAR架構(gòu)下報(bào)文掉線超時(shí)不上報(bào)問(wèn)題分析
文章出處:【微信號(hào):汽車電子嵌入式,微信公眾號(hào):汽車電子嵌入式】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論