简介：本资源面向汽车电子与工业自动化领域的嵌入式开发者，提供基于英飞凌TC297多核微控制器实现安全管理单元（SMU）的完整工程代码，重点解决系统在检测到温度、电压、电流等关键参数越限时执行端口紧急停止的安全逻辑问题，适合具备一定嵌入式基础、希望深入理解功能安全与多核编程的工程师学习参考。压缩包共545个文件，以325个h头文件与172个c源文件为主体，辅以xml、json等配置与描述文件，整体约2.55MB，涵盖SMU紧急停止报警处理、三个CPU核的启动与任务调度、任务调度配置及依赖库等模块。目前已有955人学习下载。通过分析SMU_Emergency_Stop_Alarm等核心文件，读者可掌握报警信号接收、紧急停机流程、多核任务划分与中断处理的实现思路，并理解工程配置与库组织方式，为构建高可靠安全管理系统提供可复用的参考范例。
1. 从一次上电无响应的排查说起：TC297 上的 SMU 到底在管什么
板子打样回来，上电后调试器连得上，但程序跑飞，复位后偶尔能起来偶尔起不来。查了两天电源和时钟，最后定位到一颗外部看门狗芯片被误触发——而触发它的，正是 TC297 内部那个平时几乎没人注意的模块：安全管理单元（Safety Management Unit，SMU）。这个场景在汽车电子和功能安全项目里太常见了，很多人第一次接触英飞凌 AURIX 系列时，注意力全在 CPU、GTM、CAN 上，SMU 往往被当成一个"配好就不管"的黑匣子，直到它真的把系统拉进安全状态，才发现自己根本没搞懂它。
这份资源就是围绕 TC297 这颗芯片，把 SMU 的初始化、告警配置、故障响应链路用可编译的代码完整实现了一遍。它适合正在做 AURIX 功能安全开发、需要过 ISO 26262 相关流程、或者单纯被 SMU 告警搞得一头雾水的嵌入式工程师。代码不是寄存器手册的翻译，而是把"哪些告警要开、开完之后往哪送、送错了会怎样"这条链路串起来，能直接放进工程里跑。
2. 项目结构与技术栈：从目录看这套代码的组织逻辑
2.1 目录分层与文件职责
拿到这套代码，先别急着编译，把目录结构看一遍能省很多事。它没有用复杂的构建系统，整体是围绕 TC297 的 iLLD（底层驱动库）展开的，典型的嵌入式工程布局：
smu_tc297/ ├── src/ │ ├── smu_init.c # SMU 模块初始化与告警配置 │ ├── smu_alarm.c # 告警源注册与响应回调 │ ├── smu_handler.c # 故障处理与安全状态切换 │ └── main.c # 启动流程与自检入口 ├── inc/ │ ├── smu_config.h # 告警映射表、优先级定义 │ └── smu_types.h # 枚举与结构体定义 ├── cfg/ │ └── smu_alarm_map.csv # 告警源到响应的映射配置 └── test/ └── smu_selftest.c # 上电自检与注入测试这个分层的思路很清晰：smu_init.c负责把 SMU 从复位状态配置到工作状态，smu_alarm.c处理告警源的注册和分发，smu_handler.c决定收到告警后系统怎么反应。cfg/下那张 CSV 是关键，它把"哪个告警源对应哪个响应"从代码里抽出来，改配置不用动 C 文件，这在功能安全项目里很重要——安全经理要审的就是这张表。
2.2 技术栈与依赖
代码基于英飞凌 AURIX Development Studio 或 Tasking 编译器，依赖 iLLD 库中的IfxSmu.h和IfxSmu_reg.h。没有用到 RTOS，是裸机前后台架构，因为 SMU 的响应要求是微秒级的，走 RTOS 反而增加不确定性。启动流程里，SMU 初始化必须在时钟和看门狗配置之后、外设初始化之前完成，这个顺序错了，告警可能丢或者误触发。
注意：iLLD 版本不同，
IfxSmu_AlarmConfig结构体的字段可能有差异，移植时先对照你手上的 iLLD 头文件确认。
2.3 告警映射表的设计
cfg/smu_alarm_map.csv是整个项目的配置核心，格式大致是这样：
alarm_source,alarm_group,response,enable,comment SMU_ALARM_CPU0_LOCKSTEP,GROUP_CPU,RESET,1,CPU0锁步比较错误 SMU_ALARM_CPU1_LOCKSTEP,GROUP_CPU,RESET,1,CPU1锁步比较错误 SMU_ALARM_SRAM_ECC,GROUP_MEM,IRQ,1,SRAM ECC不可纠正错误 SMU_ALARM_FLASH_ECC,GROUP_MEM,IRQ,1,Flash ECC错误 SMU_ALARM_CLOCK_LOSS,GROUP_CLK,NMI,1,时钟丢失 SMU_ALARM_VOLTAGE_MON,GROUP_PWR,RESET,1,电压监控告警response这一列决定了告警触发后的动作：RESET直接复位、IRQ走中断处理、NMI触发不可屏蔽中断。这张表在编译时被脚本转成 C 数组，运行时由smu_alarm.c逐条注册。把响应策略外置的好处是，不同项目复用同一套 SMU 驱动，只换 CSV 就行。
3. 核心模块拆解：初始化、告警注册与故障响应链路
3.1 SMU 初始化：从复位到工作状态
SMU 上电后处于复位状态，所有告警被屏蔽。初始化的第一步是解锁配置寄存器，然后逐条写入告警配置。这段代码是整个项目的地基：
/* smu_init.c - SMU 初始化主流程 */ #include "IfxSmu.h" #include "smu_config.h" void Smu_Init(void) { IfxSmu_Config smuConfig; IfxSmu_initModuleConfig(&smuConfig, &MODULE_SMU); /* 配置告警全局响应：默认走 NMI，由 handler 决定后续动作 */ smuConfig.alarmGlobConfig.nmiConfig = IfxSmu_NmiConfig_enable; smuConfig.alarmGlobConfig.irqConfig = IfxSmu_IrqConfig_enable; /* 使能 SMU 内部自检，上电时跑一遍 */ smuConfig.startConfig.enableStartupSelfTest = TRUE; /* 应用配置，此函数内部会解锁寄存器并写回 */ IfxSmu_initModule(&MODULE_SMU, &smuConfig); /* 逐条注册告警源，映射表来自 cfg/smu_alarm_map.csv */ Smu_RegisterAlarmsFromTable(g_smuAlarmTable, g_smuAlarmCount); }IfxSmu_initModuleConfig把配置结构体填成默认值，然后我们覆盖三个关键项：NMI 使能、IRQ 使能、启动自检。IfxSmu_initModule内部会处理寄存器解锁序列——TC297 的 SMU 配置寄存器有保护机制，直接写会被忽略，必须按特定顺序写解锁码。这一步如果失败，后面所有告警配置都是白搭，所以初始化后要读回SMU_STS寄存器确认配置生效。
Smu_RegisterAlarmsFromTable是自定义函数，遍历 CSV 生成的数组，对每条告警调用IfxSmu_setAlarmConfig。参数里最关键的是alarmType和responseType，前者指定告警源编号，后者指定响应方式。注册完一条要读回确认，因为某些告警源在特定芯片步进（stepping）上可能不存在，写进去会被静默忽略。
3.2 告警注册与优先级仲裁
告警不是注册完就完事，多个告警同时触发时谁先响应，靠的是优先级仲裁。TC297 的 SMU 支持告警分组，每组有独立的优先级寄存器。代码里用了一个结构体把分组和优先级绑在一起：
/* smu_alarm.c - 告警注册与优先级配置 */ typedef struct { uint8 groupId; uint8 priority; /* 0 最高，数值越大优先级越低 */ uint8 response; /* RESET / IRQ / NMI */ } Smu_AlarmGroupConfig; static const Smu_AlarmGroupConfig g_groupConfig[] = { { GROUP_CPU, 0, RESPONSE_RESET }, /* CPU 锁步错误最高优先级 */ { GROUP_CLK, 1, RESPONSE_NMI }, /* 时钟丢失次之 */ { GROUP_PWR, 2, RESPONSE_RESET }, /* 电压异常 */ { GROUP_MEM, 3, RESPONSE_IRQ }, /* 内存 ECC 走中断 */ }; void Smu_RegisterAlarmsFromTable(const Smu_AlarmEntry *table, uint32 count) { for (uint32 i = 0; i < count; i++) { if (!table[i].enable) continue; /* 设置告警源使能 */ IfxSmu_setAlarmConfig(&MODULE_SMU, table[i].alarmSource, table[i].response); /* 按分组设置优先级 */ uint8 grp = table[i].alarmGroup; IfxSmu_setAlarmPriority(&MODULE_SMU, grp, g_groupConfig[grp].priority); /* 读回验证，防止芯片步进不支持导致静默失败 */ if (IfxSmu_getAlarmConfig(&MODULE_SMU, table[i].alarmSource) != table[i].response) { Smu_LogError(table[i].alarmSource, SMU_ERR_NOT_SUPPORTED); } } }这里有个血泪经验：IfxSmu_setAlarmConfig在告警源不存在时不会报错，只是不生效。如果不做读回验证，你会以为配好了，实际跑起来那个告警永远不会触发。Smu_LogError把不支持的告警源记下来，上电自检时打印，方便对照芯片手册确认。
优先级仲裁的逻辑是：同组内高优先级告警先响应，跨组时按组优先级。CPU 组放最高是因为锁步错误意味着计算单元不可信，必须立刻复位。内存 ECC 走 IRQ 是因为可纠正错误可以记录后继续跑，不可纠正错误才需要升级响应——这个区分在smu_handler.c里做。
3.3 故障响应：从告警触发到安全状态
告警触发后，SMU 硬件会根据配置产生 NMI、IRQ 或直接复位。走 NMI 的路径最复杂，因为 NMI 处理函数里不能调用可能阻塞的代码，所有操作必须是确定性的：
/* smu_handler.c - NMI 处理与安全状态切换 */ void Smu_NmiHandler(void) { /* 读取告警状态寄存器，确认是哪个告警触发 */ uint32 alarmStatus = IfxSmu_getAlarmStatus(&MODULE_SMU); /* 记录到非易失存储区，复位后可以查 */ Smu_LogToNvm(alarmStatus); /* 根据告警组决定动作 */ uint8 group = Smu_GetAlarmGroup(alarmStatus); switch (group) { case GROUP_CPU: /* CPU 不可信，直接触发系统复位 */ IfxScuRcu_performReset(); break; case GROUP_CLK: /* 时钟异常，切到备用时钟源并降频运行 */ Smu_SwitchToBackupClock(); break; case GROUP_PWR: /* 电压异常，关闭非关键外设降低功耗 */ Smu_ShutdownNonCriticalPeripherals(); break; default: /* 其他告警记录后清除，继续运行 */ IfxSmu_clearAlarmStatus(&MODULE_SMU, alarmStatus); break; } }IfxSmu_getAlarmStatus返回一个位图，每一位对应一个告警源。Smu_GetAlarmGroup把位图映射回分组。CPU 组直接复位是因为锁步比较错误意味着两条流水线的结果不一致，继续跑可能输出错误结果，这在安全关键系统里不可接受。时钟组切备用时钟是常见做法，TC297 支持外部晶振和内部备份时钟切换，切换过程要在几个时钟周期内完成，否则外设状态会乱。
Smu_LogToNvm把告警状态写到 DFlash 的保留区，复位后启动流程里读出来，决定是正常启动还是进入安全模式。这个"后悔药"机制在排查偶发故障时特别有用——现场复位了，但原因留在 Flash 里。
提示：NMI 处理函数里不要用 printf 或任何依赖中断的驱动，TC297 的 NMI 优先级高于所有外设中断，调这些会死锁。
4. 编译、烧录与上电验证：让代码在板子上跑起来
4.1 环境搭建与编译
这套代码在 AURIX Development Studio 下可以直接导入。新建工程时选 TC297 对应的器件型号，把src/、inc/、cfg/拷进去，然后在工程属性里添加 iLLD 库路径。编译前确认两件事：一是smu_alarm_map.csv已经被脚本转成smu_alarm_table.c，二是链接脚本里给 NVM 日志区留了空间。
CSV 转 C 数组的脚本项目里带了一个 Python 版本，跑法很简单：
python tools/csv_to_c.py cfg/smu_alarm_map.csv > src/smu_alarm_table.c生成的数组长这样：
const Smu_AlarmEntry g_smuAlarmTable[] = { { SMU_ALARM_CPU0_LOCKSTEP, GROUP_CPU, RESPONSE_RESET, 1 }, { SMU_ALARM_SRAM_ECC, GROUP_MEM, RESPONSE_IRQ, 1 }, /* ... 其余条目 */ }; const uint32 g_smuAlarmCount = sizeof(g_smuAlarmTable) / sizeof(g_smuAlarmTable[0]);编译时如果报IfxSmu_setAlarmPriority未定义，多半是 iLLD 版本里这个函数叫别的名字，去IfxSmu.h里搜Priority就能找到对应接口。
4.2 烧录与上电自检
烧录用 DAP miniWiggler 或板载调试器都行。上电后第一件事是看串口输出的自检结果，test/smu_selftest.c里会跑一遍告警注入测试——通过软件触发某个告警源，看响应是否符合预期。自检输出类似：
[SMU] Init done, 12 alarms registered [SMU] Self-test: inject CPU0_LOCKSTEP -> RESET expected ... PASS [SMU] Self-test: inject SRAM_ECC -> IRQ expected ... PASS [SMU] Unsupported alarms: 2 (check chip stepping)如果自检卡在某一条，先确认芯片步进是否支持该告警源。TC297 不同步进之间告警源有增减，手册的附录里有对照表。
4.3 用调试器观察告警响应
想确认告警真的触发了，可以在Smu_NmiHandler入口打个断点，然后手动往SMU_CMD寄存器写注入命令。更直观的办法是看SMU_STS寄存器的实时值，调试器里加个 watch 表达式，触发时对应位会置 1。注意复位类告警触发后调试器会断开，这是正常的，因为芯片真的复位了。
5. 避坑与常见问题：SMU 调试中容易翻车的地方
5.1 告警配了但不触发
现象是自检注入时没反应，或者实际故障发生了 SMU 没动作。原因通常是配置寄存器没解锁成功，或者告警源在当前芯片步进上不存在。解决办法是初始化后读回SMU_STS和SMU_CFG确认，对不支持的告警源在自检阶段就报出来，别等到现场才发现。
5.2 NMI 处理函数里死锁
在 NMI 里调了IfxQspi_write之类的驱动，结果卡死。原因是 NMI 优先级最高，驱动里等的中断永远等不到。解决是把 NMI 处理做成纯寄存器操作，需要记录的信息先写 RAM，复位后再由启动流程搬到 Flash。
5.3 复位后查不到原因
告警触发了复位，但复位后读 NVM 日志是空的。检查Smu_LogToNvm是否在复位前完成写入——Flash 写入需要时间，如果复位来得太快，数据没落盘。常见做法是先把日志写 RAM 的保留区，复位后启动流程第一件事就是把它搬到 Flash。
5.4 优先级配反导致响应顺序错
CPU 告警和内存告警同时触发，结果先处理了内存告警。检查g_groupConfig里的优先级数值，0 是最高，别写反了。另外跨组仲裁依赖硬件实现，不同步进行为可能不同，关键告警建议单独分组。
5.5 移植到同系列其他型号时告警源对不上
TC297 的代码直接拿到 TC275 上跑，部分告警源编号不同。解决是把告警源定义抽到头文件里，用条件编译区分型号，CSV 里也按型号分列。
6. 二次开发：把 SMU 配置做成可复用的安全框架
这套代码最值得改的地方，是把告警配置从"写死在 C 里"变成"配置驱动"。我一般会做三件事：第一，把 CSV 扩展成带版本号和校验和的格式，每次上电自检时校验配置完整性，防止 Flash 位翻转导致配置错乱；第二，给Smu_RegisterAlarmsFromTable加一个回调注册机制，让应用层能对特定告警挂自定义处理，而不是全塞在smu_handler.c里；第三，把 NVM 日志区做成环形缓冲，多次复位的原因都能查到，而不是只留最后一次。
改造后的注册接口大概长这样：
/* 应用层注册自定义告警处理 */ Smu_RegisterCallback(SMU_ALARM_SRAM_ECC, MyEccHandler); /* 框架内部在分发时先查回调，没有再走默认响应 */ void Smu_DispatchAlarm(uint32 alarmSource) { Smu_Callback cb = Smu_FindCallback(alarmSource); if (cb != NULL) { cb(alarmSource); /* 应用层自己处理 */ } else { Smu_DefaultResponse(alarmSource); /* 走 CSV 配置的默认动作 */ } }验证改造是否成功，别只看编译过不过。我的习惯是跑三遍自检：第一遍正常上电，确认所有告警注册成功；第二遍逐条注入，确认响应和 CSV 一致；第三遍模拟配置损坏（手动改一个字节），确认校验能拦住并进入安全模式。这三遍走完，才敢把代码合进主线。
从那以后我每次配 SMU，都强制走一遍"读回验证 + 注入自检 + 日志落盘"的流程，不再相信"配了就是配了"。希望帮到你。
本文还有配套的精品资源，点击获取
