如何进行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发生时的上下文信息。

审核编辑：刘清