S32K312：NMI 在 Reset_Handler 执行之前触发，仅在功能（软件）复位之后触发，且仅在特定情况下触发。 设备：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 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - 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 信息来源。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
请您在系统处于挂起状态时读取寄存器 MU_0.MUB CSSR0 和 MU_1.MUB CSSR0，并确认其中任何一个寄存器的第 0 位（NMIC）是否已设置？
谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 感谢您指出 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通道从一开始就从未被钳位？ 再次感谢您一直以来的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@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引脚吗？
此致，
丹尼尔
Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨，丹尼尔， 请查看附件中的三张合并后的寄存器转储截图，如下所示。 根据您的问题整理我们的研究结果。 -------------------------------------------------------- 附件 -------------------------------------------------------- 附件 1：正常设备（已启用安全调试，运行正常） Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png 附件 2：故障单元，在功能 RESET 之前 已触发信号（正常运行） Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png 附件3：故障单元，功能RESET后，卡在…… NMI 处理程序（挂起状态）
[[ ## completed ##]] Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- 发现 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。 是否出现了与之前同一事件相同的症状？ 再次感谢您一直以来的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@danielmartynek ， 感谢您提供的最新信息，以及您对 MURIP / NMI 路径的升级处理。 请向您内部的健康、安全与环境（HSE）团队提出问题。我们对此表示感谢，我们会等待。 他们的意见。 与此同时，我们发现了一个可能相关的额外数据点， 所以我们希望现在就分享出来，而不是等待。 在比较UTEST Flash区域中性能良好的单元的OTP字段时 我们发现，在故障单元中，生命周期插槽存在差异。 CUST_DEL (0x1B000220-22F) 和 OEM_PROD (0x1B000230-23F) 完全相同 在好的单元和坏的单元上都编程了（所有字均为 0x55AA50AF） 故障单元。 区别在于 IN_FIELD 插槽 (0x1B000240-24F)： - 良好单元：开始进行编程。 Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - 故障单元：读取为未编程 (0xFFFFFFFF) Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png 我们仍在仔细核对 IN_FIELD 中的确切字节模式。 我们这边有个位置，但这个位置的好坏差异似乎很明显。 持续的。 请问您能否解释一下： 1.这是否意味着故障单元的配置发生了变化 在过渡过程中途被损坏或不完整 IN_FIELD？ 2. 生命周期推进到 IN_FIELD 是否可能不完整或缺失 请解释我们一直在研究的NMI/挂起行为 线？ 3. 是否有安全的方法来检查或完成此生命周期进展 对于故障单元，是否需要进行全面的生产线重启？ 再次感谢您的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
根据内存视图，OEM_PROD = 非活动状态，IN_FIELD = 已擦除。
请先读取DCM寄存器：RM，版本12，第 39.3.1 节 DCM 内存映射。
以及第 38.2.3 节“破坏性重置 3 (DCMROD3) 中的只读 GPR”？
您也可以使用 HSE_FW API 来获取 LC 属性？
谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
感谢您提供的详细寄存器转储文件。我已经将有关 MURIP 行为以及 HSE_B 和 CM7_0 之间潜在的 NMI 路径的问题上报给了我们内部的 HSE 团队，因为这似乎没有相关文档记录。等我收到他们的反馈后，我会尽快回复你。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
谢谢你提供的数据。
由于 IN_FIELD 槽仍处于擦除状态，您能否尝试再次设置该属性以推进其更新？
正如我之前提到的，该案件目前正在内部讨论中。
一旦有任何新消息，我会立即更新此帖。
Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 感谢您向我们指出 DCM 内存映射和 DCMROD3。我们在两台设备上捕获了 DCMSTAT (0h)、DCMLCS (8h)、DCMLCS_2 (80h) 和 DCMROD3 (208h)，并根据 RM rev.9 对它们进行了解码。 ---------------------------------------------------- 捕获的值 ---------------------------------------------------- 好单位： Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 故障单元： Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - 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 闪存标记的单独/安全存储来跟踪生命周期，或者这是否表明标记本身存在问题。 问候， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@danielmartynek 我们按照建议，再次尝试在故障单元上设置 IN_FIELD 属性。 结果：HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) 问候， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
可能是负责推进生命周期 (LC) 的 HSE 服务中断了，导致 LC 处于这种状态。
LC 和 LC 控制 (DCMLCC) 寄存器报告的值与 HSE_FW 相同，均为 0x77 (IN_FIELD)，但 UTEST 区域的编程不正确。理论上，您可以使用调试器对 UTEST IN_FIELD 插槽进行编程，这应该可以清除 DCM 错误。
此致，
丹尼尔
Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek 感谢您建议使用调试器对 UTEST IN_FIELD 槽进行编程。 我们检查了内部 OTP 字段参考表，发现 IN_FIELD 生命周期槽 (1B00_0240-024F) 在 LC > MCU_PROD (OEM_PROD) 后，除 HSE 外，对任何主设备均被列为写保护。由于该单元上的 HseReadLifecycle() 已经报告 IN_FIELD，因此该 LC 条件似乎已经满足。 能否解释一下，在这种保护规则下，调试器向该插槽写入数据如何才能成功？在这种情况下，要使调试器被视为允许的主设备，是否需要特定的程序、模式或身份验证步骤？ 另外，您是否已经找到任何关于为什么 LC 推进到 IN_FIELD 时最初会处于这种不完整状态的原因？如果可以进行分析，我们希望了解根本原因，而不仅仅是恢复步骤。 谢谢你， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
谢谢你提供的信息。
目前看来，似乎没有办法恢复MCU。
一种可能性是，HSE 设置属性服务请求推进 LC 的操作被系统 RESET 中断（据我了解，LC 不是通过 IVT 中的 LCW 推进的）。
您是否阅读了 HSE 对服务请求的回复？你们会记录是否出现错误吗？
在触发服务之前，您是否验证过 HSE_STATUS_INIT_OK 是否已设置？
有多少块电路板/MCU受到此问题的影响？这种情况仅限于少数设备，还是在更多设备上都观察到了？
谢谢！
丹尼尔 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
请问有任何最新消息吗？
谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 很抱歉回复晚了，感谢您的提问。以下是我们的回答： 1.对于 LC 推进序列，我们读取 HSE 服务响应（来自 DebugAuth、AdvanceLifecycle 和 ReadLifecycle 调用），并使用它们来确定总体成功/失败状态。我们不记录具体是哪个调用失败了，也不记录具体的错误代码——只有总体的 OK/FAIL 结果，并且不会将其保存到任何地方。因此，我们没有关于这些设备最初进行LC推进过程中发生了什么的记录。 2. 我们的 LC 更新函数及其调用者在触发 AdvanceLifecycle 服务之前，都没有显式检查 HSE_STATUS_INIT_OK。我们在下载流程开始时检查一次 HSE_STATUS_INIT_OK，方法是读取 MU_0.MUB FSR 寄存器 (0x4038C104) 并从中导出 hseStatus_t（对 FSR 位 16-31 进行掩码/移位，如在 Hse_Ip_GetHseStatus 中所做的那样）。在流程后续的生命周期推进步骤之前，不会重复进行此检查。 为了提供更多背景信息，我们故障单元的生产设备日志显示了以下顺序：FSR 检查完成（OK）-> 应用程序下载 -> 安全调试启用 -> 失败。请注意，我们设备日志中的“安全调试启用”指的是包含 LC 推进（DebugAuth、AdvanceLifecycle 和 ReadLifecycle 一起）的整个过程——它被记录为一个单独的通过/失败步骤，因此我们无法从该日志中判断哪个子步骤实际失败了。 我们的调试设备（TRACE32）已在现有调试流程中检查了 HSE_STATUS_INIT_OK，但我们的下载/编程设备（生产线）可能没有在 LC 前进触发的序列点上持续检查此状态。 关于受影响的设备数量：目前我们有 2 块板/MCU 出现此问题。 我们还有两个后续问题： - 通过读取 FSR 寄存器并从中导出 hseStatus_t 来检查 HSE_STATUS_INIT_OK 是否是一种有效/推荐的方法？ - 目前，我们在下载流程开始时通过读取寄存器来检查 HSE_STATUS_INIT_OK。在触发生命周期推进之前，是否也应该专门检查一下？ 谢谢你，Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 希望你一切都好。我想查看一下这个帖子有没有什么更新。 如果您有时间，能否提供一些指导？我们将不胜感激。 谢谢你， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ，
很抱歉耽搁了——我一直在等待 HSE 团队的反馈，但还没有收到关于 NMI 的明确解释。
DCMROD3 中的 LC_ERR 标志：只有当 FCCU NCF 3 配置为生成 NMI 时，它才能触发 NMI。
关于您的问题：
是的，没错。
系统 RESET 后应检查 HSE_STATUS_INIT_OK 标志。应用程序必须等待此标志出现后才能更改系统时钟或使用任何 HSE 服务。一旦设定，就不会改变。该应用程序还可以轮询 HSE_B 内核的 WFI 标志 (PRTN0_CORE2_STAT[WFI])，以确定 HSE_B 是忙还是空闲。
关于 LC 推进中断的问题——还有一个值得调查的可能根本原因。更改生命周期会修改 UTEST 闪存的内容，而 UTEST 闪存与代码闪存块 0 位于同一个 RWW（边读边写）分区中。如果在 UTEST 写入期间有任何代码正在从块 0 执行，则会发生 RWW 错误，并可能阻止生命周期更改成功完成。为避免这种情况，应用程序必须确保在 LC 推进服务进行期间没有对 Block 0 的并发访问。请注意，缓存在大多数情况下可能会掩盖此问题，但在某些特殊情况下，特别是当应用程序使用非同步事件时，可能会导致缓存未命中，从而使问题显现出来。
此致，
丹尼尔
記事全体を表示
