设备：S32K312
工具链：Green Hills ELXR（编译器）
HSE固件：s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin
调试器：Lauterbach TRACE32
软件：基于AUTOSAR RTD的引导加载程序（FBL）+应用程序（APP），双镜像结构
问题概要
在部分生产单元上，CPU 在执行功能性操作后立即挂起。
（软件）RESET。同样的单位在破坏性
（上电复位）后总能正常启动。在我们的参考/已知良好设备上，不会出现卡顿现象。
证据表明，非军事事件 (NMI) 发生在任何应用程序代码执行之前。
1）在挂起点捕获的 CPU 上下文（自动堆叠的异常帧）：
- R0-R3 = 0x00000000，R12 = 0x00000000
- LR = 0xFFFFFFFF（重置默认值 -> 尚未执行任何 BL）
- PC = 0x00416904（我们的 Reset_Handler 的第一个指令地址）
- xPSR = 0x01000000
2) SCB->ICSR = 0x00000802
- VECTACTIVE[8:0] = 2 -> NMI 是当前活动的异常
- RETTOBASE = 1
这证实 CPU 当前正在 NMI 处理程序内部执行。
3) 我们向量表中的 NMI 偏移量条目正确指向我们自己的
默认异常处理程序，因此这是一个真正的 NMI 事件，而不是向量事件。
表格损坏。
在相同的挂起状态下检查的寄存器（全部读取为干净/非活动状态）
- MC_RGM_DES = 0x00000000（非破坏性RESET）
- MC_RGM_FES = 0x20000000（仅限第 29 位）（仅限“软件功能RESET”）
标志位已设置，无其他功能
RESET源已标记）
- FCCU：STAT、N2AF_STATUS、A2FF_STATUS、N2FF_STATUS、NCF_S0、IRQ_STAT
全部 = 0x00000000
- CMU_FC 实例 0、3、4：SR = 0x00000000（无频率高/低故障）
- PMC LVSC = 0x00000000（无 LVD/HVD 标志，已锁存或带电）
- ERM (0x4025C000): 无法读取正常单元或故障单元的 ERM 值
（在我们的配置中可能采用时钟门控），因此 ERM 状态未经验证。
问题
1. 除了 FCCU / CMU_FC / PMC / MC_RGM 之外，还有其他 NMI 来源吗？
这可能会在应用程序的 Reset_Handler 执行之前触发。
第一条指令？
2. 由于 HSE 子系统独立于应用程序核心运行，因此
应用程序核心功能重置是可能的（但这不会导致）
重置 HSE）以创建状态不匹配，从而触发 NMI。
应用核心？
3. 是否有与此症状相符的 S32K312 已知勘误表（仅限 NMI）
功能性/软件重置（而非上电复位）？
任何关于需要检查的其他登记册的指导，或涵盖以下内容的任何文件
非常感谢来自 FCCU / ERM / CMU_FC / PMC 以外的 NMI 信息来源。
你好@Chibeom ，
请您在系统处于挂起状态时读取寄存器 MU_0.MUB CSSR0 和 MU_1.MUB CSSR0，并确认其中任何一个寄存器的第 0 位（NMIC）是否已设置？
谢谢
感谢您指出 MU_0.MUB / MU_1.MUB CSSR0。
MU_0.MUB 和 MU_1.MUB 上的 CSSR0（位 0，NMIC）均读取 0x00000000。
单元处于挂起状态，因此 MU->NMI 请求路径 (CCR0[NMI] /
CSSR0[NMIC]) 似乎并非待处理。
然而，在比较已知良好单元和一台设备之间的MU寄存器时，
故障单元（两者均在相同的挂起状态地址范围内捕获），
我们发现了一个始终存在的差异：
正常单元 故障单元
MU_0.MUB 版本 0x0300000F 0x0300000F（相同）
MU_0.MUB PAR 0x20200404 0x20200404（相同）
MU_0.MUB CR 0x00000000 0x00000000（相同）
MU_0.MUB SR 0x00000000 0x00000002 <- MURIP 集
MU_1.MUB VER/PAR/CR：正常单元和故障单元完全相同
MU_1.MUB SR 0x00000000 0x00000002 <- MURIP 集
因此，在两个 MU 实例上，SR 位 1 (MURIP) 仅在发生故障的实例上设置。
单位，始终如一。根据参考手册，MURIP 指出：
“处理器 A”已发出 MU 复位，且只能通过以下方式清除：
系统重置（非 MU 重置）。
由于 CPU 在执行任何操作之前都会在 NMI 处理程序内部冻结，因此无法执行任何操作。
应用程序代码本身无法清除此标志，因此它
必须在启动序列之前（或作为启动序列的一部分）设置。
我们非常希望您能就以下问题提供意见：
1.对于 MU_0.MUB 和 MU_1.MUB，哪个处理器是“处理器 A”（即
谁制定 MURIP？我们的头部信息仅暴露了“MUB”寄存器块。
应用程序核心可访问地址——这是否意味着
应用程序核心始终是“处理器 B”，而 HSE 是“处理器 A”。
在这些情况下呢？
2. “系统RESET”（清除 MURIP 所必需的操作）是否包含功能/软件
是RESET应用核心，还是仅进行破坏性/上电RESET？如果
MURIP 无法通过我们的功能 RESET 清除，这就能解释为什么了。
SW RESET 后该设置保持不变，但开机后则清除。
3. 独立于 NMI 问题：MURIP 标志本身是否已设置/卡住
在正常运行期间，这是预期之内的还是被认为是异常的？
4. 由于 CSSR0[NMIC] 当前读取值为 0，硬件是否有可能……
NMI 例外条目出现时是否自动清除 NMIC，还是仅通过以下方式清除：
显式软件写入（在这种情况下，NMIC=0 表示
MU->NMI通道从一开始就从未被钳位？
再次感谢您一直以来的帮助。
你好@Chibeom ，
很抱歉耽搁了。我离开办公室两天。
1. 是的，HSE_B 核心控制 MU_0 和 MU_1 的 MUA 接口。
2. 任何系统 RESET 都应该 RESET MURIP。
3. 我认为这是一个异常情况，因为我对此了解不多。
4. 由于它是 W1C 寄存器，因此需要显式写入。
能否确保在触发功能 RESET 时 HSE_B 处于非活动状态？
另外，当应用程序卡在 NMI 处理程序中时，HSE_B 的状态是什么？
你能读取 MU_0 B 侧的标准 HSE GPR (0x4039_C028)、FSR 和 GSR 寄存器吗？
您在应用程序中使用NMI引脚吗？
此致，
丹尼尔
嗨，丹尼尔，
请查看附件中的三张合并后的寄存器转储截图，如下所示。
根据您的问题整理我们的研究结果。
--------------------------------------------------------
附件
--------------------------------------------------------
附件 1：正常设备（已启用安全调试，运行正常）
附件 2：故障单元，在功能 RESET 之前
已触发信号（正常运行）
附件3：故障单元，功能RESET后，卡在……
NMI 处理程序（挂起状态）
[[ ## completed ##]]
--------------------------------------------------------
发现
1）功能RESET触发时的 HSE_B 活动，以及
2）HSE_B 在 NMI 处理程序中卡住时的状态：
比较附件 2（RESET前）和附件 3（RESET后，
在故障单元上（处于挂起状态），我们检查的每个寄存器都显示：
重置前后完全相同：
[[ ## completed ##]]
- MU_0.MUB / MU_1.MUB TSR = 0x0000000F，RSR = 0x00000000（无待处理
发送/接收通道上的消息（RESET后保持不变）
- MU_0.MUB GSR = 0x00000000（不变）
- MU_0.MUB FSR = 0x03600000（未更改）
- HSE GPR (0x4039C028) = 0x000001C1（未更改）
- MU_0.MUB / MU_1.MUB SR 位 1 (MURIP) = 0x00000002 -- 已设置
在RESET触发信号之前，并且保持设置状态，保持不变；在
RESET之后
因此，MURIP 在此次 RESET 周期之前就已经设置好了，并且
功能 RESET 本身并不会改变任何与 HSE 相关的
登记簿。
作为参考，引用，在一台运行良好的设备上，使用相同的安全调试功能
配置（附件 1），MURIP 在两个设备上均读取 0x00000000
MU_0.MUB 和 MU_1.MUB，而 HSE GPR 和 WKPU NCR 读取的是
相同的值。将值视为故障单元。
3）关于设置/卡住的 MURIP 是否属于异常情况：
明白了，谢谢确认。
4) NMI 引脚使用：
我们不使用 WKPU 路由的 NMI 路径（WKPU_IP_USED 未启用；
我们的引导加载程序中没有编译任何 WKPU 驱动程序代码。
应用程序图像）。WKPU NCR (0x402B4008) = 0x60000000 完全相同
在所有三个附件中。在所有情况下，NSR = 0x00000000。自从
我们认为，这一点在所有单位和条件下都保持不变。
涉及外部/WKPU路由的NMI源。
目前为止的调查结果概要
故障
设备上的 MURIP（MU_0.MUB 和 MU_1.MUB SR 位 1）已设置。在功能 RESET 的触发信号发出之前，该单元就已经存在，并且仍然存在。
悬挂期间保持不变。在一台性能良好的设备上，读数为0，与上述相同。
安全调试配置。这是唯一一致且可复现的结果。
我们在比较过的每个注册表中都发现了差异（FCCU，
CMU_FC、PMC、WKPU 和 MU CSSR0/GSR/TSR/RSR/GPR/FSR）。
由于 MURIP 由“处理器 A”（HSE_B）设置，因此应该由……清除。
根据您的回答，“任何系统 RESET”，而且它之前已经设置过了。
我们的功能 RESET 已发出触发信号（但 RESET
本身并未显示）。要更改它），这表明 HSE_B 在早些时候发布了 MU
RESET。 HSE_B 识别的“系统 RESET”从未清除过该点。
问题
1. 从健康、安全和环境 (HSE) 的角度来看，是否有办法确定什么会导致这种情况发生
首先，HSE_B（处理器 A）是否应该发出 MU RESET 指令？我们会
我想了解为什么会设置 MURIP。
2. 是否有推荐的方法来触发 HSE_B
的 RESET？被应用程序
识别为“系统 RESET”（以清除 MURIP）。除了完全断电重启之外，软件方面还有什么需要改进的地方吗？
3. 应用程序核心端的 MURIP 标志卡住是否可能与以下情况有关？
我们正在观察的是NMI，或者这更有可能是两个独立的NMI。
是否出现了与之前同一事件相同的症状？
再次感谢您一直以来的帮助。
你好@danielmartynek ，
感谢您提供的最新信息，以及您对 MURIP / NMI 路径的升级处理。
请向您内部的健康、安全与环境（HSE）团队提出问题。我们对此表示感谢，我们会等待。
他们的意见。
与此同时，我们发现了一个可能相关的额外数据点，
所以我们希望现在就分享出来，而不是等待。
在比较UTEST Flash区域中性能良好的单元的OTP字段时
我们发现，在故障单元中，生命周期插槽存在差异。
CUST_DEL (0x1B000220-22F) 和 OEM_PROD (0x1B000230-23F) 完全相同
在好的单元和坏的单元上都编程了（所有字均为 0x55AA50AF）
故障单元。
区别在于 IN_FIELD 插槽 (0x1B000240-24F)：
- 良好单元：开始进行编程。
- 故障单元：读取为未编程 (0xFFFFFFFF)
我们仍在仔细核对 IN_FIELD 中的确切字节模式。
我们这边有个位置，但这个位置的好坏差异似乎很明显。
持续的。
请问您能否解释一下：
1.这是否意味着故障单元的配置发生了变化
在过渡过程中途被损坏或不完整
IN_FIELD？
2. 生命周期推进到 IN_FIELD 是否可能不完整或缺失
请解释我们一直在研究的NMI/挂起行为
线？
3. 是否有安全的方法来检查或完成此生命周期进展
对于故障单元，是否需要进行全面的生产线重启？
再次感谢您的帮助。
你好@Chibeom ，
根据内存视图，OEM_PROD = 非活动状态，IN_FIELD = 已擦除。
请先读取DCM寄存器：RM，版本12，第 39.3.1 节 DCM 内存映射。
以及第 38.2.3 节“破坏性重置 3 (DCMROD3) 中的只读 GPR”？
您也可以使用 HSE_FW API 来获取 LC 属性？
谢谢
你好@Chibeom ，
感谢您提供的详细寄存器转储文件。我已经将有关 MURIP 行为以及 HSE_B 和 CM7_0 之间潜在的 NMI 路径的问题上报给了我们内部的 HSE 团队，因为这似乎没有相关文档记录。等我收到他们的反馈后，我会尽快回复你。
你好@Chibeom ，
谢谢你提供的数据。
由于 IN_FIELD 槽仍处于擦除状态，您能否尝试再次设置该属性以推进其更新？
正如我之前提到的，该案件目前正在内部讨论中。
一旦有任何新消息，我会立即更新此帖。
感谢您向我们指出 DCM 内存映射和 DCMROD3。我们在两台设备上捕获了 DCMSTAT (0h)、DCMLCS (8h)、DCMLCS_2 (80h) 和 DCMROD3 (208h)，并根据 RM rev.9 对它们进行了解码。
----------------------------------------------------
捕获的值
----------------------------------------------------
好单位：
- DCMSTAT (0h) = 0x00000E11
- DCMLCS (8h) = 0x00000000
- DCMLCS_2 (80h) = 0x00000000
- DCMROD3 (208h) = 0x00000000
故障单元：
- DCMSTAT (0h) = 0x00000E03
- DCMLCS (8h) = 0x06184104
- DCMLCS_2 (80h) = 0x00000006
- DCMROD3 (208h) = 0x00400000
----------------------------------------------------
已解码字段（仅限故障单元，因为正常单元读取的值为全零）
----------------------------------------------------
DCMSTAT：
- bit1 DCMERR = 1（DCM 完成出错）-- 正常设备的此位值为 0
- bit4 DCMLCST = 0（LC 扫描状态未“成功完成”）——正常设备的此位值为 1
DCMLCS：
- 位 21-19 DCMLCC4（IN_FIELD 标记）= 011b = "区域已擦除/未擦除"
- 位 15-13 DCMLCC3（OEM_PROD 标记）= 010b = "标记为非活动"
- 位 27-25 DCMLCC5（预 FA 标记）= 011b = “已擦除/原始”
- 所有关联的 *_ECE/*_CFE/*_CSS 位 = 0。
DCMLCS_2：
- 位 3-1 DCMLCC6（FA 标记）= 011b = "已擦除/原始"
DCMROD3：
- bit22 LC_ERR = 1（“生命周期扫描出错”）
这与我们之前分享的 UTEST OTP 转储一致：故障单元上的 IN_FIELD 插槽读取为已擦除/全新。
----------------------------------------------------
故障单元上的 HSE_FW API 结果 (HseReadLifecycle)
----------------------------------------------------
HseReadLifecycle() 返回 0x10 = HSE_LC_IN_FIELD。因此，从 HSE 固件的角度来看，当前生命周期已经是 IN_FIELD。
这似乎与上面的 DCM/OTP 数据相冲突：DCM 的 DCMLCC4 字段读取 IN_FIELD 标记为“已擦除/原始”，而 UTEST OTP IN_FIELD 插槽（0x1B000240h 及之后）读取为未编程（0xFFFFFFFF），但 HSE API 报告生命周期已确认为 IN_FIELD。
我们想按原样分享这些信息，而不是得出结论，因为我们不知道 HSE 是否通过独立于 DCM 闪存标记的单独/安全存储来跟踪生命周期，或者这是否表明标记本身存在问题。
问候，
智范
我们按照建议，再次尝试在故障单元上设置 IN_FIELD 属性。
结果：HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C)
问候，
智范
你好@Chibeom ，
可能是负责推进生命周期 (LC) 的 HSE 服务中断了，导致 LC 处于这种状态。
LC 和 LC 控制 (DCMLCC) 寄存器报告的值与 HSE_FW 相同，均为 0x77 (IN_FIELD)，但 UTEST 区域的编程不正确。理论上，您可以使用调试器对 UTEST IN_FIELD 插槽进行编程，这应该可以清除 DCM 错误。
此致，
丹尼尔