嵌入式开发：Trap和Alarm是两回事

mqh0386

在汽车嵌入式开发中，"Trap"和"Alarm"这两个名词我们并不陌生。程序如果发生了Trap，一般会复位（Reset）。如果软件程序触发了Alarm，很多时候，程序也会复位，两者是一回事吗？
1、Trap是什么？

汽车MCU的开发中，Trap会关联到很多耳熟能详的词汇：Trap向量表、Trap基地址寄存器、Trap处理程序等等。1.1 Trap和CPU目前，绝大多数控制器选用的芯片都不再是单纯的单核（Signal Core）单片机。多核异构（Heterogeneous Multi-Core）和多核同构（Homogeneous Multi-Core）单片机的使用，已经比较普遍。这里先解释多核异构和多核同构的概念。多核异构：指一个单片机包含不同类型或者不同架构的Core，比如：TC3xx既包含Tricore Core，又包含Arm Cortex M3 Core、XC800 Core。
多核同构：指一个单片机内部包含相同类型、相同架构的Core，比如：TC397包含6个Tricore，这6个Core就是多核同构。既然一个单片机包含那么多的Core，即：多个CPU。那么，Trap和CPU之间又是什么关系呢？每个CPU可以独立处理任务，那么，每个CPU也就都可能遇到Trap（陷阱），而且，可能会因为多种因素（eg：非法访问、除0等）而触发Trap。所以，一个CPU会对应一个Trap Table。每个CPU的Trap Table会占用一段内存（一般是PFlash），示意如下：


1.2 Trap与Trap例程

Trap与中断（Interrupt）类似，每个Trap会对应一个Trap处理程序。当Trap发生时，由Trap类别（Class）查找对应CPU的Trap Table，然后跳转到每个Trap对应的处理程序，示意如下：



提示：这点与中断类似，每个CPU包含一个中断向量表，中断向量表中可以记录对应中断例程的位置。
1.3 Trap发生后可以做什么？

当程序发生Trap时，说明程序行为异常，如果要追查Trap诱发的原因，势必需要Trap发生时的一些信息。怎么做呢？既然Trap发生后可以进入Trap处理程序，我们就可以在Trap程序中做一些处理，比如：信息外发或者关键信息存储，以便于后续问题排查，示意如下：


当问题出现在终端用户车辆时，由于没有连接调试设备或者监控设备，关键信息不可能直观地输出。一般的处理措施：通过车端的对外控制器（eg：T-Box，Telematics Box）将信息传输到云端，通过云端获取这些关键信息。当然，这就牵扯到信息安全话题，获取车辆信息需要车主授权。
通过上面这些介绍，因此直白地翻译Trap，就是"陷阱"的意思。那么，我们首先思考一个问题：是怎样的行为触发了Trap呢？遇到如下场景会触发Trap：

不可屏蔽中断（NMI，Non-Maskable Interrupt）；
指令异常（instruction exception）；内存管理异常（memory management exception，eg：栈溢出）；内存非法访问（illegal access）；

......
注意：一般来说，Trap无法由软件关闭，而且是硬件自动激活的行为。
如果大家留意芯片的架构手册（architecture manual），可以看到：Trap有多种分类。而且，大多数的Trap行为由硬件（Hardware）触发，eg：内存非法读/写访问，栈溢出，访问了空地址（NULL_PTR）等；当然，软件（Software）也会触发Trap，eg：System Call指令等。而且Trap的行为不仅可以同步触发（Synchronous），还可以异步触发（Asynchronous）。对于经常查bug的小伙伴来说，Asynchronous问题相对Synchronous问题，稍显棘手。硬件和软件触发的Trap行为，示意如下：



提示：软件触发的Trap，多数属于同步触发，暂没接触过软件异步触发Trap。
2、Alarm是什么？

讨论Alarm，很多时候需要结合功能安全讨论。以TC3xx为例，Alarm触发后的行为由SMU（Safety Management Unit）管理。关于Alarm的触发、管理等细节可以参考前文《嵌入式开发：安全架构核心组件之SMU》。

（一）Alarm和Trap触发的Reset区别

对于Trap，一般会直接复位CPU，而且属于强制行为。其实，这属于一种自我保护机制，当CPU不能正常工作时，通过这种复位机制使得程序重新运行。

但是，Alarm触发的Reset是一种"人为"设定行为，即：根据功能安全要求目标，进行对应的安全处理行为。当程序触发Alarm以后，Reset或者不做处理都可以通过软件配置决定。



（二）Alarm与功能安全

Alarm怎么又和功能安全扯到一起了呢？车辆作为载人的交通工具，安全永远是放在第一位的。在功能安全的概念里，"Safety"可以说是一个显眼包，功能安全的话题有些大，本文不做深入讨论。但是，功能安全的落地执行，脱离不开软件的鲁棒性检查和安全冗余设计。

提到鲁棒性检查，我们会联想到电源管理芯片的安全检查、主芯片的安全检查等等，而且这些安全检查依赖驱动层的MCAL。比如：MBIST（Memory Build In Self Test）、芯片时钟检查、芯片电压检查等。当这些检查异常时，可以通过Alarm触发后续的动作，比如：Reset。当然，软件层面，功能安全还会涉及OS、Watchdog、E2E等，本文不做过多讨论。

功能安全与Alarm关系，示意如下：



额外拓展：

功能安全（Safety）和信息安全（Security）属于两个话题，不要混淆。

往期精彩回顾

Autosar往期精彩文章汇总：252~302

Autosar往期精彩文章汇总：201~251

点击下方关注，一起聊聊Autosar/嵌入式，如果需要，联系作者进群，给你更专业的解答