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

正文

1. OS錯誤處理介紹

1.1 錯誤類型

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

1.2 錯誤碼

發生Application Errors后OS會調用ErrorHook(),ErrorHook()函數是callout函數，函數原型：

(void) ErrorHook(StatusType Error);

參數Error標識具體的錯誤碼

發生Protection Errors后OS會調用ProtectionHook(), ProtectionHook函數是callout函數，函數原型：

ProtectionReturnType ProtectionHook(StatusType Fatalerror);

參數Fatalerror標識具體的錯誤碼

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

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

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

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

1.3 Davinci中配置OsHooks

三個Error相關的Hook函數可以在Davinci中配置，如果配置后就需要用戶自定義實現。

2. 自定義錯誤處理

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

2.1 錯誤信息存儲

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

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

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

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

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

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

問題2：錯誤信息存儲在那里了，是不是可以存儲在NvM？

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

Note:

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

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

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

2.2 關鍵上下文信息獲取

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

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

/*!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導致的，只要我們記錄好錯誤發生時的ServiceID等就能輕松定位。

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

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

3.總結

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

問題1：有哪里常見的OS錯誤 ？

答：大類有Application Errors, Protection Errors, Kernel Errors三種，每種大類包含的具體ErrorCode可以參考1.1章節。

問題2：如何進行OS錯誤處理？

答：通過Retention RAM來存儲OS錯誤信息，通過OS給出的一系列API獲取Error發生時的上下文信息。

審核編輯：劉清