前言
最近遇到一個CAN報文超時Notification不上報導(dǎo)致ECU不休眠的偶發(fā)問題,本文分享解決問題的思路及影響報文超時上報的機制,希望能給各位讀者一點啟發(fā)。
參考文檔:
1.Specification of CommunicationAUTOSAR Release 4.3.0
本文使用的AUTOSAR配置工具為:Vector公司的Davinci
正文
1.問題描述
背景:ECU下電的兩個必要條件是:本地硬線IGN== IgOff && CAN報文中的點火信號等于IgOff,如果包含點火信號的CAN報文丟失,則判斷該報文是否Timeout。
問題場景描述
初始狀態(tài):IgOn,CAN報文中點火信號等于IgOn
執(zhí)行動作:IgOff,直接拔掉CAN工具(等同于所有報文掉線)
問題表現(xiàn):偶發(fā)ECU不能休眠下電
初步分析:ECU不能下電時的Log中顯示,IgOff后點火信號一直還是IgOn且沒有收到點火信號所在報文的Timeout標(biāo)志。
進一步分析:點火信號所在報文的超時標(biāo)志是在Com模塊配置的PDU的Signal的Callout函數(shù)中置位的,也就是說問題發(fā)生的時候報文超時的Callout沒有被調(diào)用。
所以該問題的直接原因就是:IGN信號所在的報文偶發(fā)報文丟失不上報Timeout。
2.嘗試的復(fù)現(xiàn)辦法
按照上訴步驟嘗試20次復(fù)現(xiàn)問題,無論是從ECU表現(xiàn)(ECU休眠,電流接近為0)來看還是Debug斷點調(diào)試(報文Timeout的Callout進入)來看都是正常的,無法復(fù)現(xiàn)問題……
思考:是不是下電流程或者某種機制導(dǎo)致Com的超時判斷不再運行導(dǎo)致的,而且這個機制有效的時候正好在超時判斷之前就會導(dǎo)致這個問題。如果是這樣的話,我們把報文的超時時間配置更大,這個問題應(yīng)該就會必現(xiàn)。
把超時時間配置為10 S,果然這個問題必現(xiàn)了 !
3.原因分析
Step 1: 先看下正常的ComTimeoutNotification的調(diào)用棧(方便分析是哪里出問題導(dǎo)致的)。
正常情況下,Com_MainFunctionRx_ComMainFunctionRx àCom_MainFunctionRxInternal àCom_RxDlMon_MainFunctionRx àCom_RxDlMon_CallTimeOutNotifications調(diào)用各個Notification
-
模塊
+關(guān)注
關(guān)注
7文章
2783瀏覽量
49562 -
CAN
+關(guān)注
關(guān)注
57文章
2885瀏覽量
466736 -
ecu
+關(guān)注
關(guān)注
14文章
914瀏覽量
55441 -
報文
+關(guān)注
關(guān)注
0文章
39瀏覽量
4158
原文標(biāo)題:AUTOSAR架構(gòu)下報文掉線超時不上報問題分析
文章出處:【微信號:汽車電子嵌入式,微信公眾號:汽車電子嵌入式】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
在STM32的CAN收發(fā)通信中,接收超時為什么不能發(fā)出一個報文的功能?
TC387從App跳回PBL在下載SBL,進入SBL后上位機發(fā)送的CAN報文響應(yīng)超時,怎么解決?
espconn_gethostbyname接口DNS解析超時機制要自己做嗎?
請問HAL庫的超時機制可以修改嗎?
Linux串口通信的超時機制
為什么32個CAN設(shè)備同時每隔1秒進行上報會出現(xiàn)有些上報不成功的現(xiàn)象呢
M482單片機只會上報FIFO的中斷,不會上報超時中斷的原因?
嵌入式網(wǎng)絡(luò)終端報文收發(fā)機制研究與實現(xiàn)
基于公平心跳超時容錯機制
網(wǎng)絡(luò)管理報文的收/發(fā)與網(wǎng)絡(luò)管理時間配置參數(shù)解析

CAN報文發(fā)送有優(yōu)先級嗎?

如何設(shè)計STM32嵌入式程序的超時機制?

STM32程序超時設(shè)計

評論