0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

如何進行AUTOSAR架構下的OS錯誤處理?

832065824 ? 來源:汽車電子嵌入式 ? 2023-10-07 09:33 ? 次閱讀

正文

1. OS錯誤處理介紹

1.1 錯誤類型

OS的Error類型分為三類,Application Errors, Protection Errors, Kernel Errors, 每種Errors產生的原因及產生Error后OS執(zhí)行的動作都不相同,詳見下表:

Error Types Feature
Application Errors 1.如果操作系統(tǒng)無法正確執(zhí)行應用程序請求的操作系統(tǒng)提供的API服務,則引發(fā)Application Erros。典型情況就是操作系統(tǒng)API使用錯誤(例如對象ID無效)。
2.Application Error不會損壞操作系統(tǒng)內部數(shù)據(jù)。
3.如果配置了Error Hook,則OS會調用ErrorHook(),ErrorHook()是一個Callout函數(shù),需要用戶自定義錯誤處理機制。
4.不會造成OS調用Shutdown/terminate。應用程序可以通過簡單地從ErrorHooks返回來繼續(xù)執(zhí)行。
Protection Errors 1.如果應用程序違反其配置的邊界則會觸發(fā)Protection Errors, 典型的就是配置了內存保護或者時間保護后發(fā)生內存非法訪問或超時。
2.Protection Errors不會損壞操作系統(tǒng)內部數(shù)據(jù)。
3.在發(fā)生未處理的異常和中斷時會觸發(fā)Protection Error。
4.將導致ProtectionHook()的調用,在該調用中可以選擇引發(fā)Shutdown或Terminatehanding(ProtectionHook返回值將覺得OS接下來的執(zhí)行流,無論是否重新啟動)。
5.如果配置了Shutdownhook,則會調用ShutdownHook().
6.如果配置了ProtectionHook,則會調用ProtectionHook().
Kernel Errors 1.如果操作系統(tǒng)無法再確保其內部數(shù)據(jù)的正確性,則引發(fā)Kernel Errors(例如,ProtectionHook()期間內存訪問違規(guī))。
2.發(fā)生Kernel Errors后OS會關閉所有中斷且調用Os_PannicHook()通知應用程序。
3. 最后操作系統(tǒng)進入無限循環(huán)。

1.2 錯誤碼

發(fā)生Application Errors后OS會調用ErrorHook(),ErrorHook()函數(shù)是callout函數(shù),函數(shù)原型:

(void) ErrorHook(StatusType Error);

參數(shù)Error標識具體的錯誤碼

發(fā)生Protection Errors后OS會調用ProtectionHook(), ProtectionHook函數(shù)是callout函數(shù),函數(shù)原型:

ProtectionReturnType ProtectionHook(StatusType Fatalerror);

參數(shù)Fatalerror標識具體的錯誤碼

返回值類型ProtectionReturnType是一個枚舉類型:

typedef enum ProtectionReturnType_e
{
  PRO_IGNORE,
  PRO_TERMINATETASKISR,
  PRO_TERMINATEAPPL,
  PRO_TERMINATEAPPL_RESTART,
  PRO_SHUTDOWN,
  PRO_NOTCONFIGURED
} ProtectionReturnType;

也就是,我們可以通過自定義ProtectionHook()的返回值來控制發(fā)送ProtectionHook后Os的執(zhí)行流。

每個廠商(Vector, Etas…)Os實現(xiàn)的Os_Types.h文件中都具體定義了每一種ErrorCode,這里以Vector的代碼實現(xiàn)為例說明每種Error Type包含的常見的Error Code:

ErrorTypes 包含的Error Codes
Application Errors E_OS_ACCESS: Illegal access
E_OS_CALLEVEL:Invalid calling context.
E_OS_ID:Invalid OS object ID.
E_OS_LIMIT: Maximum task activations reached.
E_OS_NOFUNC: OS object is currently not in use.
E_OS_RESOURCE:Scheduling requested with occupied resource.
E_OS_STATE: OS object is not in correct state to perform the requested operation.
E_OS_VALUE:Given value is out of the configured range.
E_OS_SERVICEID: Service cannot be called.
Protection Errors E_OS_PROTECTION_MEMORY:A memory access violation occurred.
E_OS_PROTECTION_EXCEPTION: A trap occurred.
E_OS_SYS_PROTECTION_SYSCALL: An unhandled syscall occurred.
E_OS_STACKFAULT: A stack fault detected via stack monitoring by the OS.
E_OS_SYS_API_ERROR: Wrong API usage.

1.3 Davinci中配置OsHooks

三個Error相關的Hook函數(shù)可以在Davinci中配置,如果配置后就需要用戶自定義實現(xiàn)。

wKgaomUgtc-AdkJFAABuV41kk-E343.jpg

2. 自定義錯誤處理

通過第一節(jié),我們知道了Error的類型及其包含的具體的Error Code,同時,如果我們配置Error發(fā)生后Hook函數(shù),那么在Error發(fā)生時我們就能被通知到。那么現(xiàn)在,我們在Error發(fā)生后應該考慮如何存儲錯誤相關的信息,同時能在事后通過存儲的Error相關信息定位和分析Error。

2.1 錯誤信息存儲

背景知識1RAMRetention。RAMretention是一種技術,用于在斷電后保持隨機存取存儲器(RAM)中的數(shù)據(jù)。在計算機系統(tǒng)中,RAM是一種易失性存儲器,這意味著在斷電情況下,其中的數(shù)據(jù)會被清除。這對于一些應用程序來說是不可接受的,因為它們需要在斷電后仍然能夠保持數(shù)據(jù)。這就是RAMretention技術的用武之地。

背景知識2:斷電系統(tǒng)和深度休眠系統(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被喚醒后,程序可以選擇軟件復位,整個軟件重新運行,也可以選擇從上次停止的地方接著運行。

wKgZomUgteGAWym7AABEsaL61KY124.jpg

Aurix芯片進入深度休眠后后SCR會接管芯片控制,在進入SCR前可以配置PMS模塊的PMSWCR0.STBYRAMSEL位域,選擇給哪快RAM進行供電。只有休眠后改被供電的RAM才有RAMRetentions的功能。

wKgaomUgtfCAe06uAACDX0HDrg0863.jpg

問題1:為什么要考慮錯誤信息的存儲了?

:因為Error發(fā)生時如果時Protection Error的話,一般就會在OS調用ProtectionHook()后執(zhí)行Shutdown,在ShutdownHook()中一般執(zhí)行ECU復位了,如果我們不存儲Error發(fā)生時的上下文信息的話,一旦系統(tǒng)復位的話我們就無法再分析Error發(fā)生的原因了。

問題2:錯誤信息存儲在那里了,是不是可以存儲在NvM?

:錯誤信息可以存儲在NvM中,但是因為ProtectionHook()后一般馬上就要進行MCU復位了,來不及調用異步的NvM接口來存儲錯誤信息了,所以只能把錯誤信息存儲到Retention RAM中。復位起來后,錯誤信息處理SWC讀取Retention RAM中的異常信息,此時可選擇是否再次寫入到NvM當中。

Note:

1.如果系統(tǒng)是斷電系統(tǒng),那么一定要注意OS ShutdownHook()中調用Mcu_PerformReset()進行軟件復位而不是調用SBC的接口給MCU斷電,因為MCU斷電后是冷啟動,Retention RAM中的數(shù)據(jù)也沒了。

2.如果系統(tǒng)是深度休眠系統(tǒng)且使用Aurix芯片的SCR功能,那么Retention RAM一定要配置在PMSWCR0.STBYRAMSEL配置供電的RAM塊中。

3.無論是深度休眠系統(tǒng)還是斷點系統(tǒng),MCU復位后在Main函數(shù)之前的Startup階段都不能把Retention RAM給清零了(需要修改啟動代碼和連接器腳本)。

2.2 關鍵上下文信息獲取

問題1:通過2.1小結我們知道錯誤信息應該存放在Retention RAM當中,那么我們應該存儲哪些異常時的上下文信息了?

:我們通過一個表格來舉例給出答案。

Error Types Error Contex
Application Errors 如果在使用Spinlock是發(fā)生Application Error,可以獲取以下信息:
1.通過Os_GetDetailedError()獲取服務ID及Error Code等信息。
2.通過OSError_GetSpinlock_SpinlockId()返回錯誤的GetSpinlock調用的參數(shù)SpinlockId.
使用其他OS服務,比如Alarm, Resource等發(fā)生錯誤時同樣可以調用OsError_xxx_xxx()獲取相關錯誤現(xiàn)場信息。
Protection Errors 1.ProtectionHook()的參數(shù)Fataerror.
2.通過GetTaskID獲取Error發(fā)生時的正在處理的Task.
3.通過GetISRID()獲取當前執(zhí)行ISR的標識符。
4.通過Os_GetExceptionAddress()獲取引發(fā)最新異常的指令的地址。
5.讀取DEADD寄存器獲取發(fā)生trap時的地址信息。
6.通過Os_GetExceptionContext()獲取異常上下文信息,異常結構體為:struct Os_ExceptionContextType_Tag;
通過結構體成員RaExceptionSource對應的TINClass信息,可以輕松定位MPU保護產生的Error.
Kernel Errors 通過GetTaskID獲取Error發(fā)生時的正在處理的Task.

/*!Setofhardwareregisterstobeabletoresumefromanexception.*/
structOs_ExceptionContextType_Tag
{
/*StoredAddressregistersofthethread(a2-a7,a12-a15)*/
uint32AddressRegisters[16];
/*StoredDataregistersofthethread(d0-d15)*/
uint32DataRegisters[16];
/*!Storedreturnaddressofthethread*/
uint32Ra;
/*!StoredPswofthethread*/
uint32Psw;
/*!StoredExceptionsource(Exceptionclassandtinnumber)ofthethread*/
uint32ExceptionSource;
/*!StoredPcpn(PreviousCPUPrioritynumber)fromthePcxiofthethread*/
uint32Pcpn;
/*!StoredPie(PreviousInterruptEnable)fromthePcxiofthethread*/
uint32Pie;
/*!TheloweraddressoftheMPUregionforstack.*/
uint32MpuRegionForStackLow;
/*!TheupperaddressoftheMPUregionforstack.*/
uint32MpuRegionForStackUpper;
/*!TherawPCXIvaluefromtheuppercontext;maybeusedtolookupinCSAspriortotheexception*/
uint32RawPCXI;
};

2.3 錯誤定位

對于Application Error一般都是錯誤使用OSAPI導致的,只要我們記錄好錯誤發(fā)生時的ServiceID等就能輕松定位。

對于Kernel Error由于OS內部數(shù)據(jù)可能被異常打亂了,數(shù)據(jù)不在可信,可獲取的上下文信息不多,這類錯誤就只能根據(jù)具體硬件平臺和OS代碼積累經驗了(開發(fā)階段可以通過故障注入提前獲知Kernel Error產生后的表現(xiàn))。

實際項目中最可能出問題的就是Protection Error了,而這里面也以MPU保護Error為最常見。出現(xiàn)內存保護Error后,通過Ra(A11程序返回寄存器)查找Map文件可以大概知道那塊代碼(指令所在的地址)發(fā)生異常;通過DEADD寄存器可以得知大概是訪問了哪塊Data數(shù)據(jù)(訪問的數(shù)據(jù)的地址)發(fā)生了異常,比如異常改寫了調用棧內容。

3.總結

最后通過回答開頭的三個問題來結束本文。

問題1:有哪里常見的OS錯誤 ?

:大類有Application Errors, Protection Errors, Kernel Errors三種,每種大類包含的具體ErrorCode可以參考1.1章節(jié)。

問題2:如何進行OS錯誤處理?

:通過Retention RAM來存儲OS錯誤信息,通過OS給出的一系列API獲取Error發(fā)生時的上下文信息。





審核編輯:劉清

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • RAM
    RAM
    +關注

    關注

    8

    文章

    1352

    瀏覽量

    114391
  • SCR
    SCR
    +關注

    關注

    2

    文章

    149

    瀏覽量

    44081
  • AUTOSAR
    +關注

    關注

    10

    文章

    345

    瀏覽量

    21423
  • SBC
    SBC
    +關注

    關注

    0

    文章

    73

    瀏覽量

    19128
  • 易失性存儲器

    關注

    0

    文章

    14

    瀏覽量

    6714

原文標題:AUTOSAR架構下的OS錯誤處理

文章出處:【微信號:汽車電子嵌入式,微信公眾號:汽車電子嵌入式】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    嵌入式編程錯誤處理機制設計

    本文主要總結嵌入式系統(tǒng)C語言編程中,主要的錯誤處理方式。文中涉及的代碼運行環(huán)境如下。
    發(fā)表于 04-28 09:59 ?720次閱讀
    嵌入式編程<b class='flag-5'>錯誤處理</b>機制設計

    嵌入式系統(tǒng)C語言編程中主要的錯誤處理方式

    本文主要總結嵌入式系統(tǒng)C語言編程中,主要的錯誤處理方式。
    發(fā)表于 07-24 16:40 ?842次閱讀
    嵌入式系統(tǒng)C語言編程中主要的<b class='flag-5'>錯誤處理</b>方式

    Rust語言中錯誤處理的機制

    可能的錯誤,實際運行中仍然可能出現(xiàn)各種各樣的錯誤,比如文件不存在、網絡連接失敗等等。對于這些不可預測的錯誤,我們必須使用錯誤處理機制來進行
    的頭像 發(fā)表于 09-19 14:54 ?1309次閱讀

    AUTOSAR架構的多核通信介紹

    隨著汽車ECU迅速的往域控制器方向發(fā)展,ECU要處理的任務越來越多,單核CPU的負載越來越大,多核ECU勢在必行。AUTOSAR架構OS
    的頭像 發(fā)表于 11-13 09:24 ?1871次閱讀
    <b class='flag-5'>AUTOSAR</b><b class='flag-5'>架構</b><b class='flag-5'>下</b>的多核通信介紹

    labviEW錯誤處理的問題

    為什么這個程序在啟用自動錯誤處理和C:\data.txt不存在的情況,沒有顯示錯誤對話框啊?
    發(fā)表于 04-01 10:03

    LabVIEW錯誤處理問題

    我想問一,就是連接硬件采集波形時,需要濾掉直流波,但是采集到的波形時斷斷續(xù)續(xù)的,所以錯誤處理時會停止程序,我想問一,運行時怎么忽略掉這個錯誤
    發(fā)表于 09-18 18:29

    AF錯誤處理

    想問一關于AF的錯誤處理,例如我進行串口通訊,打開串口錯誤,但是我不想停止AF,想繼續(xù)嘗試連接要怎么做?
    發(fā)表于 02-03 15:44

    LabVIEW中的錯誤處理

    如何合理使用 LabVIEW 中的自定義錯誤處理功能;對于可預見的錯誤,是否可以選擇直 接忽略,或者前幾次嘗試忽略直到該特定錯誤出現(xiàn)很多次后才通知用戶需要糾正該錯誤 了;是否可以對
    發(fā)表于 05-24 11:07 ?6次下載

    Spring Boot框架錯誤處理

    》 《strong》翻譯《/strong》:雁驚寒《/p》 《/blockquote》《p》《em》摘要:本文通過實例介紹了使用Spring Boot在設計API的時候如何正確地對異常進行處理。以下是譯文《/em》《/p》《p》API在提供
    發(fā)表于 09-28 15:31 ?0次下載

    一文入門AUTOSAR OS

    Autosar OsAutosar 框架中上至RTE 下至驅動,中間可以和BSW 基礎模塊進行交互。是整個autosar 框架下最重要的
    的頭像 發(fā)表于 06-29 10:34 ?3955次閱讀
    一文入門<b class='flag-5'>AUTOSAR</b> <b class='flag-5'>OS</b>

    RS232通信時怎么處理錯誤?RS232通信中的錯誤處理方法

    RS232通信時怎么處理錯誤?RS232通信中的錯誤處理方法? RS232通信是一種電氣標準,它定義了計算機和串行通信設備之間的通信協(xié)議。盡管RS232通信很穩(wěn)定,但仍然可能會出現(xiàn)錯誤
    的頭像 發(fā)表于 10-17 16:33 ?2668次閱讀

    基于Tricore芯片的AUTOSAR架構的多核啟動

    隨著汽車ECU迅速的往域控制器方向發(fā)展,ECU要出來任務越來越多,單核CPU的負載越來越大,多核ECU勢在必行。AUTOSAR架構OS支持多核處理
    的頭像 發(fā)表于 10-23 10:15 ?2806次閱讀
    基于Tricore芯片的<b class='flag-5'>AUTOSAR</b><b class='flag-5'>架構</b><b class='flag-5'>下</b>的多核啟動

    AUTOSAR OS操作系統(tǒng)功能特性

    AUTOSAR OS AUTOSAR OS(AUTomotive Open System ARchitecture Operating System)是
    的頭像 發(fā)表于 10-27 16:55 ?1990次閱讀

    西門子博圖:錯誤處理機制概覽

    可通過以下幾種不同的錯誤處理機制進行參數(shù)跟蹤或編程或訪問錯誤
    的頭像 發(fā)表于 11-25 11:35 ?2476次閱讀
    西門子博圖:<b class='flag-5'>錯誤處理</b>機制概覽

    C語言中的錯誤處理機制解析

    C 語言不提供對錯誤處理的直接支持,但是作為一種系統(tǒng)編程語言,它以返回值的形式允許您訪問底層數(shù)據(jù)。
    的頭像 發(fā)表于 02-26 11:19 ?438次閱讀