1536_AURIX_TriCore内核架构_Trap

全部学习汇总： GreyZhang/g_tricore_architecture: some learning note about tricore architecture. (github.com)

近段时间一直在跟trap打交道，但是处理得毫无头绪，因此找出来了这一章节看一下。暂时，这方面稍微有了一点框架感，但是还是缺少一些实践上的印证来丰富理论以及实践的结合点。

1. 首先这里引入了一个全新的知识点概念，后面需要去学习一下，那就是不可屏蔽中断。这个在接触ARM的时候就已经看到过了，但是没有弄清楚究竟是什么。

2. Trap一共有8类，这些概念之前的学习中也已经看过了。

3. 出问题之后，TIN会由硬件存储到D[15]之中。

4. 分类方式上，可以分成同步/异步、硬件/软件。

从这个表格看，其实只有少数几个trap是软件触发类的，其他的应该都是MCU内核硬件层面的行为。

1. 同步trap：执行或者尝试执行特殊的指令；访问了需要存储管理系统干预的地址。这样的trap在执行结束之前就可以判定。

2. 异步的trap类似中断，但是不可屏蔽。

3. 硬件中断，主要是MMU相关的。

4. 软件trap，可以通过断言等实现。这里顺便学到了，溢出其实是有几个断言支持的。

不可恢复的中断有一个FCU，之前也看到过。这么看，其实很多trap还是可以恢复的。而我现在看到的大部分的trap处理都是干脆利落，直接停止运行。看起来，这种处理的方式还是有一些欠缺。

1. Trap的处理与中断类似，但是中断的寄存器不会进行修改。

2. Trap的向量处理类似中断，可以类比理解。中断向量的入口是由硬件计算实现的。

3. 返回地址在不同的情况下返回意义以及解析方式不同，这个需要结合具体情况来分析。

4. trap向量表可以放在任意代码区中。

1. 这一页前面这部分与之前的章节有很大的重复，内容重复似乎是这个内核架构手册中的一大特点。但是这也非常好，可以让不同的章节可以有更好的可理解度。

2. 下面的trap处理过程，以及相应寄存器的设置看上去跟中断的处理都十分相似。

这里的一个信息让我觉得奇怪，前面刚刚看到trap不会处理中断，那么为什么又在这里关中断了？

这里，针对不同的trap以及原因做了一个简单的了解。具体的信息倒是可以直接参考笔记中的标注了。

FCD trap出现后的两种处理方法，这个在之前的文档中也是看到过的。看起来，这个内核架构手册的重复度的确是很大。

上面这部分信息主要也是对于TIN的理解，简单看了一下可能的原因。针对load以及fetch的差异后面需要专门学习。

这里看了几个新的TIN的解释，但是针对最后这个计数器减到零之后触发trap，感觉有一些意外。难道现在我接触到的项目中都不会有这种情况？或者说，以增加溢出滚动的方式到0不会触发？

前面还记录了想了解的不可屏蔽中断，这里接着出现了答案。几种典型的情况：NMI直接绑定到一个外部PIN脚；看门狗订一起中断响应；电源失效。

1. trap发生之后，中断不是不可以发生，而是优先级更低。

连续的几个表格给出来了一些trap的优先级。

整体看下来，trap系统不是很复杂，至少从结构路线上看，整体的复杂度甚至还不如中断。这类问题让人望而却步的很大原因或许不是它难，而是少见。