MCX C Knowledge Hub The MCX C series MCUs, powered by Arm® Cortex®-M23 up to 72 MHz or Arm® Cortex®-M0+ up to 48 MHz, are designed for cost effectiveness and efficiency, making them ideal for low-end Industrial and IoT applications. Featuring precision analog peripherals as well as USB and segment LCD options, these MCUs cater to diverse needs. The MCX C Series extends the classical IPs within NXP MCUs, providing flexible and scalable memory and packages. MCX C MCUs offer features like USB and segment LCD support, making them ideal for a wide range of general-purpose applications. With a focus on versatility, these MCUs provide the performance and scalability needed for today’s evolving technology demands. Documents: MCX C Series  MCX C Fact Sheet MCX C Series Products MCX C04x:  The MCX C04x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer 32 KB Flash, 2 KB SRAM, and 8 KB boot ROM. Designed as entry-level MCUs, they prioritize simplicity and ease of use for a variety of applications. Key peripherals include a 12-bit ADC, comparator and multiple-channel timer/PWM modules. The enhanced low-power architecture ensures efficiency, with static power consumption as low as 2.2 μA and a 7.5 μs wake-up time for full retention. In deep sleep, static mode power consumption drops to just 77 nA. This series supports scalable memory options and flexible packaging, accommodating diverse application needs. Documents: MCX C041 Sub-Family Reference Manual Data Sheet - MCX C04X Errata: MCXC041 Mask Set MCX C14x/C24x/C44x: The MCX C14x/24x/44x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer a range of memory configurations, from 32KB to 256KB Flash and up to 32KB SRAM, with 16KB Boot ROM. These entry-level MCUs are optimized for cost-sensitive and battery-powered applications requiring low-power USB connectivity and segment LCD support. The FlexIO technology enables customization for various serial peripheral emulation needs. They feature optimized low-power modes, achieving efficiency down to 54uA/MHz in very low-power run mode and 1.96 uA in deep sleep mode with retained RAM and RTC. Documents: Data Sheet - MCX C24x/C14x Data Sheet - MCX C44x Errata:  MCXC - x41 x42  Errata: MCXC - x43 x44 MCX C44x Sub-Family Reference Manual MCX C24x Sub-Family Reference Manual MCX C15/C16: The MCX C15 and MCX C16 microcontrollers (MCUs) are low‑cost, entry‑level devices featuring an Arm® Cortex®‑M23 core running at up to 72 MHz, with memory configurations offering up to 64 KB of flash memory and 16 KB of static random‑access memory (SRAM). These devices bring precision analog and control peripherals into the low‑cost, entry‑level MCU class, making advanced features—such as a 16‑bit analog‑to‑digital converter (ADC), comparator with digital‑to‑analog converter (DAC) and flexible pulse‑width modulation (FlexPWM) for motor control—accessible to cost‑sensitive IoT applications. Designed as an upgrade path from legacy 8‑bit and 16‑bit MCUs, as well as devices based on Arm Cortex‑M0+ cores, this entry‑level 32‑bit MCU series delivers higher performance and greater scalability without increasing costs. Documents: Data Sheet -MCX C151/C161/C162  Fact Sheet - MCX C1 Family Reference Manual - MCX C15/C16  Boards: FRDM MCX C444: FRDM-MCXC444 is a compact and scalable development board for rapid prototyping of MCX C444 MCU. It offers industry-standard headers for easy access to the MCU's I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger.  FRDM-MCXC444 QSG Getting Started with FRDM-MCXC444 FRDM-MCXC444 Board User Manual FRDM MCX C242: FRDM-MCXC242 is a compact and scalable development board for rapid prototyping of MCX C242 MCU. It offers industry standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and on-board MCU-Link debugger. FRDM-MCXC242 QSG Getting Started with MCXC242  FRDM-MCXC242 Board User Manual  FRDM-MCX C041:  is a compact and scalable development board for rapid prototyping of MCX C041 MCU. It offers industry-standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger. FRDM-MCXC041 QSG Getting Started with FRDM-MCXC041 FRDM-MCXC041 Board User Manual MCX C to FRDM Board Mapping Supported MCU(s) Recommended Board Best fit for  Key Differentiators MCXC041 (16QFN, 24QFN) FRDM-MCXC041 Ultra-Low-cost entry-level designs  32KB flash - 2KB SRAM- 48MHz Cortex M0+ - LPUART - SPI - I2C - ADC MCX C141/ C142/ C241/ C242 /C441 /C442 / C444 FRDM-MCXC444 General-purpose USB and Segment LCD application Industrial / Consumer Up to 256KB Flash - 32KB SRAM - 48MHz Cortex-M0+ - USB FS 2.0 - SLCD - FlexIO - DMA 0 CAN-FD - Multiple UART/SPI/I2C MCX C151/ C152/ C161/ C162 FRDM-MCXC162 Motor Control Precision analog Power tools    medical devices Up to 64KB flash - 16KB SRAM - 72MHz Cortex-M23 - 16-bit ADC 2.4MSPS - FlexPWM - 4xUART - 45 GPIO   Application Notes: Software, Hardware and Peripherals: AN14321 Using Segment Liquid Crystal Displays (SLCD) Controller on MCX C444 MCU: This document describes the usage of the on-chip SLCD controller by enabling an SLCD device called S401M16KR. The S401M16KR is a four-digit 0.17-inch seven-segment LCD panel. AN14590 Running RT-Thread on MCUXpresso IDE: This document is intended for the users who are familiar with RT-Thread and want to port it to MCUXpressoIDE. It provides steps to streamline the porting process. The porting steps are applicable to other NXP chips also. This document uses FRDM-MCXC444 as an example. AN14319 FlexIO Emulating UART with IRDA: This application note introduces how to use the universal peripheral module FlexIO for emulating the UART bus with IRDA. The FlexIO peripheral, initially introduced on the MCXC242 and MCXC444 family, is a highly configurable module capable of emulating a wide range of different communication protocols. These communication protocols include UART, I2C, SPI, I2S, and so on. AN14322 USB to multi VCOM on MCX C444 Series MCU: This document describes how to implement a USB to functions of multiple VCOMs on MCX C444 series FRDM boards. AN14349 Emulating I2C Bus Controller by using FlexIO on MCX C: This application note lists the steps to use the FlexIO module for emulating the I2C bus controller Power Management:  AN14811 Estimated Power-on Hours for the MCX C04x, MCX C14x, MCX C24x and MCX C44x: This document describes the estimated product power-on hours (PoH) for the MCX C04x, MCX C14x, MCX C24x, and MCX C44x industrial MCUs. It uses the criteria from the qualification process. AN14332 MCX C444 Power Mode Switch Application: This application note focuses on the power management controller (PMC), system mode controller (SMC), Multipurpose Clock Generator Lite (MCG-Lite), and Low-Leakage Wakeup Unit (LLWU). Training: Design without Bounds FRDM Training and Resources FRDM Training Hub MCX C15/C16 Product Training Useful Links: FRDM Boards Enclosures (3D Print) MCX C:  How to Enter the ROM Bootloader to Update the firmware MCUXPresso for Visual Studio Code - MCX MCUXpresso Config Tool for MCUXpresso IDE MCUXpresso Config Tool for 3rd party IDE Download Firmware to MCX microcontrollers over USB, I2Cm UART, SPI, CAN Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here    MCXC

i.MXRT1176 上的 WiFi (SDIO) 断开连接与 Qt/QML UI 的复杂性相关 大家好， 我们目前正在研发一款具有屏幕镜像功能的仪表盘。在我们的架构中，配套的移动应用程序通过 Wi-Fi 将帧流传输到我们的主机 MCU。数据通过 SDIO 连接的 Wi-Fi 模块接收，使用 FFmpeg 解码，并在显示屏上呈现。我们的网络协议栈采用 lwIP，集群 HMI 的 MCU 采用 Qt。 系统规格： 主机MCU： NXP i.MX RT1176 Wi-Fi 模块： u-blox MAYA-W161（SDIO 接口） 显示屏： LCDIFV2（并行RGB接口） 操作系统： FreeRTOS 问题：我们遇到了间歇性的 Wi-Fi 断开连接问题，这似乎与图形负载直接相关。只有当显示器运行资源密集型 GUI（包含大量元素和动画）时，才会出现 Wi-Fi 掉线的情况。切换到轻量级用户界面后，Wi-Fi 连接依然非常稳定。 请指导我们如何解决这个问题。 此致， 维格内什 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 你好@Vignesh_VInayak ，希望你一切都好。 由于图像处理需要较高的 CPU 使用率和较大的内存占用，因此对于 GUI 相关应用程序，两个核心中的一个将是专用的，用于管理界面。请问您的实现方案是否使用了两个核心？每个线程是否有专用的堆栈空间？ 此外，能否请您提供已启用调试日志记录的 Wi-Fi 协议栈日志，以便我们进一步分析 Wi-Fi 线程的状态？要启用调试日志，请在wifi_config.h 文件中启用“CONFIG_WLCMGR_DEBUG”和“CONFIG_WIFI_SDIO_DEBUG”宏。头文件？ Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 嗨@RomanVR ， 感谢您如此迅速地回复我。 请查看下方所需详细信息和日志： 目前，我们的项目只使用 Cortex-M7 内核；没有使用 M4 内核。 是的，所有线程都已分配了足够的堆栈空间。我们还使用 FreeRTOS 堆栈溢出钩子函数验证了这一点，没有发生溢出。 我已附上启用建议宏后的日志文件。在日志中，最后一个 wlcm 日志之后的所有内容都是我们的应用程序日志，每当收到 Wi-Fi 数据包时，这些日志都会打印一些随机帧大小。如您所见，日志在某个点停止了——这就是 Wi-Fi 断开连接发生的地方。断开连接的那一刻，我们没有看到来自 wlcm 或 SDIO 的任何日志。 此致， 维格内什。 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 你好@Vignesh_VInayak ， 请问断开连接后，应用程序的其他部分（包括显示）是否还能正常运行？如果情况属实，能否请您分享一下您的线程优先级配置？ 关于前面的问题，能否请您分享一下正在运行的线程的 FreeRTOS 运行时统计信息？ 为此，您需要在FreeRTOSConfig.h中启用“configGENERATE_RUN_TIME_STATS”。文件并定义一个任务，定期调用 FreeRTOS API“vTaskGetRunTimeStats”，并将结果打印到终端。这将提供有关每个线程 CPU 使用率的有用信息，并缩小 Wi-Fi 断开连接的根本原因范围。与此相关的是，由于显示应用程序会导致较高的 CPU 负载，因此强烈建议采用双核架构，以确保高负载应用程序的正确执行。

Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G274A hello expert We are investigating an unexpected dependency between QuadSPI and the PFE HIF data path on an S32G274A running QNX 7.1. If QuadSPI is not initialized, PFE0 and PFE2 complete PHY, EMAC, firmware, and HIF initialization successfully. The EMAC can receive valid frames, but the HIF DMA does not consume TX or RX descriptors, so packets are not transferred between PFE and DDR, and ARP/ping fails. After reducing the QuadSPI initialization sequence step by step, we found that a single write is sufficient to restore PFE communication: writing 0x020F000C to the QuadSPI Module Configuration Register, QuadSPI_MCR at offset 0x0000 from QuadSPI base address 0x40134000—that is, physical address 0x40134000. If this write is removed, PFE communication consistently fails. Flash identification, JEDEC transactions, the QNX F3S framework, /dev/fs0, and startup delay have all been excluded as necessary conditions. Our current interpretation is that the relevant effect may be clearing QuadSPI_MCR[MDIS] to 0, which enables the QuadSPI clocks. Could you please confirm whether clearing QuadSPI_MCR[MDIS] can activate any clock request, bridge, or interconnect state shared with the PFE HIF DMA-to-DDR/XBAR/NoC path on S32G274A? Is there any undocumented or indirect dependency between PFE HIF DDR access and the QuadSPI clock or interconnect state, or could this indicate a missing shared-clock/NoC initialization step during platform startup? Which MC_CGM, RDC, MC_ME, NoC, or PFE platform register should be configured to establish the required state independently, instead of having the PFE driver access the QuadSPI MCR? We are currently performing complementary tests to confirm whether clearing MDIS alone is both necessary and sufficient; at this stage, the confirmed trigger is the complete MCR write value 0x020F000C. Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Thank you for contacting us. 1. Are you using a customer board? 2.What is your PFE version? BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, Yes, we are using a custom board based on the S32G274A. PFE0 and PFE2 are connected through RGMII to KSZ9031 PHYs. The operating system is QNX 7.1. The PFE software versions are as follows: - NXP PFE QNX driver version: PFE-DRV_S32G_QNX_1.9.0 - PFE firmware version: PFE-FW_S32G_1.12.0 - PFE hardware version reported by the driver: 0x00050300 Please let me know if you need the complete startup log, clock configuration, schematic section, or register dump for comparison. Best regards, Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi, Thank you for your reply. 1.What is your method of S32G booting? Was there no initialization of QSPI in the early stage? 2.Try operating only the MDIS bit to see if it affects the results. BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, 1. We load the QNX IFS and DTB via TFTP in U-Boot and start QNX with bootm. QNX is not loaded from QSPI Flash. Before starting the PFE driver, QNX does not start devf-qspi-s32g or explicitly initialize the QuadSPI controller. 2. We tested the MDIS bit using read-modify-write operations on the QuadSPI Module Configuration Register (QuadSPI_MCR, base address 0x40134000, offset 0x0000). Test A — No QuadSPI MCR operation The QSPI driver was not started and QuadSPI_MCR was not written. PFE communication failed. Test B — Set only MDIS MCR before = 0x030F00CC MCR write = 0x030F40CC MCR after = 0x030F40CC MDIS = 1 PFE Communication successful Only MDIS, bit 14, was changed from 0 to 1. The QSPI Flash filesystem was not started, /dev/fs0 was not created, and no JEDEC access was performed. The test program exited normally after the register operation. Test C — Clear only MDIS The initial MDIS value was already 0, so the unchanged MCR value 0x030F00CC was written back. PFE communication failed. We also previously tested writing the complete value 0x020F000C to QuadSPI_MCR. PFE communication succeeded in that case. Could you please advise why setting only the QuadSPI MCR MDIS bit from 0 to 1 affects PFE0/PFE2 communication on S32G274A? Is there any required initialization sequence, known erratum, or documented dependency between QuadSPI MCR operations and the PFE HIF/DMA-to-DDR path? BR, Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Thank you for your reply. I am currently conducting an internal investigation into this matter for you. I will get back to you with the progress! BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Sorry for the late reply. Based on internal information and discussions with experts, there is no special dependency  between QSPI and PFE. It is recommended to check the issue through the following methods.  1. At the ATF/uboot initial stage and the QNX stage, disable QSPI. 2. Test the functionality of PFE during the U-boot stage. 3. If you need further assistance, if you could share some of your resources. For instance, you could provide an Image that can reproduce your problem. Please use the following link for posting you resource:https://support.nxp.com BR Joey

S32K358 HSE API 导致 RESET 并报告 HSE_ERR_GENERAL 您好， 我们的项目使用 S32K358 芯片，搭配 HSE B 固件和 AB 模块。 执行 HSE API 获取属性原因 RESET 时发生问题。 调试过程中，在执行 API 之前，FSR 是正常的。 image.pngimage.png 执行 Mu_Ip_SetTxRegister 设置 MU0 TR[1] 寄存器后，2 个寄存器报告错误 FSR 状态为 0F600002 表示通道 #1 正在执行中 image (6).png图像 (6).png GSR 状态为 67030001 表示 HSE_ERR_GENERAL image 8.png图片 8.png 我检查了其他程序，HSE API 工作正常。执行 Mu_Ip_SetTxRegister 设置 MU0 TR[1] 寄存器后，两个寄存器都正常。 FSR状态为0F600000 GSR状态为00000000 如何解决这个问题？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好，我们已经检查过了，问题并非出在中断上。它来自“看门狗”组织。我们禁用了看门狗，但没有发生RESET。谢谢。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 你好， 这个案子有任何进展吗？ 我也遇到了同样的问题。使用HSE固件将MCU S32K324生命周期推进到OEM_PROD后，1秒后MCU被重置？ 提前致谢 阿尤布。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您的新案件已分配给区域 FAE 团队，因此我建议将后续步骤和调查工作交给他们，以避免重复劳动。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 在推进 HSE LC 时，我使用的是 Trace32。可能是测量时间不正确。抱歉。 尝试几次解锁调试端口后，Trace32 报告 ECU 不断 RESET。即使我关闭/重新打开电路板的电源，ECU 仍然处于 RESET 状态。 HaiHoangSoftware_0-1752114844597.pngHaiHoangSoftware_0-1752114844597.png 如何知道发生的是哪种类型的RESET（破坏性RESET/功能性RESET）并检查根本原因？ 调试端口在 LC IN_FIELD 中受到保护。由于这个问题，我无法使用调试脚本解锁调试端口。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 如果晚1秒发生，那可能是什么情况都有可能。而且它可能与生命周期的推进无关。我需要更多关于此问题的信息。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 重置后，HSE 立即锁定了调试端口，因为 HSE 生命周期变为 IN_FIELD。 RESET 后无法立即读取 RGM FES 和 DES 寄存器。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 你知道RESET的原因是什么吗？复位后你检查过RGM FES和DES寄存器吗？ 如果安装了 HSE 固件，则无法使用 LC 配置字推进生命周期。可以取任何值，安装 HSE 固件时将忽略该值。在这种情况下，只有通过 HSE 服务才能推进生命周期。 问候， 卢卡斯 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好， 我以同步模式执行了这些命令。 奇怪的是，当我调用 set attribute 来编程 ADPK 并配置调试授权模式时，ECU 执行正常。 只有当我调用 set attribute 来更改 HSE LifeCycle 时，API 才不会返回错误，但 1 秒钟后，程序突然 RESET。 在推进 HSE 生命周期之前，我是否需要设置 Address LC 配置字？ HaiHoangSoftware_0-1751869464437.pngHaiHoangSoftware_0-1751869464437.png 如果LC配置字的值为0x00000000，会发生什么情况？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好， 我以同步模式执行了这些命令。 奇怪的是，当我调用 set attribute 来编程 ADPK 并配置调试授权模式时，ECU 执行正常。 只有当我调用 set attribute 来更改 HSE LifeCycle 时，API 才不会返回错误，但 1 秒钟后，程序突然 RESET。 在推进 HSE 生命周期之前，我是否需要设置 Address LC 配置字？ HaiHoangSoftware_0-1751595287949.pngHaiHoangSoftware_0-1751595287949.png 如果 LC 配置字中的值为 0x00000000 会怎样？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 我的建议是同步运行该命令，以避免中断问题。 命令由函数 Hse_Ip_ServiceRequest 触发。异步方法的实现顺序如下： lukaszadrapa_0-1751363963705.pnglukaszadrapa_0-1751363963705.png Mu_Ip… 函数是内联的，所以没有问题。但是 BaseNXP 模块中的 OsIf 函数没有内联，所以您也需要移动它们。 此致， Lukas Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好， 这些 API 位于 Block 1 中，地址为 0x0060FB3E。 这样执行起来是否足够安全？ 有什么原因需要RESET ECU吗？ HaiHoangSoftware_0-1751350485291.pngHaiHoangSoftware_0-1751350485291.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 嗯，还漏了一句话：UTEST闪存是在生命周期推进时由HSE进行编程的。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 该设备不应该自动RESET。这很可能是由读写错误引起的。闪存块之间支持边读边写。但是请注意，闪存块 0 和 UTEST 位于同一分区中。 如“表102”所示。Flash 块配置”和 S32K3 参考手册中的“21.3 UTest NVM 扇区”。 还有第 14.6.5 节HSE-B 固件参考手册中的“同步 HSE 和应用程序核心之间的闪存读/写访问”对于进一步开发可能很重要。 解决方法是从 RAM 或其他闪存块执行代码。 此致， Lukas Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好， 我通过将设置属性 API 的输入参数设置为全局易失性变量来解决此问题。 但是，在成功执行 API 更改生命周期后，ECU 会自动 RESET。 我们计划将变更生命周期作为 UDS 服务来实现，但如果 HSE 固件自动 RESET ECU，则似乎无法实现。 更换ECU生命周期后，我需要做些什么才能使其正常运行？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好， 按照 NXP 的演示应用程序，我实现了一个使用 Set_Attr 服务推进 LC 的功能，包括以下 3 个步骤： ADKP计划 将调试授权模式更改为密码 高级 HSE LC 步骤 1、2 使用Mu0实例和1 个空闲通道正常执行。 步骤 3 始终报告 FSR= 0x0f600002 和 GSR=67030001 以下是否需要任何步骤： 备用 IVT 地址LC配置字 我还需要做些什么才能晋级LC？ HaiHoangSoftware_0-1751280488672.pngHaiHoangSoftware_0-1751280488672.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 您好@HaiHoangSoftware HSE_ERR_GENERAL 最常见的原因是 HSE 服务参数中提供的地址无效。要么是指向未实现内存空间的完全无效地址，要么是由于 XRDC 配置，HSE 无法访问该内存，要么是该内存中存在多位 ECC 错误。 也可能是数据缓存导致的——请确保禁用数据缓存，或者强制将用于与 HSE 通信的所有内存资源设置为不可缓存的内存。 如果在使用 HSE_SRV_ID_GET_ATTR 服务时遇到此类错误，请检查 pAttr 地址并禁用数据缓存以进行测试： lukaszadrapa_0-1751023995011.pnglukaszadrapa_0-1751023995011.png 此致， Lukas

i.MXRT1176におけるWiFi（SDIO）切断は、Qt/QML UIの複雑さと相関関係がある。 チームの皆さん、こんにちは。 現在、画面ミラーリング機能を搭載したインストルメントクラスターの開発に取り組んでいます。私たちのアーキテクチャでは、対応するモバイルアプリがWi-Fi経由でホストMCUにフレームをストリーミングします。データはSDIO接続のWi-Fiモジュールを通じて受信され、FFmpegでデコードされ、ディスプレイ上でレンダリングされます。ネットワークスタックにはlwIPを、クラスタHMI用のMCUにはQtを使用しています。 システム仕様： ホストMCU: NXP i.MX RT1176 Wi-Fiモジュール: u-blox MAYA-W161(SDIOインターフェース) ディスプレイ: LCDIFV2(パラレルRGBインターフェース) OS: FreeRTOS 問題点：グラフィック処理の負荷と直接関係していると思われる、断続的なWi-Fi接続切断が発生しています。Wi-Fi接続が切断されるのは、ディスプレイがリソースを大量に消費するGUI（多数の要素やアニメーションを含む）を実行している場合のみです。軽量なUIに切り替えても、Wi-Fi接続は完全に安定します。 この問題を解決するためのご指導をお願いいたします。 よろしくお願いいたします。 ヴィグネシュ Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity こんにちは、 @Vignesh_Vinayak さん。お元気でお過ごしでしょうか。 画像プロセッシングは高いCPU使用率と大きなメモリ使用量を必要とするため、GUI関連アプリケーションでは、2つのコアのうち1つがインターフェース管理に専用であることが想定されています。貴社の実装方法では、2つのコアを使用しているかどうかを明確にしていただけますか？各スレッドごとに十分なスタックがありますか? さらに、Wi-Fiスタックでデバッグログを有効にした状態でログを共有していただけますか?Wi-Fi Threadの状態をさらに分析するために。デバッグログを有効にするには、wifi_config.hの「CONFIG_WLCMGR_DEBUG」と「CONFIG_WIFI_SDIO_DEBUG」マクロを有効にしてくださいヘッダーファイル？ Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity こんにちは、 @RomanVR さん。 こんなに早く返信してくれてありがとうございます。 ご依頼いただいた詳細情報とログは以下のとおりです。 現在、私たちのプロジェクトはCortex-M7コアのみを使用しています。M4コアは利用されていません。 はい、すべてのスレッドには十分なスタックが割り当てられています。また、FreeRTOSのスタックオーバーフローフック関数を使用して確認したところ、オーバーフローは発生していませんでした。 提案されたマクロを有効にしたログファイルを添付しました。ログ内には、最終的なWLCMログ以降に表示されるすべてのログがアプリケーションログで構成されており、Wi-Fiパケットが受信されるたびにランダムなフレームサイズを単に印刷します。ご覧の通り、ログはある時点で止まります。そこでWi-Fiが切断されます。接続が切断された時点では、wlcmからもSDIOからもログは出力されていません。 よろしくお願いします、 ヴィグネシュ。 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity こんにちは、 @Vignesh_Vinayak さん。 切断が起きた後、ディスプレイを含む他のアプリケーションは正常に動作しているのか教えていただけますか?もしそうなら、スレッドの優先度設定を共有していただけませんか? 前の質問に関連して、実行中のスレッドのFreeRTOSランタイム統計を共有していただけますか? そのためには、 FreeRTOSConfig.hで「configGENERATE_RUN_TIME_STATS」を有効にする必要があります。ファイルを作成し、FreeRTOS API「vTaskGetRunTimeStats」を定期的に呼び出し、結果をターミナルに出力するタスクを定義します。これにより、各ThreadのCPU使用率に関する有用な情報が得られ、Wi-Fi切断の根本原因を絞り込むことができます。これに関連して、ディスプレイアプリケーションは高いCPU負荷を引き起こすため、高負荷アプリケーションの適切な実行を確保するためにデュアルコアアーキテクチャの実装が強く推奨されます。

S32K358 HSE API がリセットを引き起こし、HSE_ERR_GENERAL を報告します。 こんにちは、 私たちのプロジェクトでは、ABブロックを備えたHSE Bファームウェアを搭載したS32K358を使用しています。 属性原因リセットを取得するためにHSE APIを実行した際に問題が発生しました。 デバッグ中、APIを実行する前はFSRは正常です image.pngimage.png Mu_Ip_SetTxRegisterを実行してMU0 TR[1]レジスタを設定した後、2つのレジスタがエラーを報告しました。 FSRステータスが0F600002であれば、チャネル#1の実行が進行中であることを意味します image (6).png画像（6）.png GSRステータスは67030001で、HSE_ERR_GENERALを意味します。 image 8.png画像8.png HSE APIが正常に動作する他のプログラムを確認したところ、MU0 TR[1]レジスタを設定するためにMu_Ip_SetTxRegisterを実行した後、2つのレジスタは正常でした。 FSRステータスは0F600000です GSRステータスは00000000です この問題を解決するにはどうすればよいでしょうか？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは。既に確認済みですが、問題は割り込みに起因するものではありません。それはウォッチドッグからの情報です。ウォッチドッグを無効にしたところ、リセットは発生しなくなりました。ありがとう。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 その件について何か進展はありますか? 私も同じ問題に直面しています。MCU S32K324はHSEファームウェアでライフサイクルを進めてから1秒でリセットされたOEM_PROD? 前もって感謝します アユーブ。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 新しいケースは地域のFAEチームに割り当てられているので、重複を避けるために次のステップや調査は彼らに任せることをお勧めします。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL HSE LCの開発を進める頃には、私はTrace32を使用していた。測定時間が正確でない可能性があります。申し訳ありませんでした。 デバッグポートのロック解除を何度か試みた後、Trace32はECUが継続的にリセットされていると報告する。基板の電源をオン/オフしても、ECUはリセット状態のままです。 HaiHoangSoftware_0-1752114844597.pngHaiHoangSoftware_0-1752114844597.png どのような種類のリセット（破壊的リセット／機能的リセット）が発生しているかを把握し、根本原因を特定するにはどうすればよいですか？ デバッグポートはLC IN_FIELDで保護されています。この問題のせいでデバッグスクリプトでデバッグポートをアンロックできません。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL もし1秒遅れて起きたら、何でもあり得ます。そして、ライフサイクルの進行とは無関係の場合もあります。問題についてもっと詳しい情報が必要です。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL リセット直後、HSEのライフサイクルがIN_FIELDに変更されたため、HSEはデバッグポートを保護しました。 リセット直後にRGMのFESおよびDESレジスタは読み取れません。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL リセットの原因は何だったかご存知ですか？リセット後にRGM、FES、DESレジスタを確認しましたか？ HSEファームウェアがインストールされている場合、LCコンフィギュレーションワードを使用してライフサイクルを進めることはできません。どんな数値でも構いませんが、HSEファームウェアをインストールすると無視されます。この場合、ライフサイクルはHSEサービスを通じてのみ進めることができます。 よろしくお願いいたします。 ルーカス Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 私はこれらのコマンドを同期モードで実行しました。 奇妙なことに、プログラム ADPK に属性を設定してデバッグ認証モードを設定すると、ECU は正常に実行されます。 HSE LifeCycleを変更するために属性設定を呼び出したときだけ、APIはエラーを返さないが、1秒後にプログラムが突然リセットされる。 HSEライフサイクルを進める前に、アドレスLC構成ワードを設定する必要がありますか？ HaiHoangSoftware_0-1751869464437.pngHaiHoangSoftware_0-1751869464437.png LC構成ワードの値が0x00000000だった場合、どうなりますか？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 私はこれらのコマンドを同期モードで実行しました。 奇妙なことに、プログラム ADPK に属性を設定してデバッグ認証モードを設定すると、ECU は正常に実行されます。 HSE LifeCycleを変更するために属性設定を呼び出したときだけ、APIはエラーを返さないが、1秒後にプログラムが突然リセットされる。 HSEライフサイクルを進める前に、アドレスLC構成ワードを設定する必要がありますか？ HaiHoangSoftware_0-1751595287949.pngHaiHoangSoftware_0-1751595287949.png LC構成ワードの値が0x00000000の場合はどうなりますか？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL 割り込みによる問題を回避するため、コマンドは同期的に実行することをお勧めします。 コマンドは関数 Hse_Ip_ServiceRequest によってトリガーされます。非同期方法には以下のシーケンスがあります: lukaszadrapa_0-1751363963705.pnglukaszadrapa_0-1751363963705.png Mu_Ip...機能はインライン化されているので問題ありません。しかし、BaseNXPモジュールのOsIf関数はインラインではないので、それらも移動する必要があります。 よろしくお願いいたします。 ルーカス Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 これらのAPIは、ブロック1の0x0060FB3Eから配置されています。 それは処刑を行うのに十分安全な状態でしょうか？ ECUリセットを引き起こす理由は何かありますか？ HaiHoangSoftware_0-1751350485291.pngHaiHoangSoftware_0-1751350485291.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL さて、一つ抜けている文があります。UTESTフラッシュは、ライフサイクルが進む際にHSEによってプログラムされます。 Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL このデバイスは自動的にリセットされることはありません。これはおそらく、書き込み中の読み取りエラーが原因です。フラッシュブロック間での読み取り同時書き込みがサポートされています。ただし、フラッシュブロック0とUTESTは同じパーティション内にあることに注意してください。 それは「表102」に示されています。「フラッシュブロック構成」とS32K3リファレンスマニュアルの「21.3 UTest NVMセクター」に記載されています。 また、「14.6.5」の項もHSE-Bファームウェアリファレンスマニュアルにある「HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」は、さらなる開発に重要となる場合があります。 解決策は、RAMまたは別のフラッシュメモリからコードを実行することです。 よろしくお願いいたします。 ルーカス Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 この問題を解決するために、属性設定APIの入力パラメータをグローバルな揮発性変数として配置しました。 しかし、ライフサイクルを変更するAPIを正常に実行した後、ECUは自動的にリセットされます。 変更ライフサイクルをUDSサービスとして実装する予定ですが、HSEファームウェアがECUを自動リセットすると実現できないようです。 交換サイクル後、ECUを正常に動作させるために何か特別な操作が必要ですか？ Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 NXPのデモアプリに倣って、Set_Attrサービスを使用してLCを進める機能を実装しました。これには3つのステップが含まれます。 プログラムADKP デバッグ認証モードをパスワードに変更します Advance HSE LC ステップ1,2は通常 Mu0 インスタンスと 1 つのフリーチャネルで実行されました。 ステップ3では常にFSR=0x0f600002とGSR=67030001が報告されます。 以下の手順は必要ですか？ バックアップIVT アドレスLC構成ワード LCを進めるために何か見落としていることはありますか？ HaiHoangSoftware_0-1751280488672.pngHaiHoangSoftware_0-1751280488672.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL こんにちは、 @HaiHoangSoftware さん HSE_ERR_GENERALが発生する最も一般的な原因は、HSEサービスへのパラメータとして指定されたアドレスが無効であることです。それは、未実装メモリ空間を指す完全に無効なアドレスか、XRDC設定のためにHSEがそのメモリにアクセスできないか、あるいはメモリにマルチビットECCエラーがあるかのどちらかです。 データキャッシュが原因である可能性もあります。データキャッシュを無効にするか、HSEとの通信に使用されるすべてのメモリリソースをキャッシュ不可能なメモリに強制的に割り当てるようにしてください。 HSE_SRV_ID_GET_ATTR サービスの使用中にこのようなエラーが発生した場合は、pAttr アドレスを確認し、テスト目的でデータキャッシュを無効にしてください。 lukaszadrapa_0-1751023995011.pnglukaszadrapa_0-1751023995011.png よろしくお願いいたします。 ルーカス

WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity Hi Team, We are currently working on an instrument cluster that features screen mirroring. In our architecture, a companion mobile app streams frames over Wi-Fi to our host MCU. The data is received via an SDIO-connected Wi-Fi module, decoded using FFmpeg, and rendered on the display. We are utilizing lwIP for our network stack and Qt for MCUs for the cluster HMI. System Specifications: Host MCU: NXP i.MX RT1176 Wi-Fi Module: u-blox MAYA-W161 (SDIO interface) Display: LCDIFV2 (Parallel RGB Interface) OS: FreeRTOS The Issue: We are experiencing intermittent Wi-Fi disconnections that appear to be directly tied to graphical load. The Wi-Fi drops only occur when the display is running a resource-heavy GUI(featuring numerous elements and animations). When we switch to a lightweight UI, the Wi-Fi connection remains perfectly stable. Kindly guide us to sort out this issue. Regards, Vignesh Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity Hi @Vignesh_VInayak, hope you are doing well. Since image processing requires high CPU usage and large memory footprint, it is intended that for GUI-related applications, one of the two cores is dedicated to managing the interface. Would you please clarify if your implementation approach uses the two cores? Is there enough stack dedicated to each thread? Additionally, would you please share logs with debug logging enabled for the Wi-Fi stack, in order to further analyze the state of the Wi-Fi thread? To enable the debug logs, could you please enable the "CONFIG_WLCMGR_DEBUG" & "CONFIG_WIFI_SDIO_DEBUG" macros in the wifi_config.h header file? Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity Hi @RomanVR , Thanks for getting back to me so promptly. Please find the requested details and logs below: At present, our project only uses the Cortex-M7 core; the M4 core is not being utilized. Yes, all threads have sufficient stack allocated. We also confirmed this using the FreeRTOS stack overflow hook function, and no overflow is occurring. I've attached the log file with the suggested macros enabled. In the log, everything appearing after the final wlcm log consists of our application logs, which simply print the some random frame size whenever a Wi-Fi packet is received. As you can see, the logs stop at a certain point — that's where the Wi-Fi disconnect occurs. At the moment of disconnection, we don't see any logs from either wlcm or SDIO. Best regards, Vignesh. Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity Hi @Vignesh_VInayak, Would you please clarify if after the disconnect occurs, does the rest of the application, including the display, continue to function normally? If it's the case, would you please share your thread priority configurations? Related to the previous questions, could you please share the FreeRTOS runtime stats of the running threads? For this you will need to enable "configGENERATE_RUN_TIME_STATS" in FreeRTOSConfig.h file and define a task to call periodically the FreeRTOS API "vTaskGetRunTimeStats" and print the result to the terminal. This will provide useful information on the CPU usage of each thread and narrow down the root cause of the Wi-Fi disconnections. Related to this, as display applications cause high CPU load, it is highly recommended that a dual-core architecture is implemented to ensure proper execution of high-load applications.

S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, Our project using S32K358 with HSE B firmware with AB blocks. An issue happened when executing HSE API to get attribute cause reset. As I debug, before execute API, FSR is normal image.pngimage.png After executing Mu_Ip_SetTxRegister to set MU0 TR[1] register, 2 registers reports errors FSR status is 0F600002 means channel #1 execution is inprogress image (6).pngimage (6).png GSR status is 67030001 means HSE_ERR_GENERAL image 8.pngimage 8.png I checked other program that HSE APIs work normally, after executing Mu_Ip_SetTxRegister to set MU0 TR[1] register, 2 registers are normal FSR status is 0F600000 GSR status is 00000000 How to solve this issue? Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, We are already check and the problem does not come from interrupt. It comes from the Watchdog. We disabled the watchdog and no reset happen. Thanks. Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hello, is there any update on that case ? i'm facing the same issue. the MCU S32K324 got reset after 1 sec of advancing the life cycle to OEM_PROD using the HSE firmware ?  Thanks in advance Ayoub. Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Your new case has been assigned to the regional FAE team, so I would suggest leaving the next steps and investigation to them in order to avoid duplicating efforts. Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL By the time advancing HSE LC, I was using Trace32. May be the measurement time is not correct. Sorry for that. After a few tries unlocking debug port, Trace32 reports ECU continuously reset. Even if I do power off/on the board, the ECU still in reset. HaiHoangSoftware_0-1752114844597.pngHaiHoangSoftware_0-1752114844597.png How do I know which type of reset is happening (destructive/functional) and check the root cause? The debug port is secured in LC IN_FIELD. I can not unlock debug port with debug script because of this issue. Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL If it happens 1s later, it can be anything. And it can be unrelated to life cycle advancing.  I would need more details about the problem.  Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Right after reset, the HSE secured the debug port because HSE lifecycle changed to IN_FIELD. RGM FES and DES registers can not be read right after reset. Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Do you know what was source of the reset? Did you check RGM FES and DES registers after the reset? If HSE firmware is installed, it is not possible to advance the life cycle using LC configuration word. There can be any value, it will be ignored when HSE firmware is installed. The life cycle can be advanced only via HSE service in this case. Regards, Lukas Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, I did execute these command in synchronous mode. The strange thing when I call set attribute to program ADPK and config debug authorization mode, the ecu execute normally. Only when I call set attribute to change HSE LifeCycle, the API return no error, but 1 second later, the program suddenly reset. Do I need to set the Address LC configuration word before advancing HSE LifeCycle? HaiHoangSoftware_0-1751869464437.pngHaiHoangSoftware_0-1751869464437.png What will happen if the value in LC configuration word is 0x00000000? Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, I did execute these command in synchronous mode. The strange thing when I call set attribute to program ADPK and config debug authorization mode, the ecu execute normally. Only when I call set attribute to change HSE LifeCycle, the API return no error, but 1 second later, the program suddenly reset. Do I need to set the Address LC configuration word before advancing HSE LifeCycle? HaiHoangSoftware_0-1751595287949.pngHaiHoangSoftware_0-1751595287949.png What if the value in LC configuration word is 0x00000000? Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL My recommendation is to run the command as synchronous to avoid issues with interrupts.  A command is triggered by function Hse_Ip_ServiceRequest. And there's following sequence for asynchronous method: lukaszadrapa_0-1751363963705.pnglukaszadrapa_0-1751363963705.png The Mu_Ip… functions are inlined, so there’s no problem. But OsIf functions from BaseNXP module are not inlined, so you need to move them too. Regards, Lukas Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, These APIs is places in Block 1, from 0x0060FB3E. Is that safe enough for the execution? Is there any reason to cause ECU reset? HaiHoangSoftware_0-1751350485291.pngHaiHoangSoftware_0-1751350485291.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Well, there's one missing sentence: UTEST flash is programmed by HSE when life cycle is advanced.  Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL The device is not supposed to automatically reset. Most likely, this is caused by read-while-write error. Read-while-write is supported between flash blocks. However, be aware that flash block 0 and UTEST are in the same partition. It’s shown in “Table 102. Flash block configuration” and in “21.3 UTest NVM sector” in S32K3 reference manual. And also section “14.6.5  Synchronizing flash read/write access between HSE and application core” in HSE-B Firmware reference manual can be important for further development. The solution is to execute the code from RAM or from another flash block. Regards, Lukas Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, I resolve this issue by placing input params for set attribute API as global volatile variable. But after execute API to change life cycle successfully, the ECU automatically reset. We plan to implement change lifecycle as a UDS service but it seems to be not possible if HSE firmware auto reset ECU. Do I need to do anything to run ECU normal after change lifecycle? Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi, Follow NXP demo App, I implement a function to advance LC using Set_Attr service include 3 steps: Program ADKP Change Debug authorization mode to Password Advance HSE LC Steps 1,2 was executed normally with Mu0 instance and 1 free channel. Steps 3 always reports FSR= 0x0f600002 and GSR=67030001 Are there any step below needed: Back up IVT Address LC configuration word Do I miss anything to advance LC? HaiHoangSoftware_0-1751280488672.pngHaiHoangSoftware_0-1751280488672.png Re: S32K358 HSE API causes reset and reports HSE_ERR_GENERAL Hi @HaiHoangSoftware  The most common reason for HSE_ERR_GENERAL is invalid address provided as a parameter for HSE service. It’s either completely invalid address pointing to unimplemented memory space or HSE has no access to that memory due to XRDC configuration or there’s multibit ECC error in that memory. It may be also caused by data cache – make sure that data cache is either disabled or that all memory resources used for communication with HSE are forced to non-cacheable memory. If you got such error when using HSE_SRV_ID_GET_ATTR service, check the pAttr address  and disable data cache for test purposes: lukaszadrapa_0-1751023995011.pnglukaszadrapa_0-1751023995011.png Regards, Lukas

S32G274A 上 PFE HIF DMA 到 DDR 通信对 QuadSPI MCR 配置的意外依赖性 你好，专家 我们正在调查运行 QNX 7.1 的 S32G274A 上 QuadSPI 和 PFE HIF 数据路径之间意想不到的依赖关系。如果 QuadSPI 未初始化，PFE0 和 PFE2 将成功完成 PHY、EMAC、固件和 HIF 初始化。EMAC 可以接收有效帧，但 HIF DMA 不消耗 TX 或 RX 描述符，因此数据包无法在 PFE 和 DDR 之间传输，ARP/ping 失败。通过逐步简化 QuadSPI 初始化序列，我们发现只需一次写入即可恢复 PFE 通信：将 0x020F000C 写入 QuadSPI 模块配置寄存器 QuadSPI_MCR，其偏移量为 0x0000，距离 QuadSPI 基地址 0x40134000（即物理地址 0x40134000）不等。如果删除此写入操作，PFE 通信将持续失败。Flash 识别、JEDEC 事务、QNX F3S 框架、/dev/fs0 和启动延迟均已被排除在必要条件之外。我们目前的解释是，相关的效果可能是将 QuadSPI_MCR[MDIS] 清除为 0，从而启用 QuadSPI 时钟。 请问清除 QuadSPI_MCR[MDIS] 是否可以激活 S32G274A 上与 PFE HIF DMA-to-DDR/XBAR/NoC 路径共享的任何时钟请求、桥接或互连状态？PFE HIF DDR 访问与 QuadSPI 时钟或互连状态之间是否存在任何未记录或间接的依赖关系？或者这是否表明平台启动期间缺少共享时钟/NoC 初始化步骤？应该配置哪个 MC_CGM、RDC、MC_ME、NoC 或 PFE 平台寄存器来独立建立所需的状态，而不是让 PFE 驱动程序访问 QuadSPI MCR？ 我们目前正在进行补充测试，以确认单独清除 MDIS 是否既必要又充分；目前，已确认的触发条件是完整的 MCR 写入值 0x020F000C。 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 嗨，维特旺 感谢您与我们联系。 1. 您是否在使用客户板？ 2.您的PFE版本是什么？ BR 乔伊 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 嗨 Joey，是的，我们使用的是基于 S32G274A 的定制电路板。PFE0 和 PFE2 通过 RGMII 连接到 KSZ9031 PHY。操作系统为QNX 7.1。PFE软件版本如下： - NXP PFE QNX驱动程序版本：PFE-DRV_S32G_QNX_1.9.0 - PFE固件版本：PFE-FW_S32G_1.12.0 - 驱动程序报告的PFE硬件版本：0x00050300 如果您需要完整的启动日志、时钟配置、原理图部分或寄存器转储以进行比较，请告知。此致敬礼，Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 您好， 感谢您的回复。 1.你们的S32G启动方法是什么？早期阶段是否没有对QSPI进行初始化？ 2.尝试只操作 MDIS 位，看看是否会影响结果。 BR 乔伊 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 嗨，乔伊， 1.我们在 U-Boot 中通过 TFTP 加载 QNX IFS 和 DTB，并使用 bootm 启动 QNX。QNX 不是从 QSPI Flash 加载的。在启动 PFE 驱动程序之前，QNX 不会启动 devf-qspi-s32g 或显式初始化 QuadSPI 控制器。 2. 我们使用对 QuadSPI 模块配置寄存器（QuadSPI_MCR，基地址 0x40134000，偏移量 0x0000）进行读-修改-写操作来测试 MDIS 位。 测试 A — 无 QuadSPI MCR 操作 QSPI驱动程序未启动，QuadSPI_MCR未写入。PFE通信失败。 测试 B — 仅设置 MDIS MCR 之前 = 0x030F00CC MCR 写入 = 0x030F40CC MCR 后 = 0x030F40CC MDIS = 1 PFE沟通成功 只有 MDIS 的第 14 位从 0 变为 1。QSPI Flash 文件系统未启动，/dev/fs0 未创建，且未执行 JEDEC 访问。测试程序在寄存器操作后正常退出。 测试 C — 仅通过 MDIS 初始 MDIS 值已经是 0，因此未更改的 MCR 值 0x030F00CC 被写回。PFE通信失败。 我们之前也测试过将完整值 0x020F000C 写入 QuadSPI_MCR。在这种情况下，PFE通信成功了。 请问为什么仅将 QuadSPI MCR MDIS 位从 0 设置为 1 会影响 S32G274A 上的 PFE0/PFE2 通信？QuadSPI MCR 操作与 PFE HIF/DMA 到 DDR 路径之间是否存在任何必需的初始化顺序、已知的错误或已记录的依赖关系？ BR， 怀特旺 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 嗨，维特旺 感谢您的回复。 我目前正在就此事对您进行内部调查。我会尽快向您汇报进展情况！ BR 乔伊 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 嗨，维特旺 抱歉回复晚了。 根据内部信息和与专家的讨论，QSPI 和 PFE 之间没有特殊依赖关系。建议通过以下方法检查问题。 1.在 ATF/U-boot 启动 初始阶段和 QNX 阶段，禁用 QSPI。 2. 在 U-boot 启动 阶段测试 PFE 的功能。 3.如果您需要进一步的帮助，或者能否分享一些资源，那就太好了。例如，您可以提供一张能够重现您问题的图片。请使用以下链接发布您的资源： https://support.nxp.com BR 乔伊

S32K3xx-WB LPUART RTD needed. S32K3x-WB LPUART Real-Time Driver example for LPUART required. Any support on this will be helpful? mex file to configure or any sample example. Re: S32K3xx-WB LPUART RTD needed. Hi The "S32K344 Whiteboard Example Project" includes examples for the S32K344-WB, including LPUART examples. However, the RTD versions used in these examples are outdated. For new projects, we recommend using the latest S32K3 RTD 7.0.1; however, the S32K344 examples included therein are designed for the S32K3X4EVB-Q257 or S32K3X4EVB-T172. This means you will need to check the schematics for differences regarding LPUART instances and pin assignments, and modify the RTD examples accordingly. Best Regards, Robin

S32G274AにおけるPFE HIF DMA-DDR通信のQuadSPI MCR構成への予期せぬ依存性 こんにちは、エキスパートさん QNX 7.1を実行しているS32G274Aにおいて、QuadSPIとPFE HIFデータパスの間に予期せぬ依存関係が発生していることを調査中です。QuadSPIが初期化されていない場合、PFE0とPFE2はPHY、EMAC、ファームウェア、およびHIFの初期化を正常に完了します。EMACは有効なフレームを受け取ることができますが、HIF DMAはTXやRXディスクリプタを消費しないため、PFEとDDR間でパケットが転送されず、ARP/pingが失敗します。QuadSPIの初期化シーケンスを段階的に簡略化した結果、PFE通信を復元するには1回の書き込みで十分であることがわかりました。具体的には、QuadSPIベースアドレス0x40134000（つまり物理アドレス0x40134000）からオフセット0x0000にあるQuadSPIモジュール構成レジスタQuadSPI_MCRに0x020F000Cを書き込むことです。この書き込みを削除すると、PFE通信が常に失敗する。フラッシュ識別、JEDECトランザクション、QNX F3Sフレームワーク、/dev/fs0、起動遅延はすべて必要条件として除外されています。現在のところ、関連する効果はQuadSPI_MCR[MDIS]を0にクリアすることであり、これによりQuadSPIクロックが有効になると考えられます。 QuadSPI_MCR[MDIS]をクリアすることで、PFE HIF(データからDDR/XBAR/NoC S32G274A)パスと共有されるクロックリクエスト、ブリッジ、またはインターコネクト状態が有効になるか確認していただけますか?PFE HIFのDDRアクセスとQuadSPIのクロックやインターコネクト状態の間に、未公開または間接的な依存関係はありますか?それとも、プラットフォーム起動時に共有クロックやNoCの初期化ステップが欠けていることを示しているのでしょうか?どのMC_CGM、RDC、MC_ME、NoC、またはPFEプラットフォームレジスタを、PFEドライバがQuadSPI MCRにアクセスするのではなく、必要な状態を独立して確立できるように設定すべきでしょうか? 現在、MDISをクリアするだけで十分かつ必要であるかどうかを確認するための補足的なテストを実施しています。現段階では、確認済みのトリガーはMCR書き込み値0x020F000Cです。 Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、ウェイトワン お問い合わせいただきありがとうございます。 1. お客様用ボードを使っていますか? 2.お使いのPFEのバージョンは何ですか？ BR ジョーイ Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、ジョーイさん。はい、弊社ではS32G274Aをベースにしたカスタムボードを使用しています。PFE0とPFE2はRGMIIを介してKSZ9031 PHYに接続されています。オペレーティングシステムはQNX 7.1です。PFEソフトウェアのバージョンは以下の通りです:- NXP PFE QNXドライババージョン:PFE-DRV_S32G_QNX_1.9.0 - PFEファームウェアバージョン:PFE-FW_S32G_1.12.0 - ドライバーが報告するPFEハードウェアバージョン:0x00050300 起動ログ、クロック設定、回路図セクション、またはレジスタダンプの完全な比較が必要な場合はお知らせください。よろしくお願いいたします、Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、 ご返信よろしくお願いします。 1. S32Gの起動方法は何ですか?初期段階ではQSPIの初期化は行われなかったのでしょうか？ 2.MDISビットのみを操作して、結果に影響があるかどうかを確認してください。 BR ジョーイ Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、ジョーイ。 1.U-BootでTFTP経由でQNX IFSとDTBをロードし、bootmでQNXを起動します。QNXはQSPIフラッシュからロードされません。PFEドライバを起動する前に、QNXはdevf-qspi-s32gを起動せず、QuadSPIコントローラを明示的に初期化しません。 2. QuadSPIモジュール設定レジスタ(QuadSPI_MCR、ベースアドレス0x40134000、オフセット0x0000)上で、MDISビットを読み取り・修正・書き込み操作でテストしました。 テストA — QuadSPI MCR動作なし QSPIドライバは起動されておらず、QuadSPI_MCRも書き込まれていませんでした。PFE通信に失敗しました。 テストB — MDISのみを設定 MCR（前）= 0x030F00CC MCR書き込み = 0x030F40CC MCR後 = 0x030F40CC MDIS = 1 PFE通信が成功しました MDISの14ビット目のみが0から1に変更された。QSPI Flashファイルシステムは起動されず、/dev/fs0も作成されず、JEDECアクセスも行われませんでした。テストプログラムはレジスタ操作後、正常に終了した。 テストC — MDISのみクリア 初期のMDIS値はすでに0だったため、変更されていないMCR値0x030F00CC書き戻されました。PFE通信に失敗しました。 また、以前にはQuadSPI_MCRに完全な値0x020F000Cを書き込むテストも行いました。PFEのコミュニケーションはその件で成功しました。 QuadSPI MCR MDISビットを0から1に設定すると、S32G274AのPFE0/PFE2通信に影響が出る理由について教えていただけますか?QuadSPI MCR操作とPFE HIF/DMA-to-DDRパスの間には、必須の初期化シーケンス、既知のエラー、または文書化された依存関係はありますか？ BR、 ワイテワン Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、ウェイトワン ご返信よろしくお願いします。 現在、このマターについて内部調査を進めています。進捗状況については後ほどご連絡いたします！ BR ジョーイ Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 こんにちは、ウェイトワン 返信が遅くなり申し訳ありません。 内部情報および専門家との協議に基づくと、QSPIとPFEの間には特別な依存関係はない。以下の方法で問題を確認することをお勧めします。  1.ATF/ubootの初期段階とQNX段階で、QSPIを無効にします。 2. U-boot段階でPFEの機能をテストする。 3.もしさらに助けが必要なら、あなたのリソースをいくつか共有していただけると助かります。例えば、問題を再現できる画像を提供することもできます。リソースを投稿する際は、以下のリンクをご利用ください： https://support.nxp.com BR ジョーイ

S32K Examples S32K1xx S32K144 Example S32K144 CMP Round-robin S32DS2.0  Example S32K144 Verify Backdoor Access Key S32DS1.3  Example S32K144 FlexCAN0 RXFIFO DMA nonSDK S32DS13  Example S32K144 PDB ADC trigger DMA ISR S32DS  Example S32K144 Flash RW simple S32DS  Example S32K144 DMA memory copy test S32DS  Example S32K144 EEEPROM usage Example S32K144 EEEPROM usage - No SDK  Example S32K144 RTC VLPS  Example S32K144 WDOG RCM interrupt  Example S32K144 SRAM ECC Injection  Example S32K144 RAM Retention S32DS.R1 Example S32K144 I2C Master MPL3115A2 S32DSR1_v3  Example S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  Example S32K144_printf_implementation - S32DS_1.0  Example S32k144 UART printf/scanf under FreeRTOS - S32DS Example S32K144 SDK Function call on configurable period using LPIT timer.  Example S32K144 .noinit section usage Example S32K144 PDB ADC DMA S32DS.ARM.2018.R1   Example S32K144 RAM selftest simple S32DS 2018.R1  Example S32K144 Position Independent Code  Example S32K144 FlexCAN Pretended Networking STOP mode test S32DS.ARM.2.2  Example S32K144 LPIT DMA LPSPI  Example S32K144 FlexCAN TX/RX/Error ISR test S32DS2.2  Example S32K144 FlexIO Idle Detection S32DS2.2 S32K142 Example_S32K142_LMEN_Cache_v1_0_S32DS3.6_RTD300  Lauterbach_Script_For_MDM_AP_Mass_erase_S32K142  S32K146 Example S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2 S32K148 Example S32K148 PDB0-PDB1 ring S32DS3.4 RTM4.0.3  Example S32K148 PDB0-PDB1 ring DMA S32DS3.4 RTM4.0.3  Example S32K148 GPIO Interrupt   S32K116 Example S32K116 WDOG Fast Test  Example S32K116 LPUART LIN Slave TXRX ISR S32DS.ARM.2.2  Example S32K116 FlexCAN PN STOP S32DS.ARM.2.2 Example S32K116 FlexCAN VLPR test S32DS.ARM.2.2 S32K118 Example S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3xx S32K312 Example S32K312 ADC_IP Continuous Scan DMA S32DS36 RTD600    S32K344 Example S32K344 PIT BTCU ADC DMA DS3.4 RTD100   Example S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO test S32DS3.4 RTD200     Example Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4 RTD300   Example S32K344 LPUART RX/TX ISR FreeRTOS S32DS36 RTD600    Example_S32K344_MCAL_MCU_ClockMonitor_v1_0_S32DS36_RTD600    Example_S32K314_DTCM1_Backdoor_RTD201_DS34_v3    Example_Reg_Prot_Flash_Controller_S32K344   Example S32K344 PIT SWtrig ADC ANAMUX S32DS 3.6.0 RTD 6.0.0   Example S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0   Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600   Example_S32K344_BIST_eMCEM_SPD106_v2_0_S32DS365_RTD700  Example S32K344EVB_T172 UART_ETH_Gateway HLD S32DS368 RTD701   Example_S32K344_CMU_FM_POR_WDG_v1_0_S32DS369_RTD701    S32K358 Example S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500   Example S32K358 GMAC 100M lwIP FreeRTOS S32DS 3.6.1 RTD600   Example S32K358 GMAC 1G lwIP FreeRTOS S32DS 3.6.1 RTD600   Example S32K358 GMAC lwIP FreeRTOS RDBESS S32DS 3.6.1 RTD600   Example_S32K358_XRDC_SEMA42_Multicore_v1_0_S32DS369_RTD701    S32K388 Example S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600   S32K389 Example S32K389 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD 6.0.0   Example S32K389 GMAC1 SABRE lwIP FreeRTOS S32DS 3.6.1 RTD600  

S32K 示例 S32K1xx S32K144 示例 S32K144 CMP 轮询 S32DS2.0 示例 S32K144 验证后门访问密钥 S32DS1.3 示例 S32K144 FlexCAN0 RXFIFO DMA nonSDK S32DS13 示例 S32K144 PDB ADC 触发 DMA ISR S32DS 示例 S32K144 Flash RW simple S32DS 示例 S32K144 DMA 内存复制测试 S32DS S32K144 EEEPROM 使用示例 示例 S32K144 EEEPROM 使用 - 无 SDK 示例 S32K144 RTC VLPS 示例 S32K144 WDOG RCM 中断 示例 S32K144 SRAM ECC 注入  S32K144 RAM 保留示例 S32DS.R1 示例 S32K144 I2C主设备 MPL3115A2 S32DSR1_v3 示例S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  示例 S32K144_printf_implementation - S32DS_1.0 示例 S32K144 在 FreeRTOS 下使用 UART printf/scanf - S32DS 示例 使用 LPIT 定时器实现可配置周期函数调用的 S32K144 SDK 示例 S32K144 .noinit章节用法 示例 S32K144 PDB ADC DMA S32DS.ARM.2018.R1 示例 S32K144 RAM 自检简单 S32DS 2018.R1 示例 S32K144 位置无关代码  示例 S32K144 FlexCAN 虚拟网络停止模式测试 S32DS.ARM.2.2 示例 S32K144 LPIT DMA LPSPI 示例 S32K144 FlexCAN TX/RX/Error ISR 测试 S32DS2.2 示例 S32K144 FlexIO 空闲检测 S32DS2.2 S32K146 示例 S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2 S32K148 示例 S32K148 PDB0-PDB1 环 S32DS3.4 RTM4.0.3 示例 S32K148 PDB0-PDB1 环 DMA S32DS3.4 RTM4.0.3 示例 S32K148 GPIO 中断 S32K116 示例 S32K116 WDOG 快速测试 示例 S32K116 LPUART LIN 从机 TXRX ISR S32DS.ARM.2.2 示例 S32K116 FlexCAN PN 停止 S32DS.ARM.2.2 示例 S32K116 FlexCAN VLPR 测试 S32DS.ARM.2.2 S32K118 示例 S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3xx S32K344 示例 S32K344 PIT BTCU ADC DMA DS3.4 RTD100   示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO 测试 S32DS3.4 RTD200   示例 Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4RTD300   示例 S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500    

S32Kの例 S32K1xx S32K144 例：S32K144 CMPラウンド・ロビンS32DS2.0  例：S32K144バックドア・アクセス・キー検証S32DS1.3  例：S32K144 FlexCAN0 RXFIFO DMA非SDK S32DS13  例：S32K144 PDB ADCトリガDMA ISR S32DS  例：S32K144 Flash RWシンプルS32DS  例：S32K144 DMAメモリ・コピー・テストS32DS  例：S32K144 EEEPROMの使用方法 例：S32K144 EEEPROMの使用方法 - 非SDK  例：S32K144 RTC VLPS  例：S32K144 WDOG RCM割り込み  例：S32K144 SRAM ECC注入  例 S32K144 RAM 保持 S32DS.R1 例：S32K144 I2CマスタMPL3115A2 S32DSR1_v3  例：S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  例：S32K144_printf_implementation - S32DS_1.0  例：FreeRTOS環境でのS32k144 UART printf/scanf - S32DS 例：S32K144 LPITタイマを使用した構成可能期間に対するSDK関数の呼び出し  例：S32K144 .noinitセクションの使用方法 例：S32K144 PDB ADC DMA S32DS.ARM.2018.R1   例：S32K144 RAMセルフテスト・シンプルS32DS 2018.R1  例：S32K144ポジショニング独立コード 例：S32K144 FlexCAN疑似ネットワーキングSTOPモードのテストS32DS.ARM.2.2  例：S32K144 LPIT DMA LPSPI  例：S32K144 FlexCAN TX/RX/エラーISRテストS32DS2.2  例：S32K144 FlexIOアイドル検出S32DS2.2 S32K146 S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2の例 S32K148 例：S32K148 PDB0-PDB1リングS32DS3.4 RTM4.0.3  例：S32K148 PDB0-PDB1 ring DMA S32DS3.4 RTM4.0.3  例：S32K148 GPIO割り込み  S32K116 例：S32K116 WDOG高速テスト  例：S32K116 LPUART LINスレーブTXRX ISR S32DS.ARM.2.2  例 S32K116 FlexCAN PN STOP S32DS.ARM.2.2 例：S32K116 FlexCAN VLPRテストS32DS.ARM.2.2 S32K118 例 S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3XXシリーズ S32K344 例：S32K344 PIT BTCU ADC DMA DS3.4 RTD100   例：S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFOテストS32DS3.4 RTD200     例Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4RTD300   例：S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500     

我想在 EVBMA7518S48V 上运行一个示例。 请帮忙，需要关于将初始程序烧录到该板上的整个工具链流程的详细信息。我已将我们遇到的错误附在下面。我还需要用户指南和手册的链接，另外，入门指南中有一个开放的图形用户界面工具，但我找不到BMA7518的这个工具。 另外，是否有直接的 .hex 文件？或者通过文件之类的东西，我们可以直接运行电路板吗？ 用户指南中列出了所需的软件。 我拿到了 s32DS（如果版本重要请说明），但我不知道从哪里下载 unionGUI，我下载了 EVALGUI，但它不支持 7318 或 7518。哪里可以找到示例代码？ • S32DS-ARM：S32 设计工作室 • UnionGUI • EVBMA7518S48V 示例代码 WhatsApp Image 2026-09-16 at 1.00.17 PM (1).jpegWhatsApp 图片 2026-09-16 下午 1:00:17 (1).jpeg WhatsApp Image 2026-09-16 at 1.00.17 PM.jpegWhatsApp 图片 2026-09-16 下午 1:00:17.jpeg

LEARNING I am new to NXP S32K144. What is the recommended development environment for a beginner, and what should I learn first? Re: LEARNING Hello @JASAMANG , For a beginner, I recommend using S32 Design Studio for S32 Platform together with an S32K144 evaluation board. In addition to the IDE, please install the S32K1 Real-Time Drivers (RTD) package. For the current development flow, the recommended combination is S32 Design Studio v3.6.0 with S32K1 RTD 3.0.0. The RTD package can be installed through Help > S32DS Extensions and Updates. I suggest following this learning path: Import and run an existing S32K144 RTD example, such as a blinking LED or GPIO example. Learn the basic project structure, build process, flashing, and debugging. Become familiar with the S32 Configuration Tools, particularly pin, clock, and peripheral configuration. Continue with GPIO, interrupts, timers, PWM, and ADC. Once these fundamentals are clear, proceed to motor-control examples and tools such as FreeMASTER and MCAT. Starting from an existing example is generally easier than creating the complete application from scratch. For RTD installation guidance, please refer to the S32K1 RTD offline installation guide. Although the article demonstrates an older S32DS/RTD combination, it explains the package dependencies and the general offline installation flow. Always verify the required S32DS version and dependent packages in the release notes of the RTD version you download. You may also find this discussion useful: Install SDK/RTD into S32 Design Studio. It explains the difference between the legacy SDK and RTD and provides links to both AUTOSAR and non-AUTOSAR blinking LED examples You may also find useful examples and technical articles in the S32K Knowledge Base.  If you encounter a problem, I recommend searching the S32K Community forum first. Many common questions and issues have already been discussed and answered there.  Also, please create a dedicated thread if you encounter a specific issue. This helps keep us the discussions clear and makes it easier for other users to find relevant information.   We actively monitor threads for seven days after the last reply. After that period,  we only receive subscription emails for updates and those can occasionally be missed. For any related questions after this period, please create a new thread and refer to the original one.   If a response answers your question, please click “Accept as Solution.” For any related questions please create a new thread and refer to the original one.   Best regards, Pavel Re: LEARNING Information Appreciated 🙏 Re: LEARNING I really appreciate the information 🙏 

s32k3 mbdt（バージョン1.4.2）は、wdgモジュールを使用する際にファイルが見つからないと報告します。 S32K3 で mbdt ライブラリのバージョン 1.4.2 を使用して wdg モジュールを使用していますが、コードを生成する際に「AeWdog_Ip_Irq.c:45:10:」というエラーが発生します。致命的なエラー: AeWdog_Ip_Cfg_Defines.h:そのようなファイルまたはディレクトリはありません。（このファイルは確かに存在しません。） RTDライブラリから手動で彼を追加したところ、他のすべての処理でエラーが発生しました。さらに多くのエラーが発生しました。 どうしたんだ？設定ミスでもしたのか？助けてください！

NXPNfcRdLibのモジュールphalFelicaにおける脆弱性 - CVE-2026-87726 概要 サポートソフトウェアNXPNfcRdLibでCVE-2026-87726というソフトウェア脆弱性が特定されました。NXP NXPNfcRdLibモジュールphalFelicaのファームウェアバージョン07.14.00_PubまでのAPIバウンドチェックが不十分だと、権限を持つ攻撃者や信頼できない第三者が意図しないメモリ領域にアクセスし、機密性、整合性、可用性の限定的な喪失につながる可能性があります。 影響を受けるデバイス この脆弱性は、CLRC663ファミリのPN5180、PN7462、PN5190プラットフォーム上のNFCリーダソリューション上で、FeliCaベースのアプリケーションと組み合わせてNXPNfcRdLibバージョン07.14.00以前の展開に影響を与えます。 緩和 NFCリーダーライブラリで利用可能な最新のNXPNfcRdLibをご利用 ください |NXP Semiconductors 07.18.00以降のすべてのファームウェアバージョンでこの問題が修正されています。 了承 NXPは、責任ある情報開示を行ったEzhilamuthan氏に感謝の意を表します。

HTRC110 PSK/FSK标签读取能力 我需要使用 HTRC110 读取 FSK/PSK 调制的令牌（主要是 HID MicroProx），但我发现该芯片无法处理这种调制方式，请问能否确认并解释一下原因？这种调制方式应该很容易处理才对。NXP还有其他替代方案吗？ Re: HTRC110 PSK/FSK tag reading Capabilities 下午好 alasa995！我也在做这项研究。你走到哪一步了？此致敬礼，谢尔盖。 Re: HTRC110 PSK/FSK tag reading Capabilities 您好，我已经成功让芯片解码FSK调制信号，只需要调整一下芯片的配置即可。

S32K3xx-WB LPUART RTDが必要です。 S32K3x-WB LPUARTリアルタイム・ドライバの例が必要です。この件についてのサポートがあれば、何か助かりますか? 設定用のmexファイル、または任意のサンプル例。 Re: S32K3xx-WB LPUART RTD needed. ハイ 「 S32K344ホワイトボードサンプルプロジェクト」には、LPUARTのサンプルを含む、 S32K344-WBのサンプルが含まれています。 しかし、これらの例で使用されているRTDバージョンは旧式です。 新規プロジェクトには、最新版のS32K3 RTD 7.0.1の使用をお勧めします。ただし、そこに記載されているS32K344のサンプルは、 S32K3X4EVB-Q257またはS32K3X4EVB-T172向けに設計されています。つまり、LPUARTインスタンスとピン割り当てに関する違いがないか回路図を確認し、それに応じてRTDのサンプルを修正する必要があります。 よろしくお願いいたします ロビン