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.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.png 附件 2：故障单元，在功能 RESET 之前 已触发信号（正常运行） Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png 附件3：故障单元，功能RESET后，卡在…… NMI 处理程序（挂起状态） [[ ## completed ##]] Chibeom_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.png - 故障单元：读取为未编程 (0xFFFFFFFF) Chibeom_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.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 故障单元： Chibeom_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受到此问题的影响？这种情况仅限于少数设备，还是在更多设备上都观察到了？ 谢谢！ 丹尼尔

Wi-Fi芯片组MCU控制 大家好， 我正在寻找一些具有 AP+STA 功能的 Wi-Fi 模块。例如，我找到了一些来自恩智浦半导体（NXP）、微芯科技（Microchip）和英飞凌科技（Infineon）的模块。然而，大多数模块仅通过 PCIe 和高级操作系统启用 wifi 接口。 不过，我找到了一套来自英飞凌的名为 AIROC CYW55X（系列）的 MCU+Wifi 模块。 您在集成和控制这类模块方面有经验吗？如果可以的话，您能否分享一下您之前使用过并成功与外部MCU集成的不同模块？我的目的不是将数据卸载到微控制器，而只是为了控制例如网状网络和接入点功能。 我想使用 MCU（例如 STM）对一些基本的 AI 模型进行一些推理，同时控制 wifi 模块。 谢谢大家 Re: Wi-Fi Chipset MCU Control 您好， 如果您计划使用 STM32 作为主机 MCU，我建议使用IW612或IW416作为 Wi-Fi 设备。在这种情况下，您可以使用产品网页软件部分提供的 STM32 CMSIS-Pack 驱动程序。 这些设备使用 SDIO 进行 Wi-Fi 通信，使用 UART 进行蓝牙通信。对于 IW612，如果您还计划使用 802.15.4，则主机接口为 SPI。 另一种选择是将RW612用作网络协处理器 (NCP)。由于 RW612 是一款无线 MCU，它可以处理无线连接协议栈，而外部 MCU 则专注于应用程序。 问候， 丹尼尔 Re: Wi-Fi Chipset MCU Control 正如丹尼尔提到的，RW612 会是一个不错的解决方案。 它有 3 个无线电模块，并且内置以太网 MAC——非常适合用于开发网络应用。 RW612 可以实现 AP+STA 功能。因此，您可以将该 MCU 用于网络控制和 AI 功能。 如果您正在寻找一个带有 Web UI 和内置 OTA 功能的现成项目，请查看https://mongoose.ws/wizard/ 启动一个项目，选择空目录，选择 FRDM-RW612 作为开发板目标，设置 WiFi 选项，点击“生成”，在 Xpresso 中打开项目，构建并烧录，连接串口控制台，一分钟内即可运行。 您能否详细说明一下您具体在建造什么？

imx93 m33 sdk ethosu_apps_rpmsg: how to get the result of model? in the sdk version26.   ethosu_apps_rpmsg did not show the way to get result from ethosu. how to do it? InferenceProcess::InferenceJob job("job", networkModel, ifm, ofm, expectedOutput, pmuEventConfig, 0,                        &ethosu_drv, 0, nullptr, 0, 0, false);     job.invalidate();     InferenceProcess::InferenceProcess inferenceprocess(inferenceProcessTensorArena, TENSOR_ARENA_SIZE);     bool failed = inferenceprocess.runJob(job);     job.clean(); how can I get the output of this calculation? Re: imx93 m33 sdk ethosu_apps_rpmsg: how to get the result of model? The inference result is in the OFM buffer you pass into the job — ofm in your constructor. expectedOutput is only for the SDK example’s validation path; it is not where the calculated result is returned. The i.MX93 Ethos-U flow writes the completed inference result into the output feature-map buffer and, in the Linux/RPMsg flow, sends the response back to Cortex-A after the OFM is populated . For your code, the important part is: InferenceProcess::InferenceJob job(     "job",     networkModel,     ifm,     ofm,              // <-- output buffer(s)     expectedOutput,   // <-- reference/validation data, not the result     pmuEventConfig,     0,     &ethosu_drv,     0,     nullptr,     0,     0,     false); job.invalidate(); bool failed = inferenceprocess.runJob(job); job.clean(); if (!failed) {     // Read result from ofm } Conceptually: Copy if (!failed) {     // Output tensor 0     uint8_t *outputData = ofm[0].data();     size_t outputSize   = ofm[0].size();     for (size_t i = 0; i < outputSize; i++)     {         PRINTF("ofm[%u] = %d\r\n", i, outputData[i]);     } } Depending on the exact SDK type of ofm , the access may be slightly different, but the rule is the same: read from the same ofm buffer that you passed into InferenceJob . If your model output is quantized, the bytes in ofm are usually int8_t or uint8_t , not final floating-point values. Convert them using the output tensor’s quantization parameters: float real_value = (quantized_value - zero_point) * scale; For example, for an int8 output: int8_t *out = reinterpret_cast (ofm[0].data()); for (size_t i = 0; i < outputSize; i++) {     float y = (static_cast (out[i]) - output_zero_point) * output_scale;     PRINTF("out[%u] q=%d real=%f\r\n", i, out[i], y); } In the RPMsg case, remember that ethosu_apps_rpmsg is mainly the Cortex-M33 firmware service. It receives the request from Cortex-A, runs the Ethos-U job, writes the result into the OFM buffer, and returns the response over RPMsg . On the Cortex-A/Linux side, the documented API path is to access the OFM buffers, for example inf->getOfmBuffers() . So: M33-side direct test: read ofm[0] after runJob() completes successfully. A-core/Linux RPMsg inference: get the output from the Linux-side inference object’s OFM buffers, not from ethosu_apps_rpmsg console output. Do not use expectedOutput as result ; it is only the golden/reference output used by the sample to compare correctness. The output of your calculation is already in ofm ; after a successful runJob(job) , read ofm[0] and interpret/dequantize it according to your model’s output tensor type.

S32K116 モーター制御 速度制御用のスロットル(ポテンショメーター)を追加 ポテンショメーター電圧を測定するためにADCチャネルADC0_SE13を追加したいです。モーターの速度を制御するため。いろいろ試してみましたが、PDBブロックに正しく設定することができませんでした。ProcessorExpertでADCを適切に設定し、その後PDB0を設定しました。いろいろ試してみましたが、毎回MCATツールでPDB0エラーが発生します。 以下のファイルでは何をすれば良いですか？私はk116 FOC 2shのサンプルコードを使用しています。 1. これを実現するために必要な適切な設定は何ですか？ 2. プロセッサエキスパートでのADC構成? 3. プロセッサエキスパートでのPDB設定? 4. periferals_config.c のコード変更？ 5. main.c のコード変更？ 6. meas_s32k.c のコード変更？ 客観的： 1. ポテンショメータを速度制御用のスロットルとして接続します。 2. PDBを介してADCを連続的にトリガーする。 3. 割り込みルーチンでADC値を読み取る。電流と電圧はmeas.cを使用して測定されます。 4. スロットル操作に応じて速度を設定する。ADC割り込みルーチン内。どの変数に速度が関係していますか？ これは設定コードで、数行を修正しています。そしてプロセッサの専門家。 void McuPdbConfig(void) ヤージュ /* PDB0モジュールの初期化 */ PDB_DRV_Init(INST_PDB0, &pdb0_InitConfig0); /* PDB0 CH0 プリトリガー初期化 */ PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig0); PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig1); PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig2); >>>>>//PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig3); /* PDB0の剰余値を設定します */ PDB_DRV_SetTimerModulusValue(INST_PDB0, 7800); PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 0, 0); PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 1, 1200); >>>>//PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 2, 2400); Screenshot from 2023-09-27 11-57-05.png2023-09-27 11-57-05 のスクリーンショット.png Re: S32K116 Motor Control add throttle (potentiometer) for speed control S32K1xxモーター制御プロジェクトでPDBブロックを使ってADC0_SE13でポテンショメータースロットルを追加する場合、MCATツールの根本的な問題はチャネル割り当ての競合やトリガー前のシーケンスカウントのずれに起因します。モータ制御(FOC 2シャント)では、PDBチャネル0がPWMリロードと同期した正確な電流サンプリングに多用されます。スロースロットル測定を追加するには、別のPDBチャネル(可能であれば)か、メインPWMハードウェアトリガーを妨げずに独立したプリトリガーシーケンスとして追加する必要があります。 Re: S32K116 Motor Control add throttle (potentiometer) for speed control 問題が解決しました。COCOフラグをクリアするためにADC値を読み取るのを忘れていました。

MCXA266: ディープパワーダウンからのウェイクアップ後、WUUウェイクアップフラグは0になります（SRS=0x4010、SSRS=0x4011）。 こんにちは、 私はFRDM-MCXA266ボードにおける、ディープパワーダウンモードからのWUUウェイクアップ動作について調査しています。 環境: - MCU:MCXA266 - 委員会:FRDM-MCXA266 - SDK例プロジェクト:frdmmcxa266_power_mode_switch_ll_mcxa - SDKバージョン:26.6.000 - 開発環境:MCUXpressoIDE_25.6.136 BOARD_InitHardware() が呼び出される前にリセットとウェイクアップの状態を読み取るために、main() の冒頭付近に以下のコードを追加しました。 /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); 関連する出力全体は以下のとおりです。 「`」 通常起動。 ######################### ## Power Mode Switch Demo ## ######################### コアクロック = 240000000Hz 電源モード：アクティブ 希望する操作を選択してください Aを押してアクティブモードに入ります Bを押してスリープモードに入ります Cキーを押してディープスリープモードに入ります Dキーを押して電源オフモードに入ります Eキーを押してDeepPowerDownモードに入ります 電源モード選択を待っています... ディープパワーダウン：VDD_CORE電圧ドメイン全体がパワーゲートされます。 起動ソースを選択してください： Aボタンを押して、ウェイクアップソースとしてタイマーを選択してください。 Bボタンを押して、ウェイクアップボタンをウェイクアップソースとして選択します。 起動ソースの選択を待っています... ウェイクアップボタンがウェイクアップソースとして選択されました。 起動するにはSW2を押してください。 電源ドメインを分離します：VDD_USB。 CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 通常起動。 「`」 初回起動時に、以下の値が表示されました。 CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 次に、ディープパワーダウンモードを選択し、ウェイクアップソースとしてウェイクアップボタンを選択し、SW2を押しました。 MCUは正常に起動し、アプリケーションは再起動されましたが、以下の数値が印刷されました。 CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 CMCリセットステータスに関する私の解釈は以下のとおりです。 - 0x00004010:ソフトウェアリセット + ウォームリセット - 0x00004011:ソフトウェアリセット + ウォームリセット + ディープダウンウェイクアップリセット この解釈が正しければ、固定状態はディープダウンウェイクアップリセットが最初に行われ、その後ソフトウェアウォームリセットが行われたことを示しています。 アプリケーションの起動コード、system_MCXA266.cを確認しました。例のソースは見つかりませんでしたが、NVIC_SystemReset()、SYSRESETREQ、またはSCB->AIRCRの書き込みは見つかりませんでした。 また、保持されたNOLOAD変数を使用して、SystemInitHook()にカウンターを追加しました。SystemInitHook()はウェイクアップ後に一度だけ実行されたため、SystemInit()後にソフトウェアリセットされた証拠は見つかりませんでした。 私の質問は以下のとおりです。 ディープパワーダウンからのWUUウェイクアップ後、SRS = 0x4010およびSSRS = 0x4011は想定される値ですか？ MCXA266 Boot ROMやExtended Bootloaderは、アプリケーション起動前にソフトウェアウォームリセットを発行しますか? どのWUUピンがディープ・パワーダウンのウェイクアップを引き起こしたかを特定するための推奨される方法は何ですか? 私の現在のCMCリセット状態の解釈は以下の通りですが、ビットの定義を誤解していたら訂正してください。 英語は母国語ではないので、説明のどこか分かりにくい部分があれば教えてください。 よろしくお願いします。 MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、@ka-2020 ご質問ありがとうございます。同じ設定で私の方でもテストを再現し、動作を調査します。結果が出次第、調査結果とご質問への回答をご連絡いたします。 ご辛抱とサポートに感謝いたします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @Alice_Yang さん。 この件について調べていただき、ありがとうございます。 別のWUU外部ウェイクアップピンを使用して追加テストを実施し、その結果を共有したいと思います。 元のウェイクアップボタンの設定に加えて、以下の設定を追加しました。 WUU_SetExternalWakeUpPinsConfig(APP_WUU, 0, &wakeupButtonConfig); 次に、WUUピン0に割り当てられたピンを使用して、デバイスをディープパワーダウン状態から復帰させました。デバイスは正常に復帰しましたが、以前と同じ結果が見られました。 CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 したがって、この動作は元のSW2 WUUピンに特有のものではないようです。 捜査の進捗状況について何か新しい情報はありますか？ 追加のログ、ソースコード、レジスタ値、またはテスト結果が必要な場合は、お知らせください。 よろしくお願いします。 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、@ka-2020 ご返信とご辛抱に感謝いたします。 ご要望に応じてこちら側でテストを行い、社内チームとも協議しました。ROMの動作に関する明確化にはROMチームからの確認が必要なため、調査に多少時間がかかりました。返信が遅くなり申し訳ありません。ご理解いただければ幸いです。 1. ディープパワーダウンからのWUUウェイクアップ後、SRS = 0x4010およびSSRS = 0x4011は想定される値ですか？ はい。 SSRS ：前回のメインコールドリセット以降にシステムリセットを生成し、かつクリアしていないすべてのシステムリセットの発生源を保存します。SSRSはコアソフトウェアのリセット後に更新されません。 SRS:メインのウォームリセットのたびに、最新のリセットの種類/発生源を示す更新情報を提供します。 2. MCXA266 Boot ROMやExtended Bootloaderは、アプリケーション起動前にソフトウェアウォームリセットを発行しますか?→いいえ。 3. どのWUUピンがディープ・パワーダウンのウェイクアップを引き起こしたかを特定する推奨方法は何ですか?->> ウェイクアップソースピンを特定するために、 WUU_GetExternalWakeUpPinsFlag() は電源ダウンモードに適しており、WUU割り込みサービスルーチンは通常通り実行できます。しかし、ディープ・パワーダウンのウェイクアップ後は、デバイスがリセットシーケンスで再起動し、WUUフラグが既にクリアされているため使用できません。 ところで、ウェイクアップピンは1つだけ使用していますか、それとも複数のウェイクアップピンを有効にしていますか？ よろしくお願いします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @ka-2020さん ご返信ありがとうございます。 この問題とお客様のご要望を、社内のSEチームに最優先で報告いたしました。私たちはこの要請の重要性を十分に理解しており、積極的に対応を進めています。 もう少し調査する時間をください。最新情報をお伝えし、できるだけ早くご連絡いたします。 ご理解とご辛抱に感謝いたします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @Alice_Yang さん。 調査していただき、またご説明いただきありがとうございます。 あなたの説明によると、WUUフラグはアプリケーション開始前のディープ・ダウンリセットシーケンス中にクリアされているようです。 私のテストでは、2つのWUU外部ウェイクアップピンが有効になっていました。元のSW2ウェイクアップピンとWUU外部ウェイクアップピン0です。 念のため確認ですが、これはディープ・パワーダウン後にどのWUUピンがウェイクアップを引き起こしたかを特定するソフトウェアの方法がないということですか? よろしくお願いします。 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @ka-2020さん ご辛抱いただきありがとうございます。 根本原因は特定されており、FUTUREサンプルチップの改良版で修正が実装される予定です。 ご迷惑をおかけして申し訳ございません。ご理解いただけますようお願い申し上げます。 よろしくお願いします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @Alice_Yang さん。 最新情報のご提供ありがとうございます。 修正はFUTUREサンプルチップのリビジョンで計画されていると理解しています。 再開まで今しばらくお待ちください。

NXP S32K3x4EVB-Q172 的 PIL 仿真误差 你好， 我正在尝试使用 MBDT for S32K3 系列 1.1.0 版本进行简单的 PIL 仿真。在 Matlab 2021b 上。我正在使用的电路板是 NXP S32K3x4EVB-Q172。使用 SImulink SIL/PIL，我能够成功运行 SIL，然后再运行 PIL。在 PIL 过程中，我在 Simulink 中收到以下错误。有时，它还会报错，提示我向电路板发送数据而不是接收数据，如图所示。 我还尝试部署 MBDT 提供的 UART 模型示例，例如“S32K344_uart_async_s32ct”。模型已部署，但在 PuTTY 终端上再次测试，仍然无法通信。 请指导我如何解决这个问题。 谢谢 Simple_PIL_project_issue_cc.pngSimple_PIL_project_issue_cc.png   Re: PIL simulation error for NXP S32K3x4EVB-Q172 @mariuslucianand OpenSDA 功能是否已在 S32K344EVB-T172 板上激活，以便在 PIL 中运行，USB2Serial 功能是否已激活？？ 我正在尝试运行PIL示例模型，我已经指定了PIL配置，模型构建正常，但是无法打开串口（请参见附件中的错误日志和配置设置）。 我非常感谢您能就如何解决这个问题提供任何指导。 谢谢！ Re: PIL simulation error for NXP S32K3x4EVB-Q172 你好@Saurabh9 ， 对于为 S32K3 MCU 创建的每个 Simulink 模型，我们的工具箱都会关联一个 S32 CT 或 EB tresos 配置项目，该项目保存板的设置并生成配置 C 代码，供 Simulink 模型在编译过程中使用。默认情况下，S32K3 工具箱关联一个 S32CT/EBT 项目，该项目配置用于另一个评估板 S32K344_Q257。 S32K3x4-Q257 EVB 和 S32K3x4-Q172 EVB 的主要区别在于，前者使用 LPUART13，而后者使用 LPUART6。 你有两种选择： 1.您可以打开外部配置工具，将封装从 Q257 更改为 Q172，并配置 LPUART6 及其所有依赖项（引脚、中断）。 2.您可以将 S32CT 配置文件替换为 s32k344_q172.mex 文件。附加到此主题（.mex）这里的扩展名与 MATLAB 的扩展名无关，它是 S32CT 格式）。 为此，您需要转到“硬件实现”、“硬件”，然后更改默认配置模板，如下所示。 mariuslucianand_0-1648251474071.pngmariuslucianand_0-1648251474071.png 在这两种情况下，您还需要指定 PIL 配置、要使用的 LPUART、PC 上的 COM 端口和波特率。为此，您需要前往硬件实现部门（PIL）。对我来说是 COM31，但你的配置可能不同。 mariuslucianand_1-1648251582058.pngmariuslucianand_1-1648251582058.png 我还附上了一个例子。 在这个特定的电路板上，OpenSDA 作为 USB2Serial 的功能尚未完全实现，因此您需要使用连接到 J44（1 到 TX，2 到 RX）接头的外部 USB2Serial 变流器，以便 PIL 能够工作。Simulink会将生成的elf文件部署到OSDA上，并通过外部USB转串口转换器进行PIL通信。 mariuslucianand_2-1648252183459.pngmariuslucianand_2-1648252183459.png 要测试该示例，请打开 k344_q172_h_s32ct.mdl 文件。打开参考配置，并输入您正在使用的 UAB2Serial 的 COM 端口。 请点击此处查看电路板的所有原理图：https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k3x4-q172-general-purpose-development-board :S32K3X4EVB-Q172 希望这能帮到您， Marius

MCXA266：深度掉电唤醒后，WUU 唤醒标志为 0（SRS=0x4010，SSRS=0x4011） 你好， 我正在研究 FRDM-MCXA266 板上从深度掉电模式唤醒 WUU 的行为。 环境： - MCU：MCXA266 - 电路板：FRDM-MCXA266 - SDK 示例项目：frdmmcxa266_power_mode_switch_ll_mcxa - SDK 版本：26.6.000 - 开发环境：MCUXpressoIDE_25.6.136 我在 main() 函数的开头附近添加了以下代码，以便在调用 BOARD_InitHardware() 之前读取 RESET 和唤醒状态。 /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); 相关的完整输出结果如下： ``` 正常启动。 ######################### ## Power Mode Switch Demo ## ######################### 核心时钟频率 = 240000000Hz 电源模式：激活 选择所需的操作 按 A 键进入：运行模式 按 B 键进入：睡眠模式 按 C 键进入：深度睡眠模式 按 D 键进入：关机模式 按 E 键进入：深度关机模式 等待电源模式选择…… Deep 掉电: The whole VDD_CORE voltage domain is 掉电. 请选择唤醒源： 按 A 选择定时器作为唤醒源； 按 B 选择唤醒按钮作为唤醒源； 等待唤醒源选择... 已选择唤醒按钮作为唤醒源。 请按SW2键唤醒。 隔离功率域：VDD_USB。 CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 正常启动。 ``` 首次启动时，打印了以下值： CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 然后我选择了深度关机模式，选择了唤醒按钮作为唤醒源，并按下了 SW2。 MCU 已成功唤醒，应用程序也已重新启动，但打印出了以下值： CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 我对 CMC RESET 状态的理解是： - 0x00004010：软件 RESET + 热 RESET - 0x00004011：软件 RESET + 热 RESET + 深度掉电唤醒 RESET 如果这种解释是正确的，则粘滞状态似乎表明首先发生了深度掉电唤醒重置，然后发生了软件热重置。 我检查了应用程序启动代码 system_MCXA266.c，以及示例源代码，但我找不到 NVIC_SystemReset()、SYSRESETREQ 或 SCB->AIRCR 写入。 我还使用保留的 NOLOAD 变量向 SystemInitHook() 添加了一个计数器。SystemInitHook() 在唤醒后只执行了一次，因此我找不到 SystemInit() 之后进行软件重置的证据。 我的问题是： 从深度掉电状态唤醒后，SRS = 0x4010 和 SSRS = 0x4011 是否正常？ MCXA266 启动 ROM 或扩展启动加载程序在应用程序启动前是否会执行软件热复位？ 如何确定是哪个 WUU 引脚导致了深度掉电唤醒？ 我目前对 CMC RESET 状态的理解如下，但如果我对位定义的理解有误，请指正： 英语不是我的母语，所以如果我的解释有任何不清楚的地方，请告诉我。 谢谢！ MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@ka-2020 谢谢你的提问。我将使用相同的设置在我的环境中重现该测试，并调查其行为。一旦我拿到结果，我会将我的发现和所有问题的答案告诉您。 感谢您的耐心和支持。 BR 爱丽丝 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@Alice_Yang 感谢您调查此事。 我使用另一个 WUU 外部唤醒引脚进行了额外的测试，并想与大家分享结果。 除了原有的唤醒按钮配置外，我还添加了以下配置： WUU_SetExternalWakeUpPinsConfig(APP_WUU, 0, &wakeupButtonConfig); 然后我使用分配给 WUU 引脚 0 的引脚将设备从深度掉电状态唤醒。设备成功唤醒，但我观察到了与之前相同的结果： CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 因此，这种行为似乎并非原始 SW2 WUU 引脚所特有的。 调查方面有任何最新进展吗？ 如果您需要我提供任何其他日志、源代码、寄存器值或测试结果，请告诉我。 谢谢！ Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@ka-2020 感谢您的回复和耐心等待。 我已根据您的要求进行了测试，并与我们的内部团队进行了讨论。由于对 ROM 行为的澄清需要 ROM 团队的确认，因此需要一些额外的时间进行调查。对于回复延迟，我深表歉意，并感谢您的理解。 1. 从深度掉电状态唤醒后，SRS = 0x4010 和 SSRS = 0x4011 是否正常？ 是的。 SSRS ：存储自上次主冷RESET以来所有导致系统RESET的源，以及您尚未清除的源。SSRS 在核心软件 RESET 后不会更新。 SRS：每次主热RESET时更新，以指示最近一次RESET的类型/来源。 2. MCXA266 启动 ROM 或扩展引导加载程序在应用程序启动前是否发出软件热复位？->>否。 3. 确定导致深度掉电唤醒的 WUU 引脚的推荐方法是什么？—— 对于识别唤醒源引脚， WUU_GetExternalWakeUpPinsFlag() 适用于掉电模式，在该模式下 WUU 中断服务例程可以正常执行。但是，在深度 Power-Down 唤醒后无法使用此功能，因为设备会通过 RESET 序列重新启动，并且 WUU 标志已被清除。 顺便问一下，您只使用了一个唤醒引脚，还是启用了多个唤醒引脚？ 谢谢！ BR 爱丽丝 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@ka-2020 感谢您的回复。 我已经将此问题和您的需求高优先级地提交给了我们内部的软件工程团队。我们完全理解这项请求的重要性，并正在积极跟进。 请给我们一些时间进行进一步调查。我会随时向您汇报最新进展，并尽快回复您。 感谢您的耐心和理解。 BR 爱丽丝 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@Alice_Yang ， 感谢您对此事的调查和澄清。 根据您的解释，WUU 标志似乎在应用程序启动之前，在深度掉电 RESET 序列期间被清除。 在我的测试中，启用了两个 WUU 外部唤醒引脚：原始的 SW2 唤醒引脚和 WUU 外部唤醒引脚 0。 请确认一下，这是否意味着没有软件方法可以识别深度掉电后是哪个 WUU 引脚导致了唤醒？ 谢谢！ Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@ka-2020 感谢您的耐心等待。 根本原因已经确定，将在未来的样品芯片版本中实施修复。 由此造成的不便，我们深表歉意，并感谢您的理解。 谢谢！ BR 爱丽丝 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@Alice_Yang ， 谢谢你的更新。 我了解到该修复方案计划在未来的芯片样品版本中推出。 感谢您的支持。

Two Issues in S32K3 RTD 7.0.1: Unpaired Parenthesis Syntax Error and Missing Crypto XML Files I am using RTD version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. The runtime log reports an unpaired parenthesis error related to featureDefined(`FEATURE_MEM_INFLS_HEADER`). Two native RTD component lines have syntax errors, where the statement getFeature(`FEATURE_MEM_INFLS_HEADER`) == `S32K388` lacks a closing parenthesis. Error Location Both faulty lines contain the code getFeature(`FEATURE_MEM_INFLS_HEADER`) == `S32K388` and are missing a trailing closing parenthesis: File Path & Line 1: eclipse/mcu_data/components/PlatformSDK_S32K3/C40_Ip/C40_Ip.component Line 603 File Path & Line 2: eclipse/mcu_data/components/PlatformSDK_S32K3/Mem_43_INFLS/Mem_43_INFLS.component Line 905 These syntax errors exist in the official original RTD component files and cause runtime feature definition parsing failures.   Second Issue: Crypto Module File Missing Error I am using RTD version S32K3_RTD_7_0_1_D2606_ASR_REL_4_9_REV_0000_20260814 with ArchLinux and S32DS. There is a file missing issue in the Crypto module under the eclipse/mcu_data/processors directory. Not all MCU models contain the two required Crypto configuration files: PlatformSDK_S32K3/common/sdk_features_rtd_crypto.xml and PlatformSDK_S32K3/[MCU_MODEL]_[PACKAGE_TYPE]/resource_tables/RTD_CRYPTO/rtd_crypto_Crypto.xml. When selecting an MCU model without the above two files and adding the Crypto_43_HSE module, it triggers S32DS UI exceptions and code generation failures. Manually copying these two complete XML files from other supported MCU model directories to the target model directory can completely resolve this error. Re: Two Issues in S32K3 RTD 7.0.1: Unpaired Parenthesis Syntax Error and Missing Crypto XML Files Hi @chenwilsoft  First Issue: Thank you for pointing this out. You are correct, there is a typo in both the C40_Ip.component and Mem_43_INFLS.component files within the `FEATURE_MEM_INFLS_HEADER` section. Using the `FEATURE_MEM_INFLS_SUPPORTBLOCK4PIPESELECT` section as a reference, it appears that an extra opening parenthesis "(" was inadvertently added before featureDefined. As workaround, could you please either: Add the missing closing parenthesis ")" at the end of the expression, or Remove the extra opening parenthesis before featureDefined (this will make the syntax consistent with the format used elsewhere in the file) Sorry for the inconvenience this issue may have caused. Second Issue: As you are using S32K3 Real-Time Drivers AUTOSAR R23-11 Version 7.0.1 QLP05, please note that this release is intended only for S32K3x4 and S32K388 devices, as stated in the software release notes. In the image below, I highlighted the sdk_features_rtd_crypto.xml files from two different S32DS 3.6.x installations: Orange: S32DS instance with RTD 7.0.1 QLP05 installed. Purple: S32DS instance with RTD 7.0.1 P02 installed. VaneB_0-1787259680399.pngVaneB_0-1787259680399.png The RTD 7.0.1 P02 package supports all S32K3 derivatives, whereas RTD 7.0.1 QLP05 was specifically designed and validated for S32K3x4 and S32K388 devices. The same applies to the rtd_crypto_Crypto.xml file. These files are not provided for all S32K3 derivatives in the 7.0.1 QLP05 release because support for those devices is outside the scope of this package. BR, VaneB

NXP S32K3x4EVB-Q172のPILシミュレーションエラー こんにちは、 S32K3シリーズ用MBDTバージョン1.1.0を使用して、簡単なPILシミュレーションを試しています。Matlab 2021b 上で動作します。私が作業しているボードはNXP S32K3x4EVB-Q172です。Simulink SIL/PILを使用して、PILに移行する前にSILを正常に実行することができました。SimulinkでPILを実行すると、以下のエラーが発生します。画像に示されているように、データを受信するのではなく、ボードに送信するエラーが発生することもあります。 また、MBDTに付属しているUART用のモデル例(例えば「S32K344_uart_async_s32ct」)をデプロイしてみました。モデルは展開されますが、再びパティ端末で通信は起こりません。 どうすれば解決できるか、アドバイスをください。 よろしくお願い申し上げます。 Simple_PIL_project_issue_cc.pngSimple_PIL_project_issue_cc.png   Re: PIL simulation error for NXP S32K3x4EVB-Q172 @mariuslucianand PILで動作させるために、S32K344EVB-T172ボードでUSB2SerialとしてのOpenSDA機能は有効になっていますか？？ PILの例モデルを実行しようとしています。PILの設定を指定しましたが、モデルは正常にビルドされるのですが、シリアルポートが開かないことが確認できます(添付のエラーログと設定をご参照ください)。 この問題を解決する方法について、何かアドバイスをいただけると大変ありがたいです。 ありがとうございます Re: PIL simulation error for NXP S32K3x4EVB-Q172 こんにちは、 @Saurabh9 さん。 S32K3 MCU用に作成されたすべてのSimulinkモデルに対して、当社のツールボックスにはS32 CTまたはEBのtresos構成プロジェクトが関連付けられており、これによりボードの設定が保持され、後のコンパイルプロセスでSimulinkモデルで使用される構成Cコードを生成します。デフォルトでは、S32K3ツールボックスは評価ボードであるS32K344_Q257向けに設定されたS32CT/EBTプロジェクトを関連付けます。 S32K3x4-Q257 EVBとS32K3x4-Q172 EVBの主な違いは、前者がLPUART13を使用するのに対し、後者はLPUART6を使用する点です。 ここでは2つの選択肢があります。 1.外部設定ツールを開き、パッケージをQ257からQ172に変更し、LPUART6の依存関係(ピン、割り込み)をすべて設定できます。 2.S32CTの設定ファイルをs32k344_q172.mexに置き換えることができます。このスレッドに添付されています(.mexここでいう拡張子はMATLABの拡張子とは全く関係なく、S32CT形式です。 そのためには、ハードウェア実装のハードウェアに行き、下記のようにデフォルト構成テンプレートを変更する必要があります。 mariuslucianand_0-1648251474071.pngmariuslucianand_0-1648251474071.png どちらの場合も、どのLPUARTを使うか、PCのCOMポート、ボーレートを指定する必要があります。そのためには、ハードウェア実装、PIL のセクションに進む必要があります。私の場合はCOM31でしたが、これはあなたの環境設定によって異なるでしょう。 mariuslucianand_1-1648251582058.pngmariuslucianand_1-1648251582058.png サンプルも添付しました。 この特定の基板では、USB2SerialとしてのOpenSDA機能はまだ完全には機能していないため、PILを動作させるにはJ44ヘッダーにコネクテッドした外部USB2Serialコンバータ(1からTX、2からRXへ)を使う必要があります。Simulinkは生成されたelfファイルをOSDA上で展開し、PILは外部のUSB2Serialコンバーターを介して通信します。 mariuslucianand_2-1648252183459.pngmariuslucianand_2-1648252183459.png サンプルをテストするには、k344_q172_h_s32ct.mdl を開いてください。参照されている設定ファイルを開き、使用しているUAB2SerialのCOMポート番号を入力してください。 ボードの回路図はすべてこちらにあります。https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k3x4-q172-general-purpose-development-board :S32K3X4EVB-Q172 お役に立てば幸いです。 マリウス

Is SmartMX2 the right choice for my project? Hi all, I'm evaluating secure element options for a standalone contactless payment device (not a phone) that would need to hold several tokenized payment card applets on one chip, with the ability to select which applet is active/exposed to a terminal before each transaction. A couple of specific questions on SmartMX2: 1. Roughly how many separate payment applets / GlobalPlatform Security Domains can a single SmartMX2 chip realistically support? 2. Does the platform support runtime AID selection triggered by an external host command — i.e., can host-side firmware tell the chip which provisioned applet to expose before a tap, rather than the chip always presenting a static/priority-ordered AID list? 3. Is SmartMX2 still the right product line for this kind of banking/payment use case, or is there a newer NXP family better suited to it? Any pointers to public documentation, dev kits, or the right internal team to talk to would be appreciated. Thanks! Re: Is SmartMX2 the right choice for my project? Hello @Javiergg  Please see the comments on your questions: 1. The NXP SmartMX2 product page on nxp.com is a good starting point for public datasheets and overview documentation. - For deeper technical specs, the product's reference manual (available under NDA) would cover GlobalPlatform SD limits and AID management. 2. For dev kits and direct engagement with the right team, reaching out through NXP's official sales or FAE (Field Application Engineer) channel is recommended, as they can connect you with the secure element specialists for banking/payment applications. 3. Regarding whether SmartMX2 is still the right fit vs. a newer family — NXP's SE050 or SN100 series are also worth exploring depending on your interface and form factor requirements, and an FAE can help compare options for your specific use case.

SmartMX2 适合我的项目吗？ 大家好， 我正在评估独立非接触式支付设备（不是手机）的安全元件选项，该设备需要在一个芯片上存储多个令牌化的支付卡小程序，并且能够在每次交易之前选择哪个小程序处于活动状态/对终端公开。 关于 SmartMX2，我有几个具体问题： 1. 单个 SmartMX2 芯片实际能够支持多少个独立的支付小程序/GlobalPlatform 安全域？ 2. 该平台是否支持由外部主机命令触发的运行时 AID 选择——也就是说，主机端固件能否在执行 tap 操作之前告诉芯片要公开哪个已配置的小程序，而不是芯片始终呈现一个静态/优先级排序的 AID 列表？ 3. SmartMX2 是否仍然是此类银行/支付用例的合适产品线，还是 NXP 有更新的产品系列更适合它？ 任何关于公开文档、开发工具包或相关内部团队的线索都将不胜感激。谢谢！ Re: Is SmartMX2 the right choice for my project? 你好@Javiergg 请查看您问题的评论： 1.NXP.com 上的 NXP SmartMX2 产品页面是获取公开数据表和概述文档的良好起点。 - 有关更深入的技术规格，请参阅产品参考手册（根据保密协议提供），其中涵盖了 GlobalPlatform SD 限制和 AID 管理。 2. 对于开发套件和与合适的团队直接接触，建议通过 NXP 的官方销售或 FAE（现场应用工程师）渠道联系，因为他们可以将您与银行/支付应用的安全元件专家联系起来。 3. 关于 SmartMX2 是否仍然适合与更新的系列进行比较——NXP 的 SE050 或 SN100 系列也值得考虑，具体取决于您的接口和外形尺寸要求，现场应用工程师 (FAE) 可以帮助您比较针对您具体使用情况的各种选项。

Wi-FiチップセットMCU制御 こんにちは、みんな、 AP+STA機能を備えたWi-Fiモジュールを探していました。例えば、NXP、Microchip、Infineonなどのモジュールを見つけました。しかし、ほとんどのモジュールはPCIe経由でWiFiインターフェースを使えず、高度なOSでしか対応していません。 しかし、InfineonのAIROC CYW55X(シリーズ)というMCU+WiFiモジュールのセットを見つけました。 こういったタイプのモジュールの統合や制御に関する経験はありますか？もしそうなら、これまでに使っていて外部MCUとうまく統合できた他のモジュールを教えてもらえますか?私の意図は、データをマイクロコントローラにオフロードするのではなく、例えばメッシュやAPの機能を制御することです。 Wi-Fiモジュールを制御しながら基本的なAIモデルに対して推論を行うために、MCU(例えばSTM)を使っています。 ありがとう、みんな Re: Wi-Fi Chipset MCU Control こんにちは、 ホストMCUとしてSTM32を使う予定なら、Wi-Fiデバイスとして IW612 か IW416 を使うことをおすすめします。その場合、製品ウェブページのソフトウェアセクションにあるSTM32 CMSIS-Packドライバを使用できます。 これらのデバイスは、Wi-FiにはSDIOを、BluetoothにはUARTを使用します。IW612の場合、もし802.15.4を使う予定なら、ホストインターフェースはSPIです。 もう一つの選択肢としては 、RW612 をネットワークコプロセッサ(NCP)として使用することです。RW612はワイヤレスMCUであるため、外部MCUがアプリケーションに集中する間、無線接続スタックを処理できます。 よろしくお願いいたします。 ダニエル Re: Wi-Fi Chipset MCU Control ダニエルが述べたように、RW612は良い解決策となるでしょう。 3-ラジオ対応で、ネットワーク対応アプリケーションの作成に理想的なイーサネットMACも内蔵しています。 RW612はAP+STA対応が可能です。つまり、そのMCUはネットワーク制御とAI機能の両方に使えます。 Web UIと組み込みOTAを備えたすぐに構築できるプロジェクトをお探しなら、 https://mongoose.ws/wizard/をご覧ください。 プロジェクトを開始し、空のディレクトリを選択し、ボードターゲットとしてFRDM-RW612を選択し、WiFiオプションを設定し、「生成」をクリックし、Xpressoでプロジェクトを開き、ビルドとフラッシュを実行し、シリアルコンソールを接続すれば、すぐに動作させることができます。 具体的に何を作っているのか、もう少し詳しく教えてもらえますか?

S32K116 Motor Control add throttle (potentiometer) for speed control I want to add ADC channel ADC0_SE13 to measure potentiometer voltage. To control speed of motor. I tried lot of things but unable to set it in PDB block properly. ADC properly configured in ProcessorExpert and then I have configured PDB0. I tried lot of combination but every time I am getting PDB0 Error in MCAT tool. What I should do in below files? I am using k116 FOC 2sh example code. 1. What is proper settings required to achieve this. 2. ADC configuration in processor expert? 3. PDB configuration in processor expert? 4. code modification in periferals_config.c ? 5. code modification in main.c ? 6. code modifications in meas_s32k.c? Objective: 1. Connect potentiometer as throttle control for speed. 2. Trigger ADC through PDB back to back. 3. Read ADC value in interrupt routine. Where current and Voltages are measured using meas.c. 4. Set speed according to throttle demand. In ADC interrupt routine. Which variable have speed? This is configuration code where I am modifying few lines. and Processor expert. void McuPdbConfig(void) { /* PDB0 module initialization */ PDB_DRV_Init(INST_PDB0, &pdb0_InitConfig0); /* PDB0 CH0 pre-trigger initialization */ PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig0); PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig1); PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig2); >>>>>//PDB_DRV_ConfigAdcPreTrigger(INST_PDB0, 0, &pdb0_AdcTrigInitConfig3);   /* Set PDB0 modulus value */ PDB_DRV_SetTimerModulusValue(INST_PDB0, 7800); PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 0, 0); PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 1, 1200); >>>>//PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDB0, 0, 2, 2400); Screenshot from 2023-09-27 11-57-05.pngScreenshot from 2023-09-27 11-57-05.png Re: S32K116 Motor Control add throttle (potentiometer) for speed control To add a potentiometer throttle via ADC0_SE13 using the PDB block in your S32K1xx motor control project, the core issue in the MCAT tool stems from channel allocation conflicts or misaligned pre-trigger sequence counts. In motor control (FOC 2-shunt), PDB channel 0 is typically heavily utilized for precise current sampling synchronized with the PWM reload. Adding a slow throttle measurement requires either a separate PDB channel (if available) or adding it as an independent pre-trigger sequence without disrupting the main PWM hardware triggers. Re: S32K116 Motor Control add throttle (potentiometer) for speed control Solved issue, I forget to read the ADC value to clear the COCO flag.

MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello, I am investigating WUU wake-up behavior from Deep Power-Down mode on the FRDM-MCXA266 board. Environment: - MCU: MCXA266 - Board: FRDM-MCXA266 - SDK Example project: frdmmcxa266_power_mode_switch_ll_mcxa - SDK version: 26.6.000 - Development environment: MCUXpressoIDE_25.6.136 I added the following code near the beginning of main() to read the reset and wake-up status before BOARD_InitHardware() is called. /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); The complete relevant output is: ``` Normal Boot. ########################### Power Mode Switch Demo ########################### Core Clock = 240000000Hz Power mode: Active Select the desired operation Press A to enter: Active mode Press B to enter: Sleep mode Press C to enter: DeepSleep mode Press D to enter: PowerDown mode Press E to enter: DeepPowerDown mode Waiting for power mode select... Deep Power Down: The whole VDD_CORE voltage domain is power gated. Please select wakeup source: Press A to select TIMER as wakeup source; Press B to select WAKE-UP-BUTTON as wakeup source; Waiting for wakeup source select... Wakeup Button Selected As Wakeup Source. Please press SW2 to wakeup. Isolate power domains: VDD_USB. CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 Normal Boot. ``` At the initial startup, the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 I then selected Deep Power-Down mode, selected WAKE-UP-BUTTON as the wake-up source, and pressed SW2. The MCU successfully woke up, and the application restarted, but the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 My interpretation of the CMC reset status is: - 0x00004010: Software Reset + Warm Reset - 0x00004011: Software Reset + Warm Reset + Deep Power-Down Wake-up Reset If this interpretation is correct, the sticky status appears to indicate that a Deep Power-Down wake-up reset occurred first, followed by a software warm reset. I checked the application startup code, system_MCXA266.c, and the example sources, but I could not find NVIC_SystemReset(), SYSRESETREQ, or an SCB->AIRCR write. I also added a counter to SystemInitHook() using a retained NOLOAD variable. SystemInitHook() was executed only once after wake-up, so I could not find evidence of a software reset after SystemInit(). My questions are: Is SRS = 0x4010 and SSRS = 0x4011 expected after a WUU wake-up from Deep Power-Down? Does the MCXA266 Boot ROM or Extended Bootloader issue a software warm reset before the application starts? What is the recommended method for identifying which WUU pin caused the Deep Power-Down wake-up? My current interpretation of the CMC reset status is as follows, but please correct me if I have misunderstood the bit definitions: English is not my first language, so please let me know if any part of my explanation is unclear. Thank you. MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @ka-2020  Thanks for your question. I will reproduce the test on my side using the same setup and investigate the behavior. Once I have the results, I will get back to you with my findings and answers to all of your questions. Thank you for your patience and support. BR Alice Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello  @Alice_Yang  Thank you for looking into this issue. I performed an additional test using another WUU external wake-up pin and wanted to share the result. I added the following configuration in addition to the original wake-up button configuration: WUU_SetExternalWakeUpPinsConfig(APP_WUU, 0, &wakeupButtonConfig); I then woke the device from Deep Power-Down using the pin assigned to WUU pin 0. The device woke up successfully, but I observed the same result as before: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 Therefore, this behavior does not seem to be specific to the original SW2 WUU pin. Do you have any updates on the investigation? Please let me know if you need any additional logs, source code, register values, or test results from my side. Thank you. Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @ka-2020  Thanks for your reply and patience. I have tested this on my side according to your requirements and have also discussed it with our internal team. Since clarification regarding the ROM behavior requires confirmation from the ROM team, it took some additional time to investigate. I apologize for the delayed response and appreciate your understanding. 1. Is SRS = 0x4010 and SSRS = 0x4011 expected after a WUU wake-up from Deep Power-Down? ->> Yes.   SSRS： Stores all sources of system reset that has generated a system reset since the last MAIN cold reset and that you have not cleared. SSRS does not update following a core software reset.  SRS: Updates on every MAIN warm reset to indicate the type/source of the most recent reset. 2. Does the MCXA266 Boot ROM or Extended Bootloader issue a software warm reset before the application starts? ->> NO.  3. What is the recommended method for identifying which WUU pin caused the Deep Power-Down wake-up? ->>  For identifying the wake-up source pin, WUU_GetExternalWakeUpPinsFlag() is suitable for Power Down mode, where the WUU interrupt service routine  can execute normally. However, it  is can not used after a Deep Power-Down wake-up, because the device restarts through a reset sequence and the WUU flags have already been cleared. By the way, are you using only one wake-up pin, or do you have multiple wake-up pins enabled? Thank you. BR Alice Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hi @ka-2020  Thanks for your reply. I have escalated this issue and your requirement to our internal SE team with high priority. We fully understand the importance of this request and are actively following up on it. Please give us some time to investigate further. I will keep you updated and get back to you as soon as possible. Thank you for your patience and understanding. BR Alice Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @Alice_Yang,  Thank you for looking into this and for the clarification. Based on your explanation, it seems that the WUU flags are cleared during the Deep Power-Down reset sequence before the application starts. In my test, two WUU external wake-up pins were enabled: the original SW2 wake-up pin and WUU external wake-up pin 0. Just to confirm, does this mean that there is no software method to identify which WUU pin caused the wake-up after Deep Power-Down? Thank you. Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hi @ka-2020  Thank you for your patience. The root cause has been identified, and a fix will be implemented in future sample chip revisions. We apologize for any inconvenience caused and appreciate your understanding. Thank you. BR Alice Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @Alice_Yang , Thank you for the update. I understand that the fix is planned for a future sample chip revision. Thank you for your support.

S32K3 RTD 7.0.1 中的两个问题：未配对括号语法错误和缺少加密 XML 文件 我正在使用 RTD 版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 。运行时日志报告了一个与 featureDefined(`FEATURE_MEM_INFLS_HEADER`) 相关的未配对括号错误。两行原生 RTD 元器件存在语法错误，语句 getFeature(`FEATURE_MEM_INFLS_HEADER`) == `S32K388` 缺少右括号。 错误位置 这两行错误代码都包含 getFeature(`FEATURE_MEM_INFLS_HEADER`) == `S32K388`，并且缺少末尾的右括号： 文件路径及第 1 行：eclipse/mcu_data/components/PlatformSDK_S32K3/C40_Ip/C40_Ip.元器件第 603 行 文件路径及第 2 行：eclipse/mcu_data/components/PlatformSDK_S32K3/Mem_43_INFLS/Mem_43_INFLS.元器件第 905 行 这些语法错误存在于官方原始 RTD 组件文件中，会导致运行时功能定义解析失败。   第二个问题：加密模块文件缺失错误 我正在使用 RTD 版本S32K3_RTD_7_0_1_D2606_ASR_REL_4_9_REV_0000_20260814 ，搭配 ArchLinux 和 S32DS。eclipse/mcu_data/processors 目录下的 Crypto 模块中缺少文件。 并非所有 MCU 型号都包含两个必需的加密配置文件：PlatformSDK_S32K3/common/sdk_features_rtd_crypto.xml 和 PlatformSDK_S32K3/[MCU_MODEL]_[PACKAGE_TYPE]/resource_tables/RTD_CRYPTO/rtd_crypto_Crypto.xml。 当选择不包含上述两个文件的 MCU 型号并添加Crypto_43_HSE模块时，会触发 S32DS UI 异常和代码生成失败。手动将这两个完整的 XML 文件从其他受支持的 MCU 模型目录复制到目标模型目录，可以彻底解决此错误。 Re: Two Issues in S32K3 RTD 7.0.1: Unpaired Parenthesis Syntax Error and Missing Crypto XML Files 嗨@chenwilsoft 第一期： 谢谢你指出这一点。您说得对，C40_Ip.元器件 和 Mem_43_INFLS.元器件 文件中的`FEATURE_MEM_INFLS_HEADER`部分都存在拼写错误。 以`FEATURE_MEM_INFLS_SUPPORTBLOCK4PIPESELECT`部分为参考，似乎在featureDefined之前无意中添加了一个额外的左括号 "(" 。 作为权宜之计，您能否执行以下操作之一： 在表达式末尾添加缺失的右括号“)”“”，或者 删除featureDefined 前面多余的左括号（这将使语法与文件中其他地方使用的格式保持一致）。 由此给您带来的不便，我们深表歉意。 第二问题： 由于您正在使用 S32K3 实时驱动程序 AUTOSAR R23-11 版本 7.0.1 QLP05，请注意，此版本仅适用于 S32K3x4 和 S32K388 设备，如软件发行说明中所述。 下图高亮显示了两个不同 S32DS 3.6.x 版本中的sdk_features_rtd_crypto.xml文件。安装： Orange：安装了 RTD 7.0.1 QLP05 的 S32DS 实例。 紫色：安装了 RTD 7.0.1 P02 的 S32DS 实例。 VaneB_0-1787259680399.pngVaneB_0-1787259680399.png RTD 7.0.1 P02 代码包支持所有 S32K3 衍生产品，而 RTD 7.0.1 QLP05 是专门为 S32K3x4 和 S32K388 设备设计和验证的。 同样的道理也适用于rtd_crypto_Crypto.xml文件。7.0.1 QLP05 版本并未为所有 S32K3 衍生产品提供这些文件，因为对这些设备的支持超出了此软件包的范围。 BR，VaneB

S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on specific Device: S32K312 Toolchain: Green Hills ELXR (compiler) HSE Firmware: s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin Debugger: Lauterbach TRACE32 Software: AUTOSAR RTD-based Bootloader (FBL) + Application (APP), two-image structure ISSUE SUMMARY On a subset of production units, the CPU hangs immediately after a Functional (software) reset. The same units always boot correctly after a Destructive (power-on) reset. The hang does not reproduce on our reference/known-good units. EVIDENCE THAT AN NMI OCCURS BEFORE ANY APPLICATION CODE EXECUTES 1) CPU context captured at the hang point (auto-stacked exception frame): - R0-R3 = 0x00000000, R12 = 0x00000000 - LR = 0xFFFFFFFF (reset default -> no BL has executed yet) - PC = 0x00416904 (the very first instruction address of our Reset_Handler) - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - VECTACTIVE[8:0] = 2 -> NMI is the currently active exception - RETTOBASE = 1 This confirms the CPU is currently executing inside the NMI handler. 3) Our vector table entry for the NMI offset correctly points to our own default exception handler, so this is a genuine NMI event, not vector table corruption. REGISTERS CHECKED AT THE SAME HANG STATE (all read as clean / inactive) - MC_RGM_DES = 0x00000000 (not a destructive reset) - MC_RGM_FES = 0x20000000 (bit 29 only) (only "software functional reset" flag set, no other functional reset source flagged) - FCCU: STAT, N2AF_STATUS, A2FF_STATUS, N2FF_STATUS, NCF_S0, IRQ_STAT all = 0x00000000 - CMU_FC instances 0, 3, 4: SR = 0x00000000 (no frequency high/low fault) - PMC LVSC = 0x00000000 (no LVD/HVD flag, latched or live) - ERM (0x4025C000): could not be read on either good or failing units (likely clock-gated in our configuration), so ERM status is unverified. QUESTIONS 1. Are there any NMI sources -- other than FCCU / CMU_FC / PMC / MC_RGM -- that could fire before the application's Reset_Handler executes its first instruction? 2. Since the HSE subsystem runs independently of the application core, is it possible for an application-core Functional reset (which does not reset HSE) to create a state mismatch that triggers an NMI on the application core? 3. Is there a known errata for S32K312 matching this symptom (NMI only on functional/software reset, never on power-on reset)? Any guidance on additional registers to check, or documentation covering NMI sources outside FCCU / ERM / CMU_FC / PMC, would be greatly appreciated. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Could you please read registers MU_0.MUB CSSR0 and MU_1.MUB CSSR0 at the hang state, and confirm whether bit 0 (NMIC) is set in either of them? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to MU_0.MUB / MU_1.MUB CSSR0. CSSR0 (bit 0, NMIC) on both MU_0.MUB and MU_1.MUB reads 0x00000000 on the failing unit at the hang state, so the MU->NMI request path (CCR0[NMI] / CSSR0[NMIC]) does not appear to be pending. However, while comparing MU registers between a known-good unit and a failing unit (both captured at the identical hang-state address range), we found a consistent difference:                                Good unit Failing unit MU_0.MUB VER 0x0300000F 0x0300000F (identical) MU_0.MUB PAR 0x20200404 0x20200404 (identical) MU_0.MUB CR 0x00000000 0x00000000 (identical) MU_0.MUB SR 0x00000000 0x00000002 <- MURIP set MU_1.MUB VER/PAR/CR: identical between good and failing units MU_1.MUB SR 0x00000000 0x00000002 <- MURIP set So on BOTH MU instances, SR bit 1 (MURIP) is set only on the failing unit, consistently. Per the reference manual, MURIP indicates that "processor A" has issued an MU reset, and can only be cleared by a system reset (not by an MU reset). Since the CPU is frozen inside the NMI handler before executing any application code, it could not have cleared this flag itself, so it must have been set prior to (or as part of) this boot sequence. We'd appreciate your input on the following: 1. For MU_0.MUB and MU_1.MUB, which processor is "processor A" (i.e. who sets MURIP)? Our header only exposes the "MUB" register block at the application-core-accessible address -- does this imply the application core is always "processor B" and HSE is "processor A" for these instances? 2. Does "system reset" (required to clear MURIP) include a Functional/SW reset of the application core, or only a Destructive/POR reset? If MURIP is not cleared by our functional reset, that would explain why it stays set across SW reset while it is clear after power-on. 3. Independent of the NMI question: is a set/stuck MURIP flag itself expected or considered anomalous during normal operation? 4. Since CSSR0[NMIC] currently reads 0, is it possible for hardware to auto-clear NMIC upon NMI exception entry, or does it only clear via an explicit software write (in which case NMIC=0 would mean the MU->NMI channel was never asserted in the first place)? Thanks again for your help so far. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, I'm sorry for the delay. I was out of office for two days. 1. Yes, the HSE_B core controls the MUA interfaces of MU_0 and MU_1. 2. Any system reset should reset MURIP. 3. I would consider this an anomaly, as I do not have much information about it. 4. It requires an explicit write, as it is a W1C register. Can you make sure that HSE_B is inactive at the time the functional reset is triggered? Also, what is the state of HSE_B while the application is stuck in the NMI handler? Can you read the standard HSE GPR (0x4039_C028), FSR, and GSR registers on the MU_0 B side? Do you use the NMI pin in the application? Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi Daniel, Please find three combined register-dump screenshots attached, followed by our findings organized by your questions. -------------------------------------------------------- ATTACHMENTS -------------------------------------------------------- Attachment 1: GOOD unit (Secure Debug enabled, running normally) Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png Attachment 2: FAILING unit, immediately BEFORE the functional reset is triggered (normal operation) Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png Attachment 3: FAILING unit, AFTER the functional reset, stuck in the NMI handler (hang state) Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- FINDINGS 1) HSE_B activity at the time the functional reset is triggered, and 2) state of HSE_B while stuck in the NMI handler: Comparing Attachment 2 (before reset) and Attachment 3 (after reset, hang state) on the failing unit, every register we checked reads IDENTICALLY before and after the reset: - MU_0.MUB / MU_1.MUB TSR = 0x0000000F, RSR = 0x00000000 (no pending messages on transmit/receive channels, unchanged by the reset) - MU_0.MUB GSR = 0x00000000 (unchanged) - MU_0.MUB FSR = 0x03600000 (unchanged) - HSE GPR (0x4039C028) = 0x000001C1 (unchanged) - MU_0.MUB / MU_1.MUB SR bit 1 (MURIP) = 0x00000002 -- already set BEFORE the reset is triggered, and remains set, unchanged, after the reset So MURIP was already set prior to this reset cycle, and the functional reset itself does not change any of these HSE-related registers. For reference, on a good unit with the same Secure Debug configuration (Attachment 1), MURIP reads 0x00000000 on both MU_0.MUB and MU_1.MUB, while HSE GPR and WKPU NCR read the same values as the failing unit. 3) Regarding whether a set/stuck MURIP is anomalous: Understood, thank you for confirming. 4) NMI pin usage: We do not use the WKPU-routed NMI path (WKPU_IP_USED is not enabled; no WKPU driver code is compiled into either our bootloader or application image). WKPU NCR (0x402B4008) = 0x60000000 identically across all three attachments. NSR = 0x00000000 in all cases. Since this is unchanged across all units and conditions, we don't believe an external/WKPU-routed NMI source is involved. SUMMARY OF FINDINGS SO FAR MURIP (MU_0.MUB and MU_1.MUB SR bit 1) is already set on the failing unit BEFORE the functional reset is even triggered, and remains unchanged throughout the hang. It reads 0 on a good unit with the same Secure Debug configuration. This is the only consistent, reproducible difference we have found across every register we've compared (FCCU, CMU_FC, PMC, WKPU, and MU CSSR0/GSR/TSR/RSR/GPR/FSR). Since MURIP is set by "processor A" (HSE_B) and should be cleared by "any system reset" per your answer, and since it is already set before our functional reset is triggered (and the reset itself does not appear to change it), this suggests HSE_B issued an MU reset at some earlier point that was never cleared by a "system reset" recognized by HSE_B. QUESTIONS 1. Is there a way to determine, from the HSE side, what would cause HSE_B (processor A) to issue an MU reset in the first place? We'd like to understand why MURIP gets set at all. 2. Is there a recommended way for us to trigger a reset that HSE_B recognizes as a "system reset" (to clear MURIP) from application software, short of a full power cycle? 3. Could a stuck MURIP flag on the application-core side be related to the NMI we are observing, or are these more likely two independent symptoms of the same earlier event? Thanks again for your continued help with this. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thank you for the detailed register dumps. I have escalated the questions around MURIP behavior and the potential NMI path between HSE_B and CM7_0 to our internal HSE team, as this seems to be not documented. I will get back to you once I have their input. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek,  Thank you for the update, and for escalating the MURIP / NMI path question to your internal HSE team. We appreciate it, and we'll wait for their input. In the meantime, we found an additional data point that may be relevant, so we wanted to share it now rather than wait. While comparing OTP fields in the UTEST Flash area between a good unit and a failing unit, we found a difference in the Lifecycle slots. CUST_DEL (0x1B000220-22F) and OEM_PROD (0x1B000230-23F) are identically programmed (0x55AA50AF across all words) on both the good unit and the failing unit. The difference is in the IN_FIELD slot (0x1B000240-24F): - Good unit: begins being programmed Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - Failing unit: reads as unprogrammed (0xFFFFFFFF) Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png We are still double-checking the exact byte pattern within the IN_FIELD slot on our side, but the good/failing difference at this slot appears consistent. Could you clarify: 1. Does this suggest that the failing unit's configuration became corrupted or incomplete partway through the transition into IN_FIELD? 2. Could an incomplete or missing lifecycle advancement to IN_FIELD explain the NMI/hang behavior we have been investigating in this thread? 3. Is there a safe way to check or complete this lifecycle advancement on the failing units, without a full production re-flow? Thanks again for your help. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Based on the memory view, OEM_PROD = Inactive, IN_FIELD = Erased. Can you please first read the DCM registers: RM, rev.12, Section 39.3.1 DCM memory map. And Section 38.2.3 Read-Only GPR On Destructive Reset 3 (DCMROD3)? You can also use the HSE_FW APIs to get the LC attribute? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to the DCM memory map and DCMROD3. We captured DCMSTAT (0h), DCMLCS (8h), DCMLCS_2 (80h), and DCMROD3 (208h) on both units, and decoded them against RM rev.9. ---------------------------------------------------- CAPTURED VALUES ---------------------------------------------------- Good unit: Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 Failing unit: Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - DCMSTAT (0h) = 0x00000E03 - DCMLCS (8h) = 0x06184104 - DCMLCS_2 (80h) = 0x00000006 - DCMROD3 (208h) = 0x00400000 ---------------------------------------------------- DECODED FIELDS (FAILING UNIT ONLY, since good unit reads all-zero) ---------------------------------------------------- DCMSTAT: - bit1 DCMERR = 1 (DCM completed with error) -- good unit has this bit = 0 - bit4 DCMLCST = 0 (LC scanning status not "completed successfully") -- good unit has this bit = 1 DCMLCS: - bits 21-19 DCMLCC4 (IN_FIELD Marking) = 011b = "Region is erased/virgin" - bits 15-13 DCMLCC3 (OEM_PROD Marking) = 010b = "Marked as inactive" - bits 27-25 DCMLCC5 (Pre-FA Marking) = 011b = "erased/virgin" - All associated *_ECE/*_CFE/*_CSS bits = 0. DCMLCS_2: - bits 3-1 DCMLCC6 (FA Marking) = 011b = "erased/virgin" DCMROD3: - bit22 LC_ERR = 1 ("Error In Life Cycle Scanning") This is consistent with the UTEST OTP dump we shared earlier: the IN_FIELD slot on the failing unit reads as erased/virgin. ---------------------------------------------------- HSE_FW API RESULT (HseReadLifecycle) ON THE FAILING UNIT ---------------------------------------------------- HseReadLifecycle() returns 0x10 = HSE_LC_IN_FIELD. So from the HSE firmware's point of view, the current lifecycle is already IN_FIELD. This appears to conflict with the DCM/OTP data above: DCM's DCMLCC4 field reads IN_FIELD marking as "erased/virgin," and the UTEST OTP IN_FIELD slot (0x1B000240h onward) reads as unprogrammed (0xFFFFFFFF), yet the HSE API reports the lifecycle as confirmed IN_FIELD. We wanted to share this as-is rather than draw a conclusion, since we don't know whether HSE tracks lifecycle through a separate/secure store independent of the DCM flash marking, or whether this indicates the marking itself is the problem. Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thanks for the data. Since the IN_FIELD slot is still in the erased state, could you try setting the attribute again to advance it? As I mentioned, the case is currently under internal discussion. I will update this thread as soon as I have any new information. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Probably the HSE service responsible for advancing the Life Cycle (LC) was interrupted, leaving the LC in this state. The LC and LC Control (DCMLCC) register reports 0x77 (IN_FIELD) as the HSE_FW does, but the UTEST area is not programmed correctly. In theory, you could program the UTEST IN_FIELD slot using a debugger, which should clear the DCM error.  Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek  We tried setting the IN_FIELD attribute again on the failing unit, as suggested. Result: HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek  Thank you for the suggestion to program the UTEST IN_FIELD slot using a debugger. We checked our internal OTP field reference table, and the IN_FIELD lifecycle slot (1B00_0240-024F) is listed as write-protected for any master except HSE once LC > MCU_PROD (OEM_PROD). Since HseReadLifecycle() on this unit already reports IN_FIELD, this LC condition appears to already be met. Could you clarify how a debugger write to this slot would be expected to succeed under this protection rule? Is there a specific procedure, mode, or authentication step required for the debugger to be treated as an allowed master in this case? Separately, do you have any findings yet on why the LC advancement to IN_FIELD was left in this partial state in the first place? We'd like to understand the root cause, not just the recovery step, if that analysis is available. Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Thank you for the information. It seems there is no option to recover the MCU at this point. One possibility is that the HSE set attribute service request to advance the LC was interrupted by a system reset (I understand the LC was not advanced using the LCW within the IVT).: Do you read the HSE response of the service request? Do you log whether there was an error? Before triggering the service, do you verify that HSE_STATUS_INIT_OK is set? How many boards/MCUs are affected by this issue? Is it limited to a few units, or have you observed it across a larger number of devices? Thank you, Daniel

PIL simulation error for NXP S32K3x4EVB-Q172 Hello,  I am trying out a simple PIL simulation using the MBDT for S32K3 series version 1.1.0 on Matlab 2021b. The board I am working on is NXP S32K3x4EVB-Q172. Using SImulink SIL/PIL I was able to run a SIL successfully before going to PIL. During PIL I get the following error in Simulink. Sometimes, it also gives me an error about sending the data to board instead of receiving it as shown in the image. I also tried deploying model examples for UART provided with the MBDT such as 'S32K344_uart_async_s32ct'. The model gets deployed but on putty terminal again, no communication happens.  Please provide guidance on how I can resolve this. Thank you Simple_PIL_project_issue_cc.pngSimple_PIL_project_issue_cc.png   Re: PIL simulation error for NXP S32K3x4EVB-Q172 @mariuslucianand Is OpenSDA functionality as USB2Serial active on S32K344EVB-T172 board for running in PIL. ? I am trying to run the PIL example model, I specified the PIL configuration, model builds fine but it fails to open the serial port (please see attached error log and configuration settings).  I would really appreciate any guidance on how to resolve this.  Thanks, Re: PIL simulation error for NXP S32K3x4EVB-Q172 Hello @Saurabh9, For every Simulink model created for S32K3 MCU, our toolbox associates an S32 CT or EB tresos configuration project, which holds the board's settings and generates the configuration C code, used by the Simulink model later on, during the compile process. By default, the S32K3 toolbox associates an S32CT/EBT project, configured for the S32K344_Q257, the other evaluation board. The main difference between the S32K3x4-Q257 EVB and the S32K3x4-Q172 EVB is that the first one uses the LPUART13 while the second one, uses the LPUART6. You have two options here: 1. You can open the external configuration tools, change the package from Q257 to Q172 and configure the LPUART6, with all its dependencies( pins, interrupts) 2. You can replace the S32CT configuration file, with the s32k344_q172.mex, attached to this thread (the .mex extension here has nothing to do with the one from MATLAB, it's an S32CT format). To do so, you have to go to Hardware Implementation, Hardware and change the Default Configuration template, as shown below. mariuslucianand_0-1648251474071.pngmariuslucianand_0-1648251474071.png In both cases, you also need to specify the PIL configuration which LPUART to use, the COM port on your PC, and the Baudrate. For this, you have to go to Hardware Implementation, PIL. For me it was COM31, but this will be different on your configuration. mariuslucianand_1-1648251582058.pngmariuslucianand_1-1648251582058.png I have also attached an example. On this specific board, the OpenSDA functionality as USB2Serial is not yet fully functional, so you need to use an external USB2Serial Converter connected to the J44(1 to TX, 2 to RX) header in order for PIL to work. Simulink will deploy the generated elf file over the OSDA, and will communicate for PIL over the external USB2Serial converter.  mariuslucianand_2-1648252183459.pngmariuslucianand_2-1648252183459.png To test the example, please open the k344_q172_h_s32ct.mdl, open the referenced configuration and type your COM port for the UAB2Serial you are using. Please find all the board's schematics here https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k3x4-q172-general-purpose-development-board:S32K3X4EVB-Q172  Hope this helps, Marius

PN7150：间歇性出现 DISCOVERY_FAILED (0x60 07) 错误，且使用 FeliCa Lite‑S (RC‑S966) 时 NDEF 数据被清零 您好，我正在使用PN7150读卡器IC，并观察到FeliCa Lite‑S (RC‑S966)标签存在不稳定行为。 即使将标签直接贴在天线上，我也会看到以下重复循环： 正确的UID帧 正确的 NDEF 帧 归零 NDEF 帧 空的 NDEF 帧 0x60 07（发现失败）通知 CAN 日志示例： UID (C040041): 01 2E 54 F7 C3 59 42 3E (始终稳定) NDEF (C060041)：有时正确：D1 01 09 54 02 65 6E 48 / 65 6C 6C 6F 21；有时为零：00 00 00 00 00 00 00 00 / 00 00 00 00 00；有时为空 (DLC=0) 当标签稍远一些（仍在正常的 NFC 范围内）时，PN7150 会频繁报告 0x60 07 并重新开始发现。 我的问题是： 当 Lite‑S 暂时禁用轮询或射频场较弱时，PN7150 是否预期会报告 0x60 07？ 禁用轮询是否会导致 PN7150 返回零或空的 NDEF 数据？ 对于 PN7150 固件中的 Lite-S 轮询禁用行为，是否有推荐的处理方法？ 例如，跳过存在性检查、延迟发现重启、重试策略 是否有专门针对 FeliCa Lite‑S 行为的 PN7150 应用笔记？ canAnalyzer3 Mini 概览如下： “编号”;“时间（绝对值）”;“状态”;“ID（十六进制）”;“DLC”;“数据（十六进制）”;“ASCII” “3.261”;“34505.380”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.262”；“34505.381”；“E”；“C040041”；“2”；“00 F1”；“..” “3.263”；“34506.401”；“E”；“C060041”；“0”；“”；“” “3.264”;“34506.645”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.265”；“34506.646”；“E”；“C040041”；“2”；“00 F1”；“..” “3.266”；“34506.894”；“E”；“C060041”；“0”；“”；“” “3.267”;“34507.143”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.268”；“34507.143”；“E”；“C040041”；“2”；“00 F1”；“..” “3.269”；“34507.389”；“E”；“C060041”；“0”；“”；“” “3.270”;“34507.930”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.271”；“34507.931”；“E”；“C040041”；“2”；“00 F1”；“..” “3.272”;“34508.979”;“E”;“C060041”;“8”;“00 00 00 00 00 00 00 00”;“........” “3.273”;“34508.980”;“E”;“C060041”;“5”;“00 00 00 00 00”;“.....” “3.274”;“34509.222”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.275”；“34509.222”；“E”；“C040041”；“2”；“00 F1”；“..” “3.276”;“34509.467”;“E”;“C060041”;“8”;“00 00 00 00 00 00 00 00”;“........” “3.277”;“34509.468”;“E”;“C060041”;“5”;“00 00 00 00 00”;“.....” “3.278”;“34509.713”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.279”；“34509.714”；“E”；“C040041”；“2”；“00 F1”；“..” “3.280”;“34509.959”;“E”;“C060041”;“8”;“00 00 00 00 00 00 00 00”;“........” “3.281”;“34509.960”;“E”;“C060041”;“5”;“00 00 00 00 00”;“.....” “3.282”;“34510.495”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.283”；“34510.496”；“E”；“C040041”；“2”；“00 F1”；“..” "3.284";"34511.516";"E";"C060041";"0";"";"" “3.285”;“34511.759”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.286”；“34511.760”；“E”；“C040041”；“2”；“00 F1”；“..” “3.287”；“34512.005”；“E”；“C060041”；“0”；“”；“” “3.288”;“34512.251”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.289”；“34512.252”；“E”；“C040041”；“2”；“00 F1”；“..” “3.290”；“34512.497”；“E”；“C060041”；“0”；“”；“” “3.291”;“34512.739”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.292”；“34512.739”；“E”；“C040041”；“2”；“00 F1”；“..” "3.293";"34512.985";"E";"C060041";"8";"D1 01 09 54 02 65 6E 48";"...T.enH" “3.294”;“34512.986”;“E”;“C060041”;“5”;“65 6C 6C 6F 21”;“你好！“ “3.295”;“34513.231”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.296”；“34513.232”；“E”；“C040041”；“2”；“00 F1”；“..” "3.297";"34513.477";"E";"C060041";"8";"D1 01 09 54 02 65 6E 48";"...T.enH" “3.298”；“34513.478”；“E”；“C060041”；“5”；“65 6C 6C 6F 21”；“你好！” “3.299”;“34513.724”;“E”;“C040041”;“8”;“01 2E 54 F7 C3 59 42 3E”;“..T..YB>” “3.300”；“34513.724”；“E”；“C040041”；“2”；“00 F1”；“..”

imx93 m33 sdk ethosu_apps_rpmsg：如何获取模型结果？ 在 SDK 版本 26 中。ethosu_apps_rpmsg 没有显示从 ethosu 获取结果的方法。 怎么做？ InferenceProcess::InferenceJob job("job", networkModel, ifm, ofm, expectedOutput, pmuEventConfig, 0, &ethosu_drv, 0, nullptr, 0, 0, false); job.invalidate(); InferenceProcess::InferenceProcess inferenceprocess(inferenceProcessTensorArena, TENSOR_ARENA_SIZE); bool failed = inferenceprocess.runJob(job); job.clean(); 我该如何获得这个计算结果？ Re: imx93 m33 sdk ethosu_apps_rpmsg: how to get the result of model? 推理结果位于传递给作业的OFM 缓冲区中——即构造函数中的 ofm。expectedOutput 仅适用于 SDK 示例的验证路径；它不是计算结果的返回位置。i.MX93 Ethos-U 流程将完成的推理结果写入输出特征图缓冲区，并且在 Linux/RPMSg 流程中，在 OFM 填充后将响应发送回 Cortex-A。 对于你的代码来说，最重要的部分是： InferenceProcess::InferenceJob job( “工作” 网络模型 ifm， ofm, // <-- 输出缓冲区 expectedOutput, // <-- 参考/验证数据，而非结果 pmuEventConfig， 0， &ethosu_drv， 0，     nullptr， 0， 0， 错误的）; job.invalidate(); bool failed = inferenceprocess.runJob(job); job.clean(); 如果（!失败） { // 从 ofm 读取结果 } 从概念上讲： 复制 如果（!失败） {     // 输出张量 0 uint8_t *outputData = ofm[0].data(); size_t outputSize = ofm[0].size(); for (size_t i = 0; i < outputSize; i++)     { PRINTF("ofm[%u] = %d\r\n", i, outputData[i]);     } } 根据 ofm 的具体 SDK 类型，访问方式可能会略有不同，但规则相同：从传递给 InferenceJob 的同一个 ofm 缓冲区读取。 如果您的模型输出是量化的，则 ofm 中的字节通常是 int8_t 或 uint8_t，而不是最终的浮点值。使用输出张量的量化参数进行转换： float real_value = (quantized_value - zero_point) * scale; 例如，对于 int8 输出： int8_t *out = reinterpret_cast (ofm[0].data()); for (size_t i = 0; i < outputSize; i++) { float y = (static_cast (out[i]) - output_zero_point) * output_scale; PRINTF("out[%u] q=%d real=%f\r\n", i, out[i], y); } 以RPMsg为例，请记住 ethosu_apps_rpmsg 主要是一个 Cortex-M33 固件服务。它接收来自 Cortex-A 的请求，运行 Ethos-U 作业，将结果写入 OFM 缓冲区，并通过 RPMsg 返回响应。在 Cortex-A/Linux 端，记录的 API 路径是访问 OFM 缓冲区，例如 inf->getOfmBuffers()。 所以： M33 端直接测试： runJob() 成功完成后读取 ofm[0]。 A-core/Linux RPMsg 推理：从 Linux 端推理对象的 OFM 缓冲区获取输出，而不是从 ethosu_apps_rpmsg 控制台输出获取输出。 不要将 expectedOutput 用作结果；它只是样本用于比较正确性的黄金/参考输出。 您的计算结果已在 ofm 中；成功运行 runJob(job) 后，读取 ofm[0] 并根据模型的输出张量类型对其进行解释/反量化。

Wi-Fi Chipset MCU Control Hello everyone, I was browsing for some wifi modules with AP+STA functionalities. I found some modules from NXP, Microchip, and Infineon for example. However, most of the modules are only enabling wifi interface through PCIe and with advanced OS. However, I found a set of MCU+Wifi module from infineon called AIROC CYW55X (series). Do you have any experience integrating and controlling these type of modules? If so, can you share different modules that you have used before and were able successful to integrate with an external MCU? My intention is not to offload data to the microcontroller, only to control for example the mesh and AP capabilities. I want to use a MCU (STM for example) to perform some inference on some basic AI models while controlling the wifi module. Thanks guys Re: Wi-Fi Chipset MCU Control Hi, If you are planning to use an STM32 as the host MCU, I would recommend using an IW612 or IW416 as the Wi-Fi device. In that case, you can use the STM32 CMSIS-Pack drivers available in the Software section of the product webpage. These devices use SDIO for Wi‑Fi and UART for Bluetooth. For the IW612, if you also plan to use 802.15.4, the host interface is SPI. Another option is to use an RW612 as a Network Co-Processor (NCP). Since the RW612 is a wireless MCU, it can handle the wireless connectivity stack while the external MCU focuses on the application. Regards, Daniel Re: Wi-Fi Chipset MCU Control As Daniel mentioned, RW612 would be a good solition. It is  3-radio, and also has a built-in Ethernet MAC - ideal for making network enabled applications. RW612 can do AP+STA. So you can use that MCU for both network-control and your AI functionality. If you're looking for a ready-to-build project with Web UI and built-in OTA, take a look at https://mongoose.ws/wizard/ Start a project, choose empty directory, choose FRDM-RW612 as a board target,  set WiFi options, click "generate" , open project  in Xpresso, build & flash, attach your serial console, and you'll have it running in a minute. Could you elaborate more on what exactly you're building?