AUTOSAR架构下的OS错误处理

前言

汽车ECU开发，到最后最难的两类问题一个是硬件相关的偶发问题，一个就是系统相关的偶发问题。硬件相关的偶发问题和ECU工作的温度，负载，线束等各种外因相关，这里暂不做讨论。系统相关的偶发问题一般都和OS相关，能够通过OS的错误处理机制能识别出来。我们在软件设计阶段就应该把能提前预知的错误考虑进去，当问题出现的时候能快速的定位问题发生的原因和位置。本文就来介绍下OS的错误类型，以及OS错误发生后常见的处理办法。每个感兴趣的读者都可以考虑以下三个问题:

问题1：有哪里常见的OS错误 ？

问题2：如何进行OS错误处理？

问题3：如何定位OS错误发生的原因和位置？

​缩略词

参考文档：

1.TriCoreTM TC1.6.2 core architecture manual .

2.MICROSAR Classic OS Technical Reference.

3.Specification of Operating System AUTROSAR CP Release 4.3.1.

注：本公众号文章中使用了一些第三方工具和文档，若有侵权，请联系作者删除!

正文

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 Protection
{
  PRO_IGNORE,
  PRO_TERMINATETASKISR,
  PRO_TERMINATEAPPL,
  PRO_TERMINATEAPPL_RESTART,
  PRO_SHUTDOWN,
  PRO_NOTED
} ProtectionReturnType;

也就是，我们可以通过自定义ProtectionHook()的返回值来控制发送ProtectionHook后Os的执行流。

每个厂商（Vector, Etas…）Os实现的Os_Types.h文件中都具体定义了每一种Error Code，这里以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：RAM Retention。RAMretention是一种技术，用于在断电后保持随机存取存储器（RAM）中的数据。在计算机系统中，RAM是一种易失性存储器，这意味着在断电情况下，其中的数据会被清除。这对于一些应用程序来说是不可接受的，因为它们需要在断电后仍然能够保持数据。这就是RAMretention技术的用武之地。可以参考博文：https://blog.csdn.net/bjxdbz/article/details/122799397

背景知识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才有RAM Retentions的功能。

问题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给清零了（需要修改启动代码和连接器脚本）。

参考文档：

​​RH850-U2A16芯片--RAM and Flash介绍​​

​​AUTOSAR架构下RH850芯片断电系统配置实践​​

​​AUTOSAR架构下RH850芯片深度休眠配置实践-Conifig EcuM and BswM​​

2.2 关键上下文信息获取

问题1：通过2.1小结我们知道错误信息应该存放在Retention RAM当中，那么我们应该存储哪些异常时的上下文信息了？

答：我们通过一个表格来举例给出答案。

• /*! Set of hardware registers to be able to resume from an exception. */
• struct Os_ExceptionContextType_Tag
• {
•   /* Stored Address registers of the thread (a2-a7, a12-a15)*/
•   uint32 AddressRegisters[16];
•   /* Stored Data registers of the thread (d0-d15)*/
•   uint32 DataRegisters[16];
•   /*! Stored return address of the thread */
•   uint32 Ra;
•   /*! Stored Psw of the thread */
•   uint32 Psw;
•   /*! Stored Exception source(Exception class and tin number) of the thread */
•   uint32 ExceptionSource;
•   /*! Stored Pcpn (Previous CPU Priority number) from the Pcxi of the thread */
•   uint32 Pcpn;
•   /*! Stored Pie (Previous Interrupt Enable) from the Pcxi of the thread */
•   uint32 Pie;
•   /*! The lower address of the MPU region for stack. */
•   uint32 MpuRegionForStackLow;
•   /*! The upper address of the MPU region for stack. */
•   uint32 MpuRegionForStackUpper;
•   /*! The raw PCXI value from the upper context; may be used to look up in CSAs prior to the exception */
•   uint32 RawPCXI;
• };

2.3 错误定位

对于Application Error一般都是错误使用OS API导致的，只要我们记录好错误发生时的ServiceID等就能轻松定位。

对于Kernel Error由于OS内部数据可能被异常打乱了，数据不在可信，可获取的上下文信息不多，这类错误就只能根据具体硬件平台和OS代码积累经验了（开发阶段可以通过故障注入提前获知Kernel Error产生后的表现）。

实际项目中最可能出问题的就是Protection Error了，而这里面也以MPU保护Error为最常见。出现内存保护Error后，通过Ra(A11程序返回寄存器)查找Map文件可以大概知道那块代码（指令所在的地址）发生异常；通过DEADD寄存器可以得知大概是访问了哪块Data数据（访问的数据的地址）发生了异常，比如异常改写了调用栈内容。示例可以参考文档：​​TC3xx芯片的Trap详解​​

3.总结

最后通过回答开头的三个问题来结束本文。

问题1：有哪里常见的OS错误 ？

答：大类有Application Errors, Protection Errors, Kernel Errors三种，每种大类包含的具体Error Code可以参考1.1章节。

问题2：如何进行OS错误处理？

答：通过Retention RAM来存储OS错误信息，通过OS给出的一系列API获取Error发生时的上下文信息。

问题3：如何定位OS错误发生的原因和位置？

答：具体参考2.3章节。

文章转载自公众号：汽车电子嵌入式