全部学习汇总： GreyZhang/g_TC275: happy hacking for TC275! (github.com)

1. SMU集中了所有软硬件的Alarm信息，这个在之前的很多模块的描述中看得出来的。
2. 默认情况下，其实只有看门狗的Alarm是开的，其他的都是关的。这个描述跟我之前项目经历中遇到的情况并不相同，看起来大概率使用的软件驱动中对SMU进行了相关的配置操作。
3. 为支持功能安全，SMU支持自检模式，同时也支持报错时间的间隔配置。

从这个拓扑图中可以看出一些基础的功能交互关系：

1. SMU可以请求CPU中断；
2. 可以对几个时钟进行监控；
3. 关于复位的部分，应用复位以及上电复位是输入给SMU的，SMU则向SCU输出了NMI以及复位请求。这里看上去像一个回环，但是应该是关键词表述不到位。SCU输入到SMU的应该全都状态，或者alarm。
4. 硬件的安全机制可能包括SRAM、ECC等检测功能。
5. 此外，SMU其实是急停功能的一个最终决策模块。

1. SMU支持的几种安全机制的alarm，之前接触到的信息：锁步、SRAM的相关诊断、FLASH的相关诊断、时钟监控、锁相环监控以及电压监控。
2. SMU支持模拟的Alarm进行支持SMU本身功能的诊断，这个主要是从功能安全角度考虑的设计。
3. FSP是一种故障报出协议，主要是实现一种由内岛外的报错信号输出。从描述看，FSP的报错信号输出可能是跟PIN相关的。
4. 每一个Alarm是否会激活FSP，这个都是可以配置的。

1. 前面架构图中提到的CPU中断请求，可以是向多个CPU申请的多并发需求。
2. 关于reset处理看似回环的设计，我觉得我前面的分析可能是准确的。这种回环其实是状态传递，而最终负责复位的是SCU。通过回环的机制，SMU收集到了相应的信息。
3. 除了支持看门狗超时故障的信息收集之外，还支持内部看门狗的超时预警。

1. Alarm是进行了分组的。
2. Alarm的分组并不是有什么层次结构的约束，仅仅是为了做一个集中的信息映射。

SMU本身支持模块级别的复位，而且复位只复位模块本身而不会影响SPB。

从整个表格看，大部分的功能影响都是上电复位的时候才有。此外，系统以及应用复位会响应SMU SPB BPI以及一些没有列出来的其他功能。

这里列出来了SMU与SCU的一些接口，其实这些接口从开篇的结构图中就能够很容易看出来。

1. ALTx是用来选择外设功能输入的连通配置的。
2. HW_EN是SMU控制PIN输出的使能信号。

1. FSP[0]是由硬件控制的，这个控制也是指代这个是一个硬件行为而不是软件逻辑。
2. 从上面的拓扑图以及下面的文字描述可以看的出来，这里面的信号其实都是MCU内部的信号。而有些信号其实是绑定了寄存器的位，由软件可以控制的。

以上是这一次SMU的基本的功能梳理，涉及到的功能块花了一点时间去理解分析，整体的时间消耗不是很短。SMU应该会是未来工作中经常接触到的，关于这部分的基本介绍接下来还是得做一个细致的分析。