P3H2840のデバッグに関する相談 現在、公式のP3H2840デモを基にデバッグを行っているのですが、デモにおける温度センサーの読み取り値がI2CモードとI3Cモードで異なることが分かりました（下図参照）。これは正常な動作でしょうか？ Re: p3h2840调试问题咨询 こんにちは、 I3Cモードレジスタの読み取り時に毎回表示される 0xff という2番目のバイトは正しくなく、ハブ構成の問題を示しています。参考までに、P3H2x4xHN-ARDの搭載温度センサーはNXP P3T1755DP デバイスで、完全にI3C対応なので、ハブが正しく設定されれば両方のモードで測定値は同じになるはずです。 以下の3項目をご確認ください。 動的アドレス割り当て— P3T1755DPはI2Cモードで起動し、I3Cプライベート転送が機能する前に動的アドレス（ENTDAA、SETAASA、またはSETDASA経由）を受信する必要があります。この段階が完了する前に i3c_xfer が呼び出されると、デバイスはI3Cフレームに正しく応答できず、2バイト目は 0xff と読み取られます。アドレス割り当てCCCが正常に実行され、0x4cが割り当てられた動的アドレスであることを確認してください。 バースト長有効化 — REG#17[6] (BL_ENABLE) — このビットが設定されている場合、I3C 書き込みフェーズにはレジスタポインタの後にバースト長バイトを含める必要があります。 i3c_xfer 呼び出しで書き込みバイト (レジスタ アドレス) が 1 つしか送信されない場合、ハブは不完全なフレームを受信し、読み取り応答のアライメントがずれるため、2 バイト目に 0xff が発生します。REG#17を読み返して、ビット6がセットされているかどうかを確認してください。もしそうであれば、書き込みペイロードにBLバイトを追加するか、必要ない場合はBL_ENABLEをクリアしてください。 ターゲットポートVCCIO — REG#22 — I3Cモードでは、ターゲットポートはREG#22のVCCIO設定を参照するプッシュプル駆動レベルを使用します。これが実際のP3T1755DP供給電圧と一致しない場合、プッシュプルモードで転送されたデータバイトが破損することがあります。REG#22がセンサーが接続されているターゲットポートの正しい動作電圧を反映しているか確認してください。

MPC5744P EVM – 外部CANトランシーバーによるCAN1/CAN2サポート こんにちは、あなた、 MPC5744P EVMが外部CANトランシーバを使って2つのCANチャネルの動作をサポートしているかどうかを明確にしたいと思います。 内蔵のCANトランシーバを使ってEVM上でCAN0をテストすることに成功し、CAN0通信は期待通りに動作しています。 現在、CAN1とCAN2を適切なピンマッピングで設定し、外部CANトランシーバとインターフェースできるようにしました。CAN1とCAN2がMPC5744P EVMの外部CANトランシーバーで正常に設定・運用可能かどうか確認していただけますか? もしそうなら、CAN1/CAN2の動作で推奨される設定、ハードウェア接続、または考慮すべき特定の設定を教えていただけますか? 皆さんのご助言とサポートを大変ありがたいです。 ご協力に感謝いたします。 Re: MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver こんにちは、 はい、CAN1およびCAN2はMPC5744Pベースの評価ボード上の外部CANトランシーバと組み合わせて使用できます。MPC5744Pデバイスは3つの独立したFlexCANモジュール(CAN0、CAN1、CAN2)を提供し、オンボードトランシーバーが利用可能かつ接続されていない場合、CAN1/CAN2は対応するMCU TX/RXピンを介して外部トランシーバーにルーティング可能です。このデバイスはすべてのFlexCANインスタンスの独立動作をサポートしています。  CAN1/CAN2については、以下をご確認ください。 選択したFlexCANインスタンスはソフトウェア上で正しく設定されています。 対応するTXピンとRXピンは、FlexCAN代替機能用に構成されています。 外部CANトランシーバは正しく電源が供給され、接続も正常です。 適切なCANバス終端が存在します。 基板固有のジャンパー設定や配線オプションは、EVMの正確なリビジョンによって異なる場合があります。EVMの部品番号やリビジョンをご提供いただければ、追加のハードウェア構成が必要かどうか確認いたします。 BR、ペトル

MPC5744P EVM – 支持 CAN1/CAN2 和外部 CAN 收发器 你好呀， 我想确认一下 MPC5744P EVM 是否支持使用外部 CAN 收发器操作两个 CAN 通道。 我已经使用板载/内置 CAN 收发器在 EVM 上成功测试了 CAN0，CAN0 通信工作正常。 现在，我已经配置了 CAN1 和 CAN2，并设置了适当的引脚映射，以便与外部 CAN 收发器连接。请问MPC5744P EVM上的CAN1和CAN2是否可以配置并成功使用外部CAN收发器？ 如果可以，能否请您提供 CAN1/CAN2 操作需要考虑的任何推荐配置、硬件连接或具体设置？ 您的指导和支持将不胜感激。 提前感谢您的帮助。 Re: MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver 您好， 是的，基于 MPC5744P 的评估板上可以与外部 CAN 收发器一起使用 CAN1 和 CAN2。MPC5744P 设备提供三个独立的 FlexCAN 模块（CAN0、CAN1 和 CAN2），如果没有板载收发器可用且已连接，则 CAN1/CAN2 可以通过其对应的 MCU TX/RX 引脚连接到外部收发器。该设备支持所有 FlexCAN 实例独立运行。  对于 CAN1/CAN2，请确保： 所选的 FlexCAN 实例已在软件中正确配置。 相应的 TX 和 RX 引脚配置为 FlexCAN 替代功能。 外部 CAN 收发器已正确通电并连接。 CAN总线终端连接正常。 特定电路板的跳线设置或布线选项可能取决于具体的 EVM 版本。如果您能提供 EVM 的部件号或版本号，我们可以检查是否需要任何额外的硬件配置。 BR，彼得

i.MX 93 Memory Compatibility Guide The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 4 Gb/ (512 MB) ISSI LPDDR4: IS43LQ16256B-062BLI 4, 8 2 Gb / (256 MB) ISSI LPDDR4: IS43LQ16128A-062BSLI 4, 6, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2 Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8 Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 16 Gb / (2 GB) IM (Intelligent Memory) LPDDR4/4x: IMAG16L4KBBG 4, 8 4 Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 4 Gb / (512 MB) ISSI LPDDR4/4X: IS43LQ16256B-053BLI 4, 8 8 Gb / (1 GB) ISSI LPDDR4/4X: IS46LQ16512B-046BLA2 4, 8 32Gb / (4GB) 16 Gb / (2Gb) usable by i.MX 93 ISSI LPDDR4/4X: IS46LQ32K01B-046BLI 4, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Q3 2026 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.

i.MX 93 内存兼容性指南 本文档旨在为 i.MX 93 系列处理器所支持的 LPDDR4/4X 内存器件的选型提供扩展指导。在任何情况下，强烈建议遵循特定 SoC 的 NXP 硬件开发者指南中概述的 DRAM 布局准则。 i.MX 93 系列处理器支持不同的封装，每种封装都有其支持的最高 LPDDR4/4X 数据速率。请参考相应的数据手册。 注意：部分 LPDDR4/4X 器件可能不支持低速运行，此外，DQ ODT 可能无法激活，这会影响这些速度下的信号完整性。如果用例中计划采用低速运行，请咨询内存供应商有关内存器件的配置方面及可能的定制，以确保功能正常。 LPDDR4/4X - 最大支持的密度 SoC 最大数据总线宽度 最大密度 假设的内存组织 说明 i.MX 93 (i.MX 93xx) 16 位 16 Gb / (2 GB) 具有 17 行地址 (R0 - R16) 的单排、单通道设备 1, 2, 3   LPDDR4/4X - 已验证的内存列表 验证过程是一个持续的工作——预计该表格会定期更新。 SoC 密度 内存供应商 已验证的内存型号 说明 i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/（512 MB） Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U 7, 9 8 Gb/ (1 GB) ISSI LPDDR4: IS43LQ16512A-053BLI 4, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/（512 MB） JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 4Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8 Gb / (1 GB) AM（Alliance Memory） LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 2Gb / (256 MB) ISSI LPDDR4: IS46LQ16128A-062BSLI 4, 6, 8   注 1： 这些数值纯粹基于 DDR 控制器和 DDR PHY 的 IP 文档、为其集成到 SoC 中所选的实现参数设置、SoC 参考手册以及 JEDEC 标准 JESD209-4B/JESD209-4-1 (LPDDR4/4X)。因此，除非另有说明，否则它们没有经过验证支持，也不能保证内存供应商会提供具有特定密度和 / 或所需内部组织的 SoC。如果客户选择使用最大密度并在预期用例中采用，需自行承担风险。 注 2： 不支持任何密度的字节模式 LPDDR4/4X 器件（内部在两个芯片之间拆分的 x16 通道，每个 x8），因此，这些数值仅适用于具有 x16 内部组织的器件（在 JEDEC 规范中称为 “标准” 器件）。 注 3： 该 SoC 还支持双秩单通道器件，因此，16Gb/2GB 密度也可通过使用具有 16 行地址 (R0 - R15) 的双秩单通道器件来实现。 注 4： 该内存型号未经过完整的 JEDEC 验证，但通过了所有功能测试项目 注意事项 5： 这是一款双通道 x32 器件。由于 i.MX93 仅支持 16 位 LPDDR4/X 数据总线，因此它只能与其中一个通道接口，从而仅能利用该器件一半的密度。如表格中所示 —— 该器件具有 32Gb/4GB 密度，但只能使用 16Gb/2GB。使用双通道器件的其中一个通道没有功能问题，因为在 LPDDR4/4X 中通道是独立的。  注6： 这是一款新的 JEDEC 100 球封装，尺寸为标准 200 球封装的一半。这种 100 球封装具有与 200 球封装相同的性能和功能，并且具有比标准封装更小、更便宜的额外优势。 注释7： 该器件已被制造商停产，并已更新为新的内存型号。  注释8： 该型号处于活跃状态。于 2025 年 6 月审核。 注释 9： 该型号已过时。 注10： 该器件将在 24 年第二季度被制造商停产，且不会更新为新的内存型号。 注释 11： 在 TSA 分析期间发现了 DQ 眼图裕量问题。vTSA 和稳定性测试未发现任何问题。

i.MX 93メモリ互換性ガイド このドキュメントの目的は、i.MX 93シリーズのプロセッサでサポートされている、互換性のあるLPDDR4/4Xメモリ・デバイスを選択するために幅広い指針を提供することにあります。いずれの場合も、特定のSoCの「NXPハードウェア開発者ガイド」に記載されているDRAMレイアウト・ガイドラインに可能な限り従うことをお勧めします。 i.MX 93シリーズのプロセッサはさまざまなパッケージをサポートしており、サポートされる最大LPDDR4/4xデータ・レートはそれぞれ異なります。詳細は、各データシートを参照してください。 注：一部のLPDDR4/4Xデバイスは低速での動作をサポートしていない場合があります。また、DQ ODTがアクティブでない場合、低速時における信号の整合性に影響する可能性があります。低速動作での使用を計画している場合は、メモリ・デバイスの構成やカスタマイズの可否についてメモリのベンダーに確認し、正常な機能を確保してください。 LPDDR4/4X - 最大サポート密度 SoC データの最大バス幅 最大密度 想定メモリ構成 備考 i.MX 93 (i.MX 93xx) 16ビット 16Gb/（2GB） 17行アドレス（R0 - R16）を持つシングル・ランク、シングル・チャネル・デバイス 1, 2, 3   LPDDR4/4X - 検証済みメモリ一覧 検証プロセスは継続的な取り組みであり、テーブルは定期的に更新される予定です。 SoC 密度 メモリベンダー 検証済みメモリ部品番号 備考 i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/（512 MB） Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U 7, 9 8 Gb/ (1 GB) ISSI LPDDR4: IS43LQ16512A-053BLI 4, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/（512 MB） JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb/（256MB） Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb/（1GB） IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 4Gb/（512MB） Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8Gb/（1GB） AM（Alliance Memory） LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 2Gb/（256MB） ISSI LPDDR4: IS46LQ16128A-062BSLI 4, 6, 8   注1： 値は、IDDRコントローラとDDR PHYのIPドキュメント、SoCへの統合のために選択された実装パラメータの設定、SoCリファレンス・マニュアル、およびJEDEC規格JESD209-4B/JESD209-4-1（LPDDR4/4X）に基づいています。したがって、これらの値は、特に明記されていない限り、検証による裏付けがありません。また、特定の密度および/または希望する内部構成のSoCがメモリ・ベンダーから提供される保証はありません。ユーザーが最大密度の使用を選択し、目的とするユース・ケースでその旨を想定する場合は、自己責任の下でそうするものとします。 メモ 2: バイト・モードのLPDDR4/4Xデバイス（x16チャネルが内部で各x8の2つのダイに分割される）は、どの密度でもサポートされません。したがって、数値はx16の内部構成（JEDEC仕様では「標準」構成）を持つデバイスにのみ適用されます。 注3： SoCはデュアル・ランクのシングル・チャネル・デバイスもサポートするため、16行アドレス（R0 - R15）のデュアル・ランクのシングル・チャネル・デバイスを使用しても5密度16Gb/2GBを達成できます。 メモ 4： メモリ部品番号は完全な JEDEC 検証を受けていませんが、すべての機能テスト項目に合格しました。 メモ 5: デュアル・チャネルのx32デバイスです。i.MX93は16ビットのLPDDR4/Xデータ・バスのみをサポートするため、接続できるのは1つのチャネルのみであり、利用できるのはデバイス密度の半分にとどまります。表に記載されるとおり、デバイスの密度は32Gb/4GBですが、使用できるのは16Gb/2GBに限定されます。デュアル・チャネル・デバイスで1つのチャネルのみ使用しても、LPDDR4/4Xでは各チャネルが独立しているため、機能上問題はありません。  注6： 新しいJEDEC 100ボール・パッケージで、標準の200ボール・パッケージの半分のサイズです。200ボール・パッケージと同じ性能と機能を備えており、標準パッケージよりも小型で安価であるという利点もあります。 注７： メーカーによって生産終了となっており、新しいメモリ部品番号に更新されています。 注8： 部品はアクティブであり、2025年6月にレビュー済みです。 注9： 旧型の部品です。 注10： メーカーによって2024年第2四半期に生産終了となっています。新しいメモリ部品番号には更新されません。 注 11： TSA分析中にDQ目視で軽微な問題が発見されました。vTSAと安定性テストでは問題は見つかりませんでした。

MCX C15/C16 Product Training: Essential MCUs built for cost effective, low-end applications Picture1.pngPicture1.png Welcome to MCX C15 and MCX C16 Product Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the MCX C15 and MCX C16 MCU family. 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 C15/C16 training, you will need to have your FRDM-MCXC162 in hand and perform the set-up operations according to the FRDM-MCXC162 Getting Started Page which is a pre-requisite.   Step 1. Mandatory pre-work before starting with the labs:  Getting Started with FRDM-MCXC162 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:  Lab0: Introduction to MCX C15/C16 and FRDM-MCXC162 Lab1: Low Power is a Superpower Objectives Download and run your first project from VS Code on the FRDM-MCXC16 Explore the basics of low-power modes Description Load the SDK low-power example, walk through the code flow, and review the available wake-up options. You'll also learn how to connect a current meter to the FRDM board to measure power consumption. Lab2: Low-Power Sensing Demo Objectives Download and run your first ACH example from VS Code on the FRDM-MCXC16 Explore a low-power sensing application Description Access and download examples directly from ACH in VS Code, then run a real-world low-power sensor use case. Lab3: PWM Lighting Demo Objectives Learn how to load firmware using LinkServer/LinkFlash and simple production-style scripts Explore the timer and PWM capabilities of the MCXC family Description Use a provided binary and step-by-step instructions to program the board. The demo controls the onboard RGB LED using PWM. Source code will also be available in ACH. Lab4: Connecting Expansion Boards to FRDM-MCXC162 Objectives Download an ACH example from VS Code Connect and use expansion boards with the FRDM-MCXC16 Description Connect an expansion board, download the example from ACH, and try a low-power sensing application using an external sensor. Additional requirements as below:  MikroE OLED B/W Click display in I2C mode SparkFun Qwiic dToF Imager (TMF8820) Qwiic board cable Step 3. Review the support material and useful links to get you up to speed with some product information, FRDM board information and Getting started. Below also includes additional reading material.   MCX C15/C16 Product Page  FRDM-MCXC162 Tool Summary Page  FRDM-MCXC162 Getting Started Page  MCX C1 Family Factsheet  MCX C15/C16 Datasheet   MCX C15/C16 Reference Manual  Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC

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