i.MX 8M クアッドEvk I2Cインターフェース 私は、I2Cインターフェースを使って、AM/FMチューナーモジュールをNXP i.MX 8M Quad EVKとインターフェースし、チューナーの設定と制御を行う必要があります。 このハードウェアインターフェースの確立方法を教えていただけますか? さらに、i.MX 8M Quad EVKはチューナーモジュールからのデジタルオーディオ出力を受信するために使えるI2S信号を露出していますか?もしそうなら、関連するコネクタの詳細とピンのマッピングを教えていただけますか? Re: i.MX 8M Quad Evk I2C interface こんにちは、 はい、MCIMX8M-EVKにはプロセッサのI2C2にアクセスするためのJ801コネクタがあります。 I2Sインターフェースへのアクセスはアダプターが必要になるため、少し難しいでしょう。これらの信号はM.2 KEY-E J1401コネクタまたはJ1801コネクタにコネクテッドされています。 次のデザインファイルで確認してください: i.MX 8M評価キット(EVKB)のデザインファイル よろしくお願いいたします。

i.MX 8M 四通道 Evk I2C 接口 我需要使用 I2C 接口将 AM/FM 调谐器模块与 NXP i.MX 8M Quad EVK 连接，以实现调谐器的配置和控制。 请问您能否指导我如何建立这个硬件接口？ 此外，i.MX 8M Quad EVK 是否提供可用于接收来自调谐器模块的数字音频输出的 I2S 信号？如果可以，能否请您提供相关的连接器详细信息和引脚映射？ Re: i.MX 8M Quad Evk I2C interface 你好， 是的，MCIMX8M-EVK 具有 J801 连接器，可访问处理器的 I2C2。 由于需要适配器，访问 I2S 接口会稍微困难一些。这些信号连接到 M.2 KEY-E J1401 连接器或 J1801 连接器。 请在下一个设计文件中查看： i.MX 8M 评估套件 (EVKB) 的设计文件 顺祝商祺！

FRDM-MCXE32B: Hands-On Prerequisites Introduction This document guides you through installing the tools and materials required for the FRDM-MCXE32B hands-on labs. Required Materials The hardware and software requirements may vary by exercise, but the following items are required for most hands-on labs. Hardware Requirements FRDM-MCXE32B board                  Personal computer USB Type-C cable Software Requirements MCUXpresso Installer (Recommended) IDE: Visual Studio Code (latest version) SDK: v26.09.00 or later MCUXpresso extension for VS Code (latest version) LinkFlash tool (included with the LinkServer installation) Windows operating system (these hands-on labs were developed and tested on Windows 11) Hands-On Prerequisites Guide. Hands-On Training

MCX E32 Product Training: Reliability and Safety Focused MCUs MCX E32 Product Training: Reliability and Safety Focused MCUs Welcome to FRDM-MCXE32B Product Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the FRDM-MCXE32B development board. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning.  Instructions  To get started with the MCX E32 training, you will need to have your FRDM-MCXE32B board in hand and perform the set-up operations according to Lab 0 and FRDM-MCXE32B Getting Started Page which is a pre-requisite.   Step 1. Mandatory pre-work before starting with the labs:  Lab 0: This document guides you through installing the tools and materials required for the FRDM-MCXE32B hands-on labs. Step 2. After completing the pre-work, download the lab guides. Each lab has its own guide document and a video guide you can use as support material in case you have any question at any step:  Lab 1: Multicore Hello World SDK Example Description This lab provides hands-on experience with the FRDM-MCXE32B board using the Multicore Hello World SDK example. The primary-core (core0) and secondary-core (core1) projects are configured and built together. The primary core initializes MCMGR (the Multicore Manager), prints "Hello World from the Primary Core!" to the debug console, and then releases the secondary core from reset by passing it a startup parameter. The secondary core waits for the startup data and then toggles the onboard red LED to indicate that it is running. After becoming familiar with the project, you will make simple code modifications as part of this hands-on lab. Lab 2: Gesture Classification and Vibration Monitoring Demo Description This lab provides hands-on experience with the FRDM-MCXE32B Gesture Classification and Vibration Monitoring proof of concept. The application demonstrates two industrial use cases: equipment anti-tamper and tilt detection, and vibration-based condition monitoring for predictive maintenance. The onboard FXLS8974CF three-axis accelerometer detects tilt, movement, and free-fall events and supplies data for vibration analysis. The application distributes the workload across both Arm Cortex-M7 cores. The secondary core (core1) acquires sensor data and performs CMSIS-DSP FFT processing. The primary core (core0) performs gesture classification and vibration-condition evaluation and controls the RGB LED, serial console, and optional LCD-PAR-S035 dashboard. The cores communicate using RPMsg-Lite over shared memory. Step 3. Review the support material and useful links to get you up to speed with some product information, MCX E32 and FRDM board information and getting started. Below also includes additional reading material.   FRDM-MCXE32B Development Board using MCUXpresso | NXP Semiconductors Getting Started with FRDM-MCXE32B Board | NXP Semiconductors MCX E32 and E31 MCUs | NXP Semiconductors MCX E32 and E31 MCUs | NXP Semiconductors Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  Hands-On Training

FRDM-MCXE32B: Run the Gesture classification and vibration monitoring demo Introduction This lab provides hands-on experience with the FRDM-MCXE32B Gesture Classification and Vibration Monitoring proof of concept. The application demonstrates two industrial use cases: equipment anti-tamper and tilt detection, and vibration-based condition monitoring for predictive maintenance. The onboard FXLS8974CF three-axis accelerometer detects tilt, movement, and free-fall events and supplies data for vibration analysis. The application distributes the workload across both Arm Cortex-M7 cores. The secondary core (core1) acquires sensor data and performs CMSIS-DSP FFT processing. The primary core (core0) performs gesture classification and vibration-condition evaluation and controls the RGB LED, serial console, and optional LCD-PAR-S035 dashboard. The cores communicate using RPMsg-Lite over shared memory.   Hardware Requirements FRDM-MCXE32B board                  Personal computer USB Type-C cable LCD-PAR-S035 display panel (Optional) Software Requirements IDE: Visual Studio Code (latest version) SDK: v26.09.00 or later Windows operating system (these hands-on labs were developed and tested on Windows 11) Gesture Classification and Vibration Monitoring demo source code from the NXP Application Code Hub saved to your Windows PC Monitoring demo Guide (function() { var wrapper = document.getElementById('lia-vid-6408021287112w960h540r591'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)   Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training

FRDM-MCXE32B: Run the Multicore Hello World SDK Example Introduction This lab provides hands-on experience with the FRDM-MCXE32B board using the Multicore Hello World SDK example. The primary-core (core0) and secondary core (core1) projects are configured and built together. The primary core initializes MCMGR (the Multicore Manager), prints "Hello World from the Primary Core!" to the debug console, and then releases the secondary core from reset by passing it a startup parameter. The secondary core waits for the startup data and then toggles the onboard red LED to indicate that it is running. After becoming familiar with the project, you will make simple code modifications as part of this hands-on lab. Hardware Requirements FRDM-MCXE32B board                  Personal computer USB Type-C cable Software Requirements IDE: Visual Studio Code (latest version) SDK: v26.09.00 or later Windows operating system (these hands-on labs were developed and tested on Windows 11) Multicore SDK Example Guide (function() { var wrapper = document.getElementById('lia-vid-6408020783112w960h540r7'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  Hands-On Training

Enabling QEMU emulation for i.MX95 19x19 EVK (community project) What actually happens between powering on an i.MX95 system and reaching a Linux login prompt? The answer involves far more than a bootloader and a kernel. The Boot ROM must locate and interpret the boot containers, the Cortex-M33 System Manager must initialize and manage platform resources, the Cortex-A55 must progress through SPL, TF-A, OP-TEE, and U-Boot, and only then can Linux initialize the system and mount its root filesystem. This QEMU-based i.MX95 emulation turns that otherwise difficult-to-observe sequence into a reproducible virtual laboratory for students, hobbyists, and engineers who want to study the complete boot chain without relying entirely on physical hardware. This community project (third-party, not an NXP product) adds QEMU-based i.MX95 emulation focused on that complete firmware journey. Rather than directly loading a kernel or staging each firmware component independently, the emulation starts from a Yocto-generated WIC image, processes its boot containers, executes the System Manager firmware, and preserves the handoffs that bring the A55 cluster online. The referenced third-party repository extends QEMU with functional emulation of the NXP i.MX95 SoC and the i.MX95 19x19 LPDDR5 EVK - embeddedPatronus/imx95-qemu: i.MX95 Qemu emulation for the complete firmware boot chain, from ROM and System Manager through TF-A, OP-TEE, U-Boot, and Linux. The project focuses on executing, observing, and debugging the complete production-style firmware boot chain from a bootable SD or eMMC image. This qemu model is intended for:- The model is intended for: for experimentation and learning [not a replacement for validation on NXP hardware] Boot-image and BSP testing System Manager and SCMI development TF-A and OP-TEE debugging Secure-world SMP analysis U-Boot and Linux platform development Pre-silicon and hardware-scarce development Education about modern heterogeneous Arm SoCs The model can help investigate questions such as: Did the System Manager receive correct handover information? Did SPL receive correct passover information? Did an SCMI request reach the M33? Did the System Manager provide a valid response? Did the System Manager program the correct A55 reset vector? Did the target CPU leave CPUWAIT? Did TF-A restore the expected context? Did OP-TEE select the correct per-core state? Did Linux mount the intended root filesystem? BSP regression testing A complete WIC image can be tested as the release artifact [functional smoke test only. not release qualification] Refer to Building Qemu section in the README of the repo to build the emulation model. To run qemu emulation of iMX95EVK:- cd build ./qemu-system-aarch64 -M imx95-evk -drive if=sd,index=0,file= ,format=raw -display none -serial pty -serial stdio -- Expected logs:- char device redirected to /dev/pts/11 (label serial0) U-Boot SPL 2026.04-lf_v2026.04+g6eeef838dac+p0 (Jun 02 2026 - 15:03:39 +0000) SYS Boot reason: por, origin: -1, errid: -1 Normal Boot Trying to boot from MMC1 Boot stage: Primary Image set: 0, offset: 0x8000 Load image from MMC/SD 0xf5800 NOTICE: BL31: v2.14.1(release):lf-6.18.20-2.0.0 NOTICE: BL31: Built : 12:42:19, Jun 8 2026 U-Boot 2026.04-lf_v2026.04+g6eeef838dac+p0 (Jun 02 2026 - 15:03:39 +0000) CPU: NXP i.MX95 Rev1.0 A55 at 1800 MHz CPU: Consumer temperature grade (0C to 95C) - invalid sensor data Model: NXP i.MX95 19X19 board ... ... The example command configures two serial consoles: "-serial pty -serial stdio" The serial ports are assigned as follows: Serial option Console First serial port, -serial pty Cortex-M33 System Manager debug console Second serial port, -serial stdio Cortex-A55 firmware and Linux console When QEMU starts, it prints the pseudo-terminal allocated to the System Manager console. Example: char device redirected to /dev/pts/11 To access the SM console on another tab:- screen /dev/pts/11 You can therefore observe both processing domains at the same time: Terminal 1 Cortex-A55 console SPL, TF-A, OP-TEE, U-Boot and Linux logs Terminal 2 Cortex-M33 System Manager console System Manager logs and interactive commands What actually happens between powering on an i.MX95 system and reaching a Linux login prompt? The answer involves far more than a bootloader and a kernel. This QEMU-based i.MX95 emulation turns that otherwise difficult-to-observe sequence into a reproducible virtual laboratory for students, hobbyists, and engineers who want to study the complete boot chain without relying entirely on physical hardware. IMX95EVK

MCX947 如何调试 Trustzone 项目 你好， 我一直在想办法调试修改后的 SDK 信任区域示例。但是我无法调试。它卡在了安全模式下，无法在非安全模式下调试。我原以为它会像从主核心切换到辅助核心一样，从安全核心切换到非安全核心。我读过一份旧的说明文档，其中建议擦除闪存等等。这并没有帮助。 核心与内存 开发板 Re: MCX947 How to debug trustzone projects 你好@embeddedguru 要调试 TrustZone 项目，我建议首先参考 SDK 中的 trustzone_helloworld 演示。 您可以参考MCUXpresso SDK 文档中的“运行 TrustZone 示例应用程序”部分，了解详细步骤。 谢谢！ 爱丽丝

100g QSFP hotplug We have a SolidRun ClearFog LX2 board and using 100G ethernet through QSFP. Everything works fine but the disconnect/reconnect. If the far side is disconnected/reconnected the link doesn't come up again. "ip link set dev eth1 down/up" doesn't help. "echo dpni.1 > /sys/bus/fsl-mc/drivers/fsl_dpaa2_eth/unbind" doesn't help either. Is there a proven workaround for this issue? Re: 100g QSFP hotplug Add the following configuration to the DPC file: mac@2 {     link_type = "MAC_LINK_TYPE_BACKPLANE";     enet_if = "CAUI"; } Re: 100g QSFP hotplug Thanks! That didn't help. After the change I get the following errors during "ls-addni dpmac.1"  fsl_dpaa2_eth dpni.1 (unnamed net_device) (uninitialized): failed to validate link configuration for in-band status  fsl_dpaa2_eth dpni.1 (unnamed net_device) (uninitialized): Error connecting to the MAC endpoint Our original dpc looks like this: mac@1 {     link_type = "MAC_LINK_TYPE_FIXED"; }; We use SerDes config 14-2-2. Re: 100g QSFP hotplug Discussing with the AE team.

88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hi, We are using the Murata LBEE5QD1ZM module, based on the 88W8987, connected through SDIO to an i.MX RT1176 running FreeRTOS and the NXP Wi-Fi driver. Some devices, especially a Multilaser M10 Android tablet, frequently fail to connect to our WPA2-Personal AP using PSK/CCMP. Occasionally, the same tablet connects successfully after several attempts. Other devices, such as a Samsung S9 FE, connect normally. Although Android displays “Obtaining IP address,” the logs indicate a failure during the WPA2 four-way handshake: - The AP reports station association, but no RSN_CONNECTED event. - Android logs indicate reception of EAPOL message 3 and transmission of message 4, followed by further retransmissions of message 3 from the AP. - Approximately 18 seconds after association, the AP reports deauthentication with reason 1. - When RSN_CONNECTED does occur, DHCP completes normally. Open and WEP connections work with the affected tablet. The problem persists with firmware versions 16.91.21.p82 and 16.92.21.p156.4. An important comparison is another product using the same module model under Linux: the M10 connects successfully using WPA2-PSK/CCMP, with the authenticator running on the host through hostapd. In our FreeRTOS implementation, the handshake is managed by the 88W8987 firmware. These observations suggest an interoperability issue in the firmware-managed authenticator. However, without an over-the-air capture, we cannot confirm whether message 4 reaches the module or why it is not accepted. Is this a known issue? Is there a firmware fix or diagnostic option to trace the authenticator state and determine why the handshake does not complete? Best regards, J. V. Melo. Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hello @joseviniciusmelo  Could you help share sdk version of iMX1176? Best Regards Shaun Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hi Shaun, I tested the following 88W8987 firmware versions and SDKs: 16.91.21.p82 with MCUXpresso SDK 2.13.1; 16.92.21.p156.4 with MCUXpresso SDK 26.09.00; The same intermittent WPA2 authentication failure occurred with both versions on our FreeRTOS platform. The same tablet connects successfully to another product that uses the same module model under Linux, where hostapd handles the WPA2 handshake on the host. Since the module firmware handles the handshake on our FreeRTOS platform, we suspect an interoperability issue with the firmware’s WPA2 authenticator. Best regards, J. V. Melo.

GUI Guider V2.0.1 offline template download path Where is the download link for the offline template of GUI Guider V2.0.1? Re: GUI Guider V2.0.1离线模板下载路径 Hi @ZYQ, You can find and download the offline templates for GUI Guider on the product page here: Create Modern Embedded GUIs Fasts | NXP Semiconductors Under "Downloads". Simply look for the entry titled offline template for your GUI Guider version, in this case: GUI Guider v2.0.1 Offline Template Information about how the offline templates work can be found on the documentation page: Getting started — GUI Guider Documentation. Let me know if you have any further inquiries.

S32K341 ファミリのマイクロコントローラ文書 こんにちは、NXPチームの皆さん、 安全コンパニオンボードにはS32K341EHT0MPAST 自動車用マイクロコントローラを選びました。製品サイトを通じてシリーズのデータシートとリファレンスマニュアルを持っています。この部品のセーフティ関連の他の資料や参考図、デザイン図を共有していただけますか?セーフティ補助基板の設計・開発に役立ててください。セーフティ補助基板について説明すると、これはセーフティMCUとセーフティPMICを含み、セーフティ関連の機能を監視・監督するために使われます。これらはセーフティのためのアドオンボードのようなシステムに取り付けられた際に使われます。 S32K41部分に関連する必要な書類の共有をサポートいただけると幸いです。 よろしくお願いいたします。 セルバ、 e-Conシステム。 Re: S32K341 Family microcontroller documents こんにちは、 S32K341ベースのセーフティコンパニオンボードについては、S32K3xxデータシートおよびリファレンス・マニュアルに加え、以下の機能安全およびハードウェアデザインのドキュメントを使用することをお勧めします。 1. S32K3xx セーフティマニュアル これはS32K341の主要なセーフティ統合文書であり、セーフティアーキテクチャ、セーフティ機構、使用上の前提、システムレベルで考慮すべき要件を定義しています。 2. S32K3xx FMEDA/セーフティ解析ドキュメント このドキュメントは詳細なハードウェアセーフティ分析を提供し、システムレベルのセーフティ分析やセーフティ概念と併用されるべきです。機能安全に関する書類の一部は、セキュリティやNDAアクセスが必要です。 3. AN14068、S32K3/S32K1 + FS23 ハードウェアおよびセーフティ適用ガイド このアプリケーションノートはあなたのユースケースに強くおすすめします。S32K341 + FS23の組み合わせを特にカバーし、Power Architecture、セーフティ接続、アプリケーション回路図、BOM/レイアウト推奨、起動シーケンス、ウォッチドッグ/FCCU監督、セーフステート処理および故障回復を含むハードウェアおよびセーフティ統合のガイダンスを提供します。 4. S32K3 RTDセーフティマニュアルおよび関連するセーフティドキュメント これらのドキュメントは、NXP S32K3リアルタイム・ドライバを使用して開発されるS32K341ソフトウェアを検討すべきです。 5. S32セーフティソフトウェアフレームワーク(SAF)、セーフティペリフェラルドライバ(SPD)、構造コア自己試験(SCST) セーフティ概念や必要な診断カバレッジに応じて、これらのパッケージはS32K3xxセーフティマニュアルで説明されているMCUセーフティ機構の実装のためのソフトウェアサポートを提供します。 ボードレベルのデザインについては、AN14068から始めることをお勧めします。なぜなら、S32K341+FS23の実装は、あなたが説明したセーフティMCU+セーフティPMIC/SBCアーキテクチャに非常に近いからです。その後、目標のASIL、Power Architecture、必要なセーフステート挙動、システムセーフティコンセプトに応じて、正確なPMIC/SBCおよびセーフティ接続を選択してください。 公開されたS32K3のドキュメントはNXP S32K3製品ページから入手可能です。セーフティマニュアル、FMEDAおよびその他の制限付き機能安全関連資料については、安全なアクセスが必要になる場合があります。 ほとんどのドキュメントは、以下のセキュアファイルから入手できます： https://www.nxp.com/products/S32K3 よろしくお願いします、 ピーター

MCX947 TrustZoneプロジェクトのデバッグ方法 こんにちは、 SDKのトラストゾーンの例の修正版をデバッグする方法を模索しています。しかし、デバッグができません。セキュアモードで停止してしまい、非セキュアモードではデバッグできません。プライマリコアからセカンダリコアに切り替えるように、セキュアから非セキュアに切り替わると思っていました。古い説明書でフラッシュを消去するなどを勧めているのを読みました。それは役に立たなかった コアとメモリ 開発ボード Re: MCX947 How to debug trustzone projects こんにちは、 @embeddedguru TrustZoneプロジェクトのデバッグには、まずSDKの trustzone_helloworld デモを参照することをお勧めします。 詳細な手順については 、MCUXpresso SDKsドキュメント の「TrustZone例アプリケーションを実行する」セクションを参照してください。 よろしくお願いします。 アリス

100g QSFPホットプラグ 私たちはSolidRun ClearFog LX2ボードを使い、QSFP経由で100Gイーサネットを使用しています。切断/再接続以外はすべて正常に動作します。 相手側が切断/再接続された場合、リンクは再び確立されません。「ip link set dev eth1 down/up」は役に立ちません。「Echo DPNI.1 > /sys/bus/fsl-mc/ドライバ/fsl_dpaa2_eth/unbind」も効果がありません。 この問題に対する確実な回避策はありますか？ Re: 100g QSFP hotplug DPCファイルに以下の設定を追加してください。 mac@2 {     link_type = "MAC_LINK_TYPE_BACKPLANE";     enet_if = "CAUI"; } Re: 100g QSFP hotplug よろしくお願いします！ それは役に立ちませんでした。変更後、「ls-addni dpmac.1」を実行すると、次のエラーが発生します。 fsl_dpaa2_eth dpni.1 (名前のないネットデバイス) (初期化されていません): インバンドステータスのリンク構成の検証に失敗しました fsl_dpaa2_eth dpni.1 (名前のないネットデバイス) (初期化されていません): MACエンドポイントへの接続エラー 元のdpcは次のようになっています。 mac@1 { link_type = "MAC_LINK_TYPE_FIXED"; }; SerDesの設定は14-2-2を使用しています。 Re: 100g QSFP hotplug AEチームと話し合っています。

100g QSFP 热插拔 我们有一块 SolidRun ClearFog LX2 板，并通过 QSFP 使用 100G 以太网。除了断开/重新连接的问题，其他一切都正常。 如果远端断开/重新连接，链路将无法再次建立。“ip link set dev eth1 down/up”命令不起作用。"echo dpni.1 > /sys/总线/fsl-mc/drivers/fsl_dpaa2_eth/unbind" 也无济于事。 这个问题是否有行之有效的解决方法？ Re: 100g QSFP hotplug 将以下配置添加到 DPC 文件中： mac@2 { link_type = "MAC_LINK_TYPE_BACKPLANE";     enet_if =“CAUI”； } Re: 100g QSFP hotplug 谢谢您！ 这样并没有解决问题。更改后，我在运行“ls-addni dpmac.1”命令时出现以下错误。 fsl_dpaa2_eth dpni.1（未命名网络设备）（未初始化）：验证带内状态链路配置失败 fsl_dpaa2_eth dpni.1（未命名网络设备）（未初始化）：连接到 MAC 端点时出错 我们最初的DPC看起来是这样的： mac@1 { link_type = "MAC_LINK_TYPE_FIXED"; }; 我们使用 SerDes 配置 14-2-2。 Re: 100g QSFP hotplug 与AE团队讨论。

S32K341系列微控制器文档 NXP团队您好， 我们为功能安全伴侣板选择了S32K341EHT0MPAST汽车微控制器。我从产品网站上获得了该系列产品的数据手册和参考手册。能否分享其他与功能安全相关的文档、参考原理图/设计图，以帮助我们设计和开发功能安全配套板？简单来说，功能安全辅助板是一个包含功能安全MCU和功能安全PMIC的模块，当作为功能安全附加板安装到系统中时，用于监测/管理功能安全相关功能。 请协助分享所有与S32K41部件相关的必要文件。 此致， 塞尔瓦， 电子通信系统。 Re: S32K341 Family microcontroller documents 你好， 对于基于 S32K341 的功能安全辅助板，除了 S32K3xx 数据手册和参考手册外，我还建议使用以下功能安全和硬件设计文档： 1. S32K3xx 功能安全手册 这是 S32K341 的主要功能安全集成文档，定义了功能安全架构、功能安全机制、使用假设以及在系统级别需要考虑的要求。 2. S32K3xx FMEDA / 功能安全分析文档 本文档提供了详细的硬件功能安全分析，应与您的系统级功能安全分析和功能安全概念一起使用。请注意，某些功能安全文档需要安全/保密协议访问权限。 3. AN14068，S32K3/S32K1 + FS23 硬件和功能安全应用指南 我强烈推荐您参考这份应用笔记来满足您的需求。它专门涵盖了 S32K341 + FS23 组合，并提供了硬件和功能安全集成指导，包括电源架构、功能安全连接、应用原理图、BOM/布局建议、启动顺序、看门狗/FCCU 监控、安全状态处理和故障恢复。 4. S32K3 RTD 功能安全手册及相关功能安全文档 如果使用 NXP S32K3 实时驱动开发 S32K341 软件，则应考虑这些文档。 5. S32 功能安全软件框架 (SAF)、功能安全外围驱动程序 (SPD) 和结构核心自检 (SCST) 根据您的功能安全理念和所需的诊断覆盖范围，这些软件包可以提供软件支持，以实现 S32K3xx 功能安全手册中描述的 MCU 功能安全机制。 对于板级设计，我建议从 AN14068 开始，因为它的 S32K341 + FS23 实现与您描述的功能安全 MCU + 功能安全 PMIC/SBC 架构非常接近。然后应根据目标 ASIL、电源架构、所需的安全状态行为和系统功能安全概念来选择确切的 PMIC/SBC 和功能安全连接。 NXP S32K3 产品页面上提供了公开的 S32K3 文档。对于功能安全手册、FMEDA 和其他受限功能安全资料，可能需要安全访问。 大部分文档可在安全文件中找到： https://www.nxp.com/products/S32K3 此致， 彼得

GUI Guider V2.0.1离线模板下载路径 GUI Guider V2.0.1 的离线模板下载路径链接在哪里呢 Re: GUI Guider V2.0.1离线模板下载路径 你好@ZYQ ， 您可以在此处的产品页面找到并下载 GUI Guider 的离线模板：快速创建现代嵌入式 GUI | NXP 半导体 在“下载”下。只需查找与您的 GUI Guider 版本对应的名为“离线模板”的条目，在本例中为： GUI Guider v2.0.1 离线模板 有关离线模板如何工作的信息可以在文档页面中找到：入门 — GUI 指南文档。 如果您还有其他疑问，请告诉我。

88W8987 使用 FreeRTOS 时，AP 模式下 WPA2 认证间歇性失败 您好， 我们使用基于 88W8987 的 Murata LBEE5QD1ZM 模块，通过 SDIO 连接到运行 FreeRTOS 和 NXP Wi-Fi 驱动程序的 i.MX RT1176。 某些设备，特别是 Multilaser M10 安卓平板电脑，经常无法使用 PSK/CCMP 连接到我们的 WPA2-Personal AP。有时，同一台平板电脑在多次尝试后才能成功连接。其他设备，例如三星 S9 FE，连接正常。 虽然安卓系统显示“正在获取 IP 地址”，但日志显示 WPA2 四次握手过程中出现故障： - AP 报告了站点关联，但没有 RSN_CONNECTED 事件。 - Android 日志显示接收到 EAPOL 消息 3 并发送消息 4，随后 AP 再次转发消息 3。 - 关联后约 18 秒，AP 报告取消认证，原因为 1。 - 当出现 RSN_CONNECTED 时，DHCP 正常完成。 受影响的平板电脑可以正常工作，开放式和 WEP 连接均可正常使用。固件版本 16.91.21.p82 和 16.92.21.p156.4 仍然存在此问题。 一个重要的对比是另一款在 Linux 下使用相同模块模型的产品：M10 使用 WPA2-PSK/CCMP 成功连接，验证芯片通过 hostapd 在主机上运行。在我们的 FreeRTOS 实现中，握手由 88W8987 固件管理。 这些观察结果表明固件管理的验证芯片存在互操作性问题。但是，如果没有空中捕获，我们无法确认消息 4 是否到达模块，也无法确认为什么它不被接受。 这是已知问题吗？是否有固件修复程序或诊断选项来跟踪验证芯片状态并确定握手无法完成的原因？ 此致， JV Melo。 Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS 你好@joseviniciusmelo 能否帮忙分享一下iMX1176的SDK版本？ 顺祝商祺！ 肖恩 Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS 嗨，肖恩， 我测试了以下88W8987固件版本和SDK： 16.91.21.p82，MCUXpresso SDK 2.13.1； 16.92.21.p156.4，带 MCUXpresso SDK 26.09.00； 在我们的 FreeRTOS 平台上，两个版本都出现了同样的间歇性 WPA2 身份验证失败问题。 同一台平板电脑可以成功连接到另一台在 Linux 系统下使用相同模块型号的产品，其中 hostapd 在主机上处理 WPA2 握手。由于模块固件在我们的 FreeRTOS 平台上处理握手，我们怀疑与固件的 WPA2 验证芯片存在互操作性问题。 此致， JV Melo。

MCX947 How to debug trustzone projects Hi, I have been figuring out way to debug modified version of SDK's trust zone examples. However, i cant debug. It got stuck in secure and cant debug in nonsecure.  I was expecting it would switch from secure to non secure just like from Primary core to secondary core. I read old instruction document suggesting to erase flash and so on . It did not help Core and Memory Development Board Re: MCX947 How to debug trustzone projects Hello @embeddedguru  For debugging a TrustZone project, I recommend first referring to the trustzone_helloworld demo in the SDK.  You can refer to the "Run a TrustZone example application" section in the MCUXpresso SDK documentation for detailed steps. Thank you. Alice

S32K341 Family microcontroller documents Hi NXP team, We have chosen S32K341EHT0MPAST automotive microcontroller for our safety companion board. I've got series datasheet and reference manual through product site. Can you share other safety related documents, reference schematics/design for this part to help us design and develop a safety companion board. To brief the safety companion board, it's a module contain safety MCU and safety PMIC, which are used to monitor/supervise safety related function when installed to a system like an add-on board for safety.  Kindly support sharing all those required documents related to S32K41 part. With regards, Selva, e-Con systems. Re: S32K341 Family microcontroller documents Hello, For your S32K341-based safety companion board, in addition to the S32K3xx Data Sheet and Reference Manual, I recommend using the following functional-safety and hardware-design documentation: 1. S32K3xx Safety Manual This is the main safety integration document for S32K341 and defines the safety architecture, safety mechanisms, assumptions of use and the requirements that need to be considered at system level. 2. S32K3xx FMEDA / safety analysis documentation This documentation provides the detailed hardware safety analysis and should be used together with your system-level safety analysis and safety concept. Please note that some functional-safety documents require secure/NDA access. 3. AN14068, S32K3/S32K1 + FS23 Hardware and Safety Application Guide I strongly recommend this application note for your use case. It specifically covers the S32K341 + FS23 combination and provides hardware and safety integration guidance, including power architecture, safety connections, application schematics, BOM/layout recommendations, startup sequencing, watchdog/FCCU supervision, safe-state handling and fault recovery. 4. S32K3 RTD Safety Manual and associated safety documentation These documents should be considered if the S32K341 software is being developed using the NXP S32K3 Real-Time Drivers. 5. S32 Safety Software Framework (SAF), Safety Peripheral Drivers (SPD) and Structural Core Self-Test (SCST) Depending on your safety concept and required diagnostic coverage, these packages can provide software support for implementing the MCU safety mechanisms described by the S32K3xx Safety Manual. For the board-level design, I suggest starting with AN14068, since its S32K341 + FS23 implementation is very close to the safety MCU + safety PMIC/SBC architecture you described. The exact PMIC/SBC and safety connections should then be selected according to your target ASIL, power architecture, required safe-state behavior and system safety concept. The public S32K3 documentation is available from the NXP S32K3 product page. For the Safety Manual, FMEDA and other restricted functional-safety collateral, secure access may be required. Most of the documents are available under secure files: https://www.nxp.com/products/S32K3 Best regards, Peter