S32DS EcuM ドキュメント 現在、S32K116でLINを実装しようとしています。 Lin_43_LPUAR_FLEXIOモジュールを追加した後、プロジェクトがコンパイルされなくなりました。 どうやら EcuM モジュールも追加しないと動かないようです(この情報はLINドキュメントに追加することをおすすめします)。 EcuMモジュールを追加した後、ドキュメントが付いていないことに気づきました。 私の質問： EcuMモジュールは何のためにあるのですか？ これで何ができて、どう使えばいいのでしょうか? なぜLINに必須なのですか? そのドキュメントはどこで見つけられますか? Re: S32DS EcuM documentation こんにちは、 @daniel_meier さん。 EcuM(ECUステートマネージャー)は、ECU状態の共通の側面を管理するAUTOSAR基本ソフトウェア(BSW)モジュールです。 RTDリリースノートに記載されているように 、「Dem、Det、EcuC、EcuM、Rteおよびインターフェースプラグインに含まれる機能はサンプルスタブ関数です」 つまり、RTDにはこれらのモジュールのサンプル実装が含まれており、対応するAUTOSAR基本ソフトウェアモジュールが利用できない場合でもアプリケーションがコンパイルして実行できるようにします。 完全なAUTOSAR環境では、EcuM、Dem、Det、Rteなどのモジュールは通常、Vector、ElektrobitなどのAUTOSARベンダー、またはその他のサードパーティサプライヤーから提供されます。RTDに含まれる実装はあくまでプレースホルダーとして意図されており、インターフェース依存性を満たすために必要な最小限の機能を提供します。 EcuMに関する詳細情報については、モジュールの詳細な説明が記載されているECUステートマネージャーのAUTOSAR仕様をご参照ください。 このモジュールをLINと組み合わせて使う場合、ドライバーユーザーマニュアルと統合マニュアルの確認もお勧めします。これらの文書は、ハードウェアおよびソフトウェアの要件、対応構成、使用ガイドライン、統合手順、既知の制限事項に関する詳細な情報を提供します。これらの文書は、例えば以下で見つけることができます: C:\NXP\S32DS.3.6.5\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Lin_43_LPUART_FLEXIO_TS_T40D2M30I0R0\doc BR、VaneB

哪个中子变流器与 i.MX95 电路板支持包 LF6.6.52_2.2.x 匹配？工具包 1.14 没有 Linux_6.6.52 文件夹。 我们正在 Toradex Verdin iMX95, B0 芯片上启用 Neutron NPU，运行来自 Toradex 电路板支持包。 7.7.0 的 Yocto 参考多媒体映像。这不是Torizon。内核版本为 6.6.142-7.7.0-devel，基于 NXP LF6.6.52_2.2.2。/dev/neutron0 存在，驱动程序会进行探测。 该镜像未包含 Neutron 固件。我们安装了“NeutronFirmware.elf”以及来自 nxp-imx/neutron 分支 lf-6.6.52_2.2.0 的“NeutronKernels.bin”。用户空间代理库和 Neutron 库都是从同一分支构建的。label_image 在容器中运行并到达 NPU。 eIQ 工具包 1.14.0安装程序 EIQ-TOOLKIT-WIN-1.14.0（日期为 2025 年 1 月 28 日）没有 Linux_6.6.52 变流器。该安装中最新的 Linux 变流器是 Linux_6.6.36_2.1.0。正在转换 mobilenet_v1_1.0_224_quant.tflite使用 --target imx95 参数会生成一个微代码为 0x5bfe0804 的模型。运行时，6.6.52 版本堆栈报告： 微代码版本不匹配！0x5bfe0804（预期为 0xa186aaf2） 已创建委托，并委托了一个节点，但分类分数为空。在 CPU 上，如果没有 Neutron 委托，相同的模型可以正确地为 grace_hopper.bmp 返回“军装”。 将固件和用户空间库替换为 lf-6.6.36_2.1.0版本删除了不匹配项，然后 6.6.52 内核驱动程序因无法创建中子推理作业而导致作业失败，中子驱动程序内部故障代码 442。6.6.36 库无法与此内核通信。 eIQ Toolkit 版本说明指出，i.MX95 电路板支持包。 LF6.6.52_2.2.x 的 Neutron 变流器仅在 eIQ Toolkit 1.14 中可用。我们拥有的 1.14 安装程序中不包含它。 哪个变流器二进制会为该电路板支持包。生成微代码 0xa186aaf2？它包含在哪个 eIQ Toolkit 或 Neutron SDK 软件包中？ Re: Which neutron-converter matches i.MX95 BSP LF6.6.52_2.2.x? Toolkit 1.14 has no Linux_6.6.52 fold 你好@Giorgos_Sofroniou 预建变流器仅在eIQ Ubuntu版本上可用。 此致， 志明

シリコン・レビジョン こんにちは、 シリコンのリビジョンをMCIMX6S4AVM08ACからMCIMX6S4AVM08ADにかけてのドキュメントを探しています。 今回のシリコン改訂版では、どのような変更が加えられたのでしょうか？その点に関するドキュメントは見つかりませんでした。 MCXA MCX C MCX N Re: silicon revision こんにちは、 @FelipeBalieiro さん。 このデータシートを参照してください。 https://www.nxp.com/docs/en/data-sheet/IMX6SDLAEC.pdf データシートでは、 MCIMX6S4AVM08ACがシリコンRev.1.2/1.3に対応していることが確認されています。MCIMX6S4AVM08ADはRev.1.4であり、ROMの変更を伴う新しい4N81Eマスクセットです。 関連するROM修正はこちらから入手できます:i.MX 6Solo/6DualLiteのChip Errata よろしくお願いします、 志明

S32DS EcuM 文档 我目前正在尝试在 S32K116 上实现 LIN。 添加Lin_43_LPUAR_FLEXIO模块后，项目无法编译了。 显然我还需要添加EcuM模块才能使其正常工作（我建议将此信息添加到 LIN 文档中）。 添加EcuM模块后，我发现它没有附带文档。 我的问题： EcuM模块是做什么用的？ 我可以用它做什么？我该如何使用它？ 为什么LIN需要它？ 哪里可以找到相关文档？ Re: S32DS EcuM documentation 嗨@daniel_meier EcuM（ECU 状态管理器）是一个 AUTOSAR 基础软件 (BSW) 模块，负责管理 ECU 状态的通用方面。 正如RTD版本说明中所述： "Dem、Det、EcuC、EcuM、Rte和接口插件中包含的函数是示例短截线函数" 这意味着 RTD 包含了这些模块的示例实现，即使相应的 AUTOSAR 基本软件模块不可用，应用程序也能编译和运行。 在完整的 AUTOSAR 环境中，EcuM、Dem、Det 和 Rte 等模块通常由 Vector、Elektrobit 等 AUTOSAR 供应商或其他第三方供应商提供。RTD 中包含的实现仅用作占位符，并提供满足接口依赖关系所需的最低功能。 有关 EcuM 的更多信息，请参阅 ECU 状态管理器的 AUTOSAR 规范，其中提供了该模块的详细描述。 关于将此模块与 LIN 配合使用，我还建议您查阅驱动程序用户手册和集成手册。这些文档提供了有关硬件和软件要求、支持的配置、使用指南、集成程序和已知限制的详细信息。例如，您可以在以下位置找到这些文件： C:\NXP\S32DS.3.6.5\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Lin_43_LPUART_FLEXIO_TS_T40D2M30I0R0\doc BR，VaneB

Which neutron-converter matches i.MX95 BSP LF6.6.52_2.2.x? Toolkit 1.14 has no Linux_6.6.52 folder We are enabling the Neutron NPU on a Toradex Verdin iMX95, B0 silicon, running the Yocto reference multimedia image from Toradex BSP 7.7.0. This is not Torizon. The kernel is 6.6.142-7.7.0-devel, based on NXP LF6.6.52_2.2.2. /dev/neutron0 exists, and the driver probes. The image did not ship the Neutron firmware. We installed "NeutronFirmware.elf" and "NeutronKernels.bin" from nxp-imx/neutron, branch lf-6.6.52_2.2.0. The userspace delegate and Neutron libraries were built from the same branch. label_image runs in a container and reaches the NPU. eIQ Toolkit 1.14.0, installer EIQ-TOOLKIT-WIN-1.14.0 dated 28 January 2025, has no Linux_6.6.52 converter. The newest Linux converter in that install is Linux_6.6.36_2.1.0. Converting mobilenet_v1_1.0_224_quant.tflite with --target imx95 produces a model whose microcode is 0x5bfe0804. At runtime the 6.6.52 stack reports: microcode version mismatch! 0x5bfe0804 (expected 0xa186aaf2) The delegate is created, and one node is delegated, but the classification scores are empty. The same model on the CPU, without the Neutron delegate, correctly returns "military uniform" for grace_hopper.bmp. Replacing the firmware and the userspace libraries with the lf-6.6.36_2.1.0 versions removes the mismatch, then the 6.6.52 kernel driver fails the job with a failure to create a neutron inference job, Neutron Driver internal fault code 442. The 6.6.36 library cannot talk to this kernel. The eIQ Toolkit release notes say the Neutron converter for i.MX95 BSP LF6.6.52_2.2.x is available only in eIQ Toolkit 1.14. The 1.14 installer we have does not contain it. Which converter binary produces microcode 0xa186aaf2 for this BSP, and in which eIQ Toolkit or Neutron SDK package is it shipped? Re: Which neutron-converter matches i.MX95 BSP LF6.6.52_2.2.x? Toolkit 1.14 has no Linux_6.6.52 fold Hi @Giorgos_Sofroniou  The prebuilt converter is only availble on eIQ Ubuntu version. Best Regards, Zhiming

S32DS EcuM documentation I am currently trying to implement LIN on an S32K116. After adding the Lin_43_LPUAR_FLEXIO module, the project did not compile anymore. Apparently I need to add the EcuM module as well for it to work (I recommend adding this information to the LIN documentation). After adding the EcuM module, I noticed that it does not come with documentation. My questions: What is the EcuM module for? What can I do with it and how do I use it? Why is it required for LIN? Where can I find the documentation for it? Re: S32DS EcuM documentation Hi @daniel_meier  EcuM (ECU State Manager) is an AUTOSAR Basic Software (BSW) module responsible for managing common aspects of ECU states. As stated in the RTD release notes: "The functions contained in the Dem, Det, EcuC, EcuM, Rte and interface plugins are sample stub functions" This means that RTD includes sample implementations of these modules to allow the applications to compile and run even when the corresponding AUTOSAR Basic Software Modules are not available. In a full AUTOSAR environment, modules such as EcuM, Dem, Det, and Rte are typically provided by AUTOSAR vendors such as Vector, Elektrobit, or other third-party suppliers. The implementations included with RTD are intended only as placeholders and provide the minimum functionality required to satisfy the interface dependencies. For additional information about EcuM, please refer to the AUTOSAR Specification of ECU State Manager, which provides a detailed description of the module. Regarding the use of this module with LIN, I would also recommend reviewing the Driver User Manual and the Integration Manual. These documents provide detailed information on hardware and software requirements, supported configurations, usage guidelines, integration procedures, and known limitations. These documents can be found, for example, at: C:\NXP\S32DS.3.6.5\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Lin_43_LPUART_FLEXIO_TS_T40D2M30I0R0\doc BR, VaneB

使用 ADV7535 在定制 i.MX95 板上进行 HDMI 启动的指南 您好，NXP团队， 我正在开发一块定制的 NXP i.MX95 板，并希望使用 ADV7535 MIPI-DSI 转 HDMI 桥接器启用 HDMI 输出。 我是 Yocto Linux、设备树配置和 HDMI 初始化方面的初学者。请您一步一步地指导我完成以下操作： 所需的Linux内核驱动程序和配置。 ADV7535 和 MIPI-DSI 的设备树 (DTS) 更改。 Yocto配置和HDMI初始化。 任何参考设备树文件、应用笔记或适合初学者的指南。 感谢您的支持。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 你好， 您可以参考这篇文章来开发您自定义设计的新图像。 保留原文定制指南 我们的 电路板支持包。 包含使用 ADV7535 桥接器所需的所有驱动程序，您可以参考 EVK 板设备树将其包含在您的设备树配置中： imx95-19x19-evk-adv7535.dtso 顺祝商祺！ Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 请求审查 i.MX95 ADV7535 HDMI 设备树补丁 您好，NXP团队， 我创建了一个设备树补丁（ hdmi_patch_imx95-15x15.patch ），以通过我自定义的 i.MX95 15×15 板上的 ADV7535 MIPI-DSI 转 HDMI 桥接器启用 HDMI 输出。 请您查看我附上的补丁，并确认HDMI集成是否正确？ 请只关注与HDMI相关的更改， 注意：此补丁还包含 LAN9646 以太网交换机配置。请忽略与 LAN9646 相关的更改，仅查看 HDMI 集成部分。 如果缺少任何更改或更改不正确，请告知我，并参考 i.MX95-15x15-FRDM 设备树提出所需的更正建议。 感谢您的支持。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 您好，NXP团队， 感谢您分享参考文件。我需要分步指导，才能使用 ADV7535 桥接器在我的定制 i.MX95 15x15 板上启用 HDMI 输出。 请问您能否解释一下： 我需要修改 i.mx95-15x15-FRDM.dtsi 文件，该文件用于 i.mx95-15x15-frdm 板。 如何使imx95-19x19-evk-adv7535.dtso适配我的定制硬件？ 3. 目前我正在使用 i.mx95-15x15-frdm 镜像，一切验证无误后，我将制作自己的自定义机器镜像。 请提供每个步骤的示例代码和命令，因为我是设备树配置和 Yocto 的新手。 感谢您的支持。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 你好， 遗憾的是，我们没有关于如何从头开始执行此操作的逐步指南，但是使用基于 EVK 的新层添加您的更改可能是一个好方法。请参考之前提到的帖子。 您的配置似乎符合我们使用此桥接器的参考设计。 顺祝商祺！ Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 亲爱的@JorgeCas ， 感谢您的快速回复。 请您查看一下@deepak_k在此帖子中分享的补丁中的更改？ 我们采用类似的方法，使用 EVK 板上 ADV7535 HDMI 配置的参考 DTSO 文件。 请您审核一下实现方案，并与我们联系是否缺少任何必要的配置或更改才能使其正常工作？ 非常感谢您的反馈。 此致， 阿萨杜拉

ASA Emergency Alert Handling and Audio Source Switching Our main question concerns the behavior of the vehicle when an emergency alert is received from DAB while another media source is active, such as Spotify via Bluetooth/CarPlay/Android Auto or an FM radio station.   Specifically, we would appreciate your technical clarification on the following points:   Automatic Source Switching: When an ASA emergency alert is received over DAB while the user is listening to FM radio or Spotify, how does the system automatically switch to the DAB emergency announcement and display the relevant alert information?   System Responsibility: Which component is responsible for this behavior? Is the alert detection and triggering handled by the ASA chip itself, or does the DAB receiver/head unit need a control interface that allows it to interrupt the currently active media source and switch to DAB audio?   Vehicle Integration: Does the DAB receiver directly control the audio source and display, or does it send an alert notification or trigger signal to the vehicle's infotainment system, which then performs the source switching and displays the alert?   Standards and Implementation: Does the relevant ASA/DAB standard define this behavior and the required interface between the receiver and the vehicle infotainment system, or are these implementation details left to the receiver manufacturer and vehicle OEM?   Technical Requirements: Are there any specific hardware interfaces, software APIs, control signals, or infotainment integration requirements necessary to ensure that an emergency alert can override the currently active media source?   Our objective is to understand whether this functionality is primarily provided by the ASA receiver/decoder or whether additional integration with the vehicle's infotainment system is required.   Any relevant technical documentation, system architecture diagrams, or implementation guidelines would be greatly appreciated. Re: ASA Emergency Alert Handling and Audio Source Switching Hi osmanistlink10 Thanks for your interest in NXP products. What's the NXP product part number related your questions?

RT-DESTRはAraSDK 2.1.1上でAra240 .dvmに完全に変換できません — サポートされていない運用+ハイブリッドの回避策 こんにちは、NXPコミュニティの皆さん。 私は、 AraSDK / ランタイム 2.1.1をターゲットとして、 FRDM i.MX95上のAra240 DNPU用のRT-DETRオブジェクト検出器を変換しています。（3.0ではない）のみ。調査結果を共有し、完全な.dvmファイルを作成するための推奨/サポートされている方法があるかどうかを尋ねたいと思います。多スケール変形可能な注意を持つDESTRスタイルモデルの変換。 環境 商品の価値 ボード FRDM i.MX95 + Ara240 ランタイム imx-nxp-ara2 2.1.1 （コンパイラと一致する必要があります） コンパイラ AraSDK 2.1.1 (ara-sdk-cnn:2.1.1,dvrun) 試行モデル Ultralytics rtdetr-l / rtdetr-x (HGNetv2)；HF PekingU/rtdetr_r50vd (ResNet-50-VD)もレビュー済み ONNXエクスポート Ultralytics RTDETR.export(format="onnx",imgsz=640、batch=1、dynamic=False、opset=17) → FP32 static ONNX 量子化 AraSDK内部で実行（アナライザー＋キャリブレーションイメージ）→INT8 .dvm（Ultralytics INT8 ONNXではありません） ゴール 完全なエンドツーエンド変換： FP32 ONNX → dvconvert → dryrun estimate → quantize → estimate → emit → .dvm これはランタイム2.1.1でロードされ、 Ara240 DNPU上で完全に動作します。 オブザベーションとNXP HuggingFace Ara240モデルの比較 Qwen2.5-VL / Qwen2.5-CoderなどのAra240モデルの公開版はるかに大きいファイルでも、正常に変換できます。これらのグラフは静的なMatMul / Norm / Softmaxスタックが主体であり、自社開発の移植版のようです。 RT-DETRが失敗する理由は、サイズ（約3300万～4300万個のパラメータ）ではなく、演算子のカバレッジにある。検出デコーダは、マルチスケール変形可能なアテンションと動的なクエリ選択を使用する。 サポートされていない/問題のあるレイヤー（UltralyticsとHF RT-DETRで同じクラス） AraSDK 2.1.1におけるパターンの影響 GridSample / F.grid_sample デコーダー：MS変形可能アテンション（n_points=4、3レベル、6レイヤー） DNPU操作ではありません。ONNXエクスポートでは多数のGridSampleノードが生成されます（Ultralytics rtdetr-lでは18個）。 TopK + 収集/マスク操作 不確実性を最小限に抑えたクエリ選択（num_queries=300） データ依存のインデックス化;コンバータのフォールバックやスケジュール/エミットの失敗 AIFI自己注意 ハイブリッドエンコーダ スケジュールはBDOTとして;見積もりはクラッシュすることがあります(total_wgs:0) Opset-17 ReduceSum (入力としての軸) デコーダーのアテンションパス コンバータ rename_ReduceSum インデックスエラー→ DV_ATen(CPU) アイデンティティ／深度放送 例えばGatherElementsマスクを展開する IRシリアル化中止（DVEEIRブロードキャストレイヤーは不要／深度ディムブロードキャスト） HuggingFace PekingU/rtdetr_r50vd は、同じ変形デコーダ + AIFI パターン (Transformers ソースの RTDetrMultiscaleDeformableAttention + grid_sample + topk) を使用しています。バックボーン部分のみが異なる（ResNet-50-VDとHGNet）。HFに切り替えても、DNPUの完全な変換は不可能です。 私が経験した失敗（段階別） IRシリアル化（フルグラフ） DVEEIRブロードキャストレイヤーは全く必要ありません…BCST…300 ソース: /model.28/Expand_1(TopKマスク拡張) Expand→Concat の書き換え後 DVEEIR放送ケースは、他のディムと同様に深さ寸法でまだサポートされていません まだGatherElements/ブロードキャストの道を進んでいます。 完全再変換 ReduceSum opset-17 → DV_ATen; Mod/Less/Xor/And → DV_ATen; 変換検証 EMAX > 1e-4。 注意:GridSampleはopset ≥16が必要なため、opset 13に落とすことはできません。 ハイブリッド：バックボーン＋エンコーダー（デコーダーのみを除く） ドライラン見積もりツール： DVESIT の総 WG は SINIT で正しく計算されていません… BDOT、400、400、32… total_wgs: 0 (AIFI)。 エミッター: DVEMCUモデルに未知のCPカーネルが存在する...出口139 (ドライランクラッシュを許容した後のダミー/汎用カーネル→実際の.dvmはありません)。 ハイブリッド：バックボーンのみ（純粋なCNN） ドライランは DVEQIR に到達し、IR のシリアル化が完了しました。このパスは CNN バックボーンの DNPU .dvm に対して実行可能です。AIFI + CCFM + デコーダは CPU (onnxruntime) 上に残ります。 私の変換方法（作業アプローチ：ハイブリッド） 現在の運用サポートでは2.1.1では 完全な RT-DETRの.dvmは実現できないため、 パリティ・コンプリートハイブリッドを使用しています。 ステップ1 — FP32静的ONNXのエクスポート（Ultralytics） from ultralytics import RTDETR model = RTDETR("rtdetr-l.pt") model.export(format="onnx", imgsz=640, batch=1, dynamic=False, simplify=True, opset=17) dvrun はこのFP32 ONNX を inet/iwt として扱います。INT8は、AraSDK量子化器とキャリブレーションセットによって後から生成されます。 ステップ2 — FP32サブグラフの抽出（ONNX extract_model） バックボーン出力でカットします（Ultralytics RT-DETR-L）： 入力: 画像 [1,3,640,640] 出力（DNPU / パートA）： /model.3/ec/act/Relu_output_0 → [1,512,80,80] /model.7/Add_output_0 → [1,1024,40,40] /model.10/conv/Conv_output_0 → [1,256,20,20] 残り（CPU / パートB）：これら3つのテンソル → output0 [1,300,6] from onnx import utils as onnx_utils BOUNDARY = [ "/model.3/ec/act/Relu_output_0", "/model.7/Add_output_0", "/model.10/conv/Conv_output_0", ] onnx_utils.extract_model("rtdetr-l.onnx", "partA_backbone.onnx", ["images"], BOUNDARY) onnx_utils.extract_model("rtdetr-l.onnx", "partB_rest.onnx", BOUNDARY, ["output0"]) パートAは純粋なCNN （Conv/Relu/MaxPool/Concat）であり、GridSample/TopK/AIFIは使用していません。 私は、full(images) == partB(partA(images)) を max_abs = 0 (ビット単位) で検証しました。 ステップ3 — AraSDK 2.1.1 (dvrun) を使用してパートAをコンパイルする YAML: srcfw: onnx, inet/iwt = partA_backbone.onnx,dim 3,640,640、calib フォルダー、ignore_mse: 必要に応じて true ホスト：推定器に必要な十分なRAM/スワップ領域（私は32GiB RAM/約100GiBスワップのサーバーを使用しました。16Giのデスクトップでは簡単にメモリ不足になります） コンパイラとボードランタイムの両方を2.1.1のままにしてください。 成功基準:スケジュールシリアライズ、エミッタがAra2プロセッサ互換性を報告、空でない.dvm/ assets (0バイトのkernel.libではない) ステップ4 — ハイブリッド推論の展開 Ara240（ランタイム2.1.1）にPart Aの.dvmファイルをロードします。 ARM上でパートB(partB_rest.onnx)を onnxruntimeで実行します。 DNPUの特徴マップをパートBに入力して検出結果を得る。 モデルパートAは.dvmに変換されますなので、CPUでDNPU+パートBをテストしましたが、誤った検出でクラス出力ゼロでした。一方、AとBのオンクロスはA55 CPUで動作し、正しい出力が得られます。参考のために画像を添付します。 ORT A + B 画像 ハイブリッドA+B NXP/Kinaraへの質問 RT-DETR / Deformable DETRはAra240 2.1.1のサポート/検証済みモデルリストに載っていますか? GridSample / マルチスケール変形可能アテンションのためのカーネルや変換パスは計画されていますか？ AIFIのような注意のために、BDOTがtotal_wgs:0なしでスケジュールできるように、推奨されるONNXの書き換えや制約はありますか? カーネルが開発されるまでの間、このアーキテクチャではハイブリッド（DNPUバックボーン＋CPUデコーダ）が想定されるパターンなのでしょうか？ DESTRグラフにおけるopset(16/17)とコンバーターのReduceSum属性フォームについて公式なガイダンスはありますか? もし他のユーザーがAra240 2.1.1（または3.x）で完全なRT-DETR .dvmファイルを作成することに成功した場合は、ぜひ共有してください。 エクスポート設定（Ultralytics vs HF / lyuwenyu） YAML / dvrunフラグ 変形可能な注意が書き換えられたのか、それともオフロードされたのか 必要であれば、さらにログ（推定器BCST／BDOT／発信器CPカーネルメッセージ）を共有いたします。 ありがとう、 ビジャイ・ラナ Re: RT-DETR cannot fully convert to Ara240 .dvm on AraSDK 2.1.1 — unsupported ops + hybrid workaroun こんにちは、 @vijayranaACL さん。 1. RT-DETR / Deformable DETR はAra240 2.1.1のサポート/検証済みモデルリストに入っていますか? >>>いいえ、このモデルは現在Ara240のサポートリストには含まれていません。 2. GridSample / マルチスケール変形可能アテンションのためのカーネルまたは変換パスは計画されていますか？ 現時点では計画はありません。 その他の質問については、社内チームに確認してからご連絡いたします。 テストしたモデルファイルを教えていただけますか?その後、i.MX95 FRDMボードでテストを行えます。 B.R Re: RT-DETR cannot fully convert to Ara240 .dvm on AraSDK 2.1.1 — unsupported ops + hybrid workaroun これらは.ptからの全レベルのモデル変換ファイルです-> .onnx-> A + B -> DVM(A + int8 on nx B)のハイブリッド。 モデルリンク:https://drive.google.com/file/d/1YhxLetVxP0T85gv0qK1GT1r_T1i25f7P/view?usp=sharing

PIC CLBのユーレカ 特定のPIC MCU(例:pic16f13145ファミリ)には、Configurable Logic Blockと呼ばれるFPGA風のプログラム可能なロジックがあります。 私が使用しているpic16f13115は、それぞれ4入力ルックアップテーブルとDフリップフロップを備えた32個のセルで構成されています。 ツールの使い方を学ぶために、今日はPWM明るさ制御付き6つのLEDのチャーリープレックス対応を実装し、シミュレーションしました。ロジックCADキャンバスを使用する代わりに、Verilogを使用して回路を定義しました。 私は時間の半分くらいを壁に頭を打ち付けて過ごしていた。少しずつ、Verilogを正しく記述し、合成（ビルド）を行い、そしてシミュレーションを実行できるようにした。 CLBでプログラムされたロジックがCPUがスリープ状態でも動作するのは素晴らしい。セーフティに関わる用途に最適です。例えば、複雑な割り込みトリガーロジックの実装に利用できます。CLBロジックをペリフェラル入力・出力に接続する際の柔軟性は非常に高いです。これは、PICの定番となっている、扱いにくいCLCプログラマブルロジックよりもはるかに柔軟性が高い。 私のEureka体験を共有したかっただけです。

芯片版本 你好， 我正在寻找有关 MCIMX6S4AVM08AC 到 MCIMX6S4AVM08AD 的芯片版本修订的一些文档。 这次硅片版本做了哪些改动？我没有找到任何相关文件。 MCXA MCXC MCX N Re: silicon revision 嗨@FelipeBalieiro 请参考此数据表。 https://www.nxp.com/docs/en/data-sheet/IMX6SDLAEC.pdf 数据手册确认MCIMX6S4AVM08AC涵盖硅 Rev. 1.2/1.3，而MCIMX6S4AVM08AD是 Rev. 1.4，是带有 ROM 修改的新 4N81E 掩码集。 相关 ROM 修改信息可在此处找到： i.MX 6Solo/6DualLite 芯片勘误表 此致， 志明

どのNeutronコンバータがi.MX95 BSP LF6.6.52_2.2.xに一致しますか?Toolkit 1.14にはLinux_6.6.52フォルダはありません 私たちは、Toradex Verdin iMX95、B0シリコン上でNeutron NPUを有効にしており、Toradex BSP 7.7.0のYoctoリファレンスマルチメディアイメージを実行しています。これはトリゾンではありません。カーネルはNXP LF6.6.52_2.2.2をベースにした6.6.142-7.7.0-develです。/dev/neutron0が存在し、ドライバーがプローブします。 そのイメージにはNeutronのファームウェアは付属していません。「NeutronFirmware.elf」をインストールしました。およびNXP-IMX/Neutronの「NeutronKernels.bin」、LF-6.6.52_2.2.0の分岐です。ユーザースペースデリゲートとNeutronライブラリは同じブランチから構築されました。label_imageはコンテナ内で実行され、NPUに到達します。 eIQツールキット1.14.0、2025年1月28日付のインストーラーEIQ-TOOLKIT-WIN-1.14.0にはLinux_6.6.52コンバータがありません。そのインストールで最新のLinuxコンバータはLinux_6.6.36_2.1.0です。mobilenet_v1_1.0_224_quant.tflite を変換中--target imx95 はマイクロコードが0x5bfe0804のモデルを生成します。実行時に6.6.52スタックは以下を報告します。 マイクロコードのバージョンが一致しません！0x5bfe0804 (期待値 0xa186aaf2) 委任先は作成され、1つのノードが委任されましたが、分類スコアは空です。同じモデルのCPU上で、Neutronデリゲートなしではgrace_hopper.bmpの「軍服」を正しく返します。 ファームウェアとユーザー空間ライブラリをlf-6.6.36_2.1.0に置き換えるバージョンは不一致を除去し、その後6.6.52カーネルドライバは中性子推論ジョブの作成に失敗し、Neutron Driver 内部故障コード442を発生させます。6.6.36ライブラリはこのカーネルと通信できません。 eIQ Toolkitのリリースノートによると、i.MX95 BSP LF6.6.52_2.2.x用のNeutronコンバーターはeIQ Toolkit 1.14でのみ利用可能とされています。私たちが持っている1.14インストーラーには、それは含まれていません。 どのコンバーターバイナリがこのBSP用のマイクロコード0xa186aaf2を生成しており、どのeIQ ToolkitやNeutron SDKパッケージに出荷されているのでしょうか? Re: Which neutron-converter matches i.MX95 BSP LF6.6.52_2.2.x? Toolkit 1.14 has no Linux_6.6.52 fold こんにちは、 @Giorgos_Sofroniou さん。 プリビルドのコンバーターは eIQ Ubuntu 版のみで利用可能です。 よろしくお願いします、 志明

Eureka on PIC CLB Certain PIC MCUs (e.g., pic16f13145 family) have FPGA-like programmable logic called Configurable Logic Block. The pic16f13115 I'm using has 32 cells each with a 4-input lookup table and a D flip-flop. To learn to use the tools, today I implemented and simulated support for Charlieplexing of 6 LEDs with PWM brightness control. I used Verilog to define the circuit instead of using the logic CAD canvas. I was pounding my head on the wall for about half my time. Slowly, I got the Verilog right, got it to synthesize (build), then got it simulating. It is cool that the CLB programmed logic works even when the CPU is sleeping. It's perfect for safety-critical applications. Can be used, for example, to implement complex interrupt trigger logic. There is great flexibility in hooking up CLB logic to peripheral inputs and outputs. It's much more flexible than the clunkier CLC programmable logic that's been a fixture of PICs. Just thought I'd share my Eureka experience.

EIS BMS reference software source code To evaluate and develop a EIS bms we bought an evaluation board with BCC 7426 (EVBMA7X2YDT1). The problem is that the only reference software i found on NXP package manager is precompiled "SW32K358_EIS_BMU_SW_3.0_CD01_D2605" to be used in combination with "SW32K358_EIS_GUI_SW_3.0_CD01_D2605". The release documentation explain how to use the GUI with S32K358_EIS_BMU board flashing the provided .elf. Is it possible to download the source code of reference software source code, in order to use the GUI with a compatible board (RD-BESSK358BMU) which has quite the same layout (K358 with MC33665A, 2 TPL ports, Debug Header) but different pinout on SPI and UART? Seems strange it has been changed from one board to other one. Thanks Re: EIS BMS reference software source code Hi gferretts The currently released SW32K358_EIS_BMU_SW_3.0_CD01_D2605 software package primarily provides pre-compiled BMU firmware along with the corresponding EIS GUI. Based on the existing release content, No any publicly downloadable complete source code for the BMU reference software.

RT-DETR cannot fully convert to Ara240 .dvm on AraSDK 2.1.1 — unsupported ops + hybrid workaround Hello NXP community, I am converting RT-DETR object detectors for Ara240 DNPU on FRDM i.MX95, targeting AraSDK / runtime 2.1.1 only (not 3.0). I want to share findings and ask whether there is a recommended / supported path for full .dvm conversion of DETR-style models with multi-scale deformable attention. Environment ItemValue Board FRDM i.MX95 + Ara240 Runtime imx-nxp-ara2 2.1.1 (must match compiler) Compiler AraSDK 2.1.1 (ara-sdk-cnn:2.1.1, dvrun) Models tried Ultralytics rtdetr-l / rtdetr-x (HGNetv2); also reviewed HF PekingU/rtdetr_r50vd (ResNet-50-VD) ONNX export Ultralytics RTDETR.export(format="onnx", imgsz=640, batch=1, dynamic=False, opset=17) → FP32 static ONNX Quantization Done inside AraSDK (analyzer + calib images) → INT8 .dvm (not Ultralytics INT8 ONNX) Goal Full end-to-end conversion: FP32 ONNX → dvconvert → dryrun estimate → quantize → estimate → emit → .dvm that loads on runtime 2.1.1 and runs entirely on the Ara240 DNPU. Observation vs NXP HuggingFace Ara240 models Published Ara240 models such as Qwen2.5-VL / Qwen2.5-Coder convert successfully even though they are much larger. Those graphs are dominated by static MatMul / Norm / Softmax stacks and appear first-party ported. RT-DETR fails not because of size (~33–43M params), but because of operator coverage: the detection decoder uses multi-scale deformable attention and dynamic query selection. Unsupported / problematic layers (same class on Ultralytics and HF RT-DETR) PatternWhereEffect on AraSDK 2.1.1 GridSample / F.grid_sample Decoder MS deformable attention (n_points=4, 3 levels, 6 layers) Not a DNPU op; ONNX export produces many GridSample nodes (18 on Ultralytics rtdetr-l) TopK + gather / mask ops Uncertainty-minimal query selection (num_queries=300) Data-dependent indexing; converter falls back or schedule/emit fails AIFI self-attention Hybrid encoder Schedules as BDOT; estimator can crash (total_wgs: 0) Opset-17 ReduceSum (axes as input) Decoder attention path Converter rename_ReduceSum IndexError → DV_ATen (CPU) Identity / depth broadcasts e.g. Expand for GatherElements mask IR serialize abort (DVEEIR Broadcast layer is not needed / depth-dim broadcast) HuggingFace PekingU/rtdetr_r50vd uses the same deformable decoder + AIFI pattern (RTDetrMultiscaleDeformableAttention + grid_sample + topk in Transformers source). Only the backbone differs (ResNet-50-VD vs HGNet). Switching to HF does not make full DNPU conversion possible. Failures I hit (stage by stage) IR serialize (full graph) DVEEIR Broadcast layer is not needed at all … BCST … 300 Source: /model.28/Expand_1 (TopK mask expand). After Expand→Concat rewrite DVEEIR broadcast case is not supported in depth dimension along with other dims yet Still on the GatherElements / broadcast path. Full reconvert ReduceSum opset-17 → DV_ATen; Mod/Less/Xor/And → DV_ATen; conversion validation EMAX > 1e-4. Note: cannot drop to opset 13 because GridSample needs opset ≥ 16. Hybrid: backbone + encoder (exclude decoder only) Dryrun estimator: DVESIT Total WGs are not calculated properly at SINIT … BDOT,400,400,32 … total_wgs: 0 (AIFI). Emitter: DVEMCU Unknown CP kernels present in model … exit 139 (dummy/generic kernels after tolerating dryrun crash → no real .dvm). Hybrid: backbone only (pure CNN) Dryruns reach DVEQIR Serializing IR completed — this path is viable for a DNPU .dvm of the CNN backbone; AIFI + CCFM + decoder stay on CPU (onnxruntime). How I convert (working approach: hybrid) Because a full RT-DETR .dvm is not achievable on 2.1.1 with current op support, I use a parity-exact hybrid: Step 1 — Export FP32 static ONNX (Ultralytics) from ultralytics import RTDETR model = RTDETR("rtdetr-l.pt") model.export(format="onnx", imgsz=640, batch=1, dynamic=False, simplify=True, opset=17) dvrun takes this FP32 ONNX as inet/iwt. INT8 is produced later by AraSDK quantizer + calibration set. Step 2 — Extract FP32 subgraphs (ONNX extract_model) Cut at the backbone outputs (Ultralytics RT-DETR-L): Inputs: images [1,3,640,640] Outputs (DNPU / Part A): /model.3/ec/act/Relu_output_0 → [1,512,80,80] /model.7/Add_output_0 → [1,1024,40,40] /model.10/conv/Conv_output_0 → [1,256,20,20] Rest (CPU / Part B): those 3 tensors → output0 [1,300,6] from onnx import utils as onnx_utils BOUNDARY = [ "/model.3/ec/act/Relu_output_0", "/model.7/Add_output_0", "/model.10/conv/Conv_output_0", ] onnx_utils.extract_model("rtdetr-l.onnx", "partA_backbone.onnx", ["images"], BOUNDARY) onnx_utils.extract_model("rtdetr-l.onnx", "partB_rest.onnx", BOUNDARY, ["output0"]) Part A is pure CNN (Conv/Relu/MaxPool/Concat) — no GridSample / TopK / AIFI. I verified: full(images) == partB(partA(images)) with max_abs = 0 (bit-exact). Step 3 — Compile Part A with AraSDK 2.1.1 (dvrun) YAML: srcfw: onnx, inet/iwt = partA_backbone.onnx, dim 3,640,640, calib folder, ignore_mse: true if needed Host: enough RAM/swap for estimator (I used a 32 GiB RAM / ~100 GiB swap server; 16 Gi desktop OOMs easily) Keep compiler and board runtime both on 2.1.1 Success criteria: schedule serializes, emitter reports Ara2 Processor compatibility, non-empty .dvm / assets (not 0-byte kernel.lib) Step 4 — Deploy hybrid inference Load Part A .dvm on Ara240 (runtime 2.1.1). Run Part B (partB_rest.onnx) on ARM with onnxruntime. Feed DNPU feature maps into Part B → detections. Model Part A is converted into .dvm so i have tested Part A on DNPU + PART B on CPU but it give false output low detection with zero class output but both PART A onnx and PART B onnx work on A55 cpu and gives correct output. I am attaching images for reference. ORT A + B Image Hybrid A + B Questions for NXP / Kinara Is RT-DETR / Deformable DETR on the supported / validated model list for Ara240 2.1.1? Is there a planned kernel or conversion path for GridSample / multi-scale deformable attention? For AIFI-like attention, is there a recommended ONNX rewrite or constraint so BDOT schedules without total_wgs: 0? Is a hybrid (DNPU backbone + CPU decoder) the intended pattern for this architecture until kernels exist? Any official guidance on opset (16/17) vs converter ReduceSum attribute form for DETR graphs? If others have successfully produced a full RT-DETR .dvm on Ara240 2.1.1 (or 3.x), please share: export settings (Ultralytics vs HF / lyuwenyu) YAML / dvrun flags whether deformable attention was rewritten or offloaded Happy to share more logs (estimator BCST / BDOT / emitter CP-kernel messages) if useful. Thanks,          Vijay Rana Re: RT-DETR cannot fully convert to Ara240 .dvm on AraSDK 2.1.1 — unsupported ops + hybrid workaroun Hi @vijayranaACL  1. Is RT-DETR / Deformable DETR on the supported / validated model list for Ara240 2.1.1? >>>No, This model is not currently included in the support list for Ara240. 2. Is there a planned kernel or conversion path for GridSample / multi-scale deformable attention? >>>There are no plans at the moment. I need to confirm with internal team regarding the other questions before getting back to you. Could you please share the model file you tested? I can then run some tests on my i.MX95 FRDM board. B.R Re: RT-DETR cannot fully convert to Ara240 .dvm on AraSDK 2.1.1 — unsupported ops + hybrid workaroun These are the all level of model conversion files from .pt -> .onnx -> hybrid A + B -> DVM of A + int8 onnx B.  model link: https://drive.google.com/file/d/1YhxLetVxP0T85gv0qK1GT1r_T1i25f7P/view?usp=sharing

ADV7535を使用したカスタムi.MX95ボードでのHDMI起動に関するガイダンス NXPチームの皆様、こんにちは。 私はNXP i.MX95カスタムボードを開発中で、ADV7535 MIPI-DSI-to-HDMIブリッジを使用してHDMI出力を有効にしたいと考えています。 私はYocto Linux、デバイスツリー設定、HDMI初期化の初心者です。どうかステップごとにご案内いただけますか: 必要なLinuxカーネルドライバーと設定。 ADV7535およびMIPI-DSIのデバイスツリー（DTS）の変更点。 Yoctoの設定とHDMI初期化について。 参考のデバイスツリーファイル、アプリケーションノート、初心者向けのガイドなど。 再開まで今しばらくお待ちください。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 こんにちは、 この投稿を参考にして、カスタムデザインの新しい画像を作成できます。 Yocto Projectのカスタマイズガイド 私たちのBSPにはブリッジADV7535使うために必要なすべてのドライバがあり、EVKボードのデバイスツリーを基準にしてデバイスツリー構成に組み込めます。 imx95-19x19-evk-adv7535.dtso よろしくお願いいたします。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 i.MX95 ADV7535 HDMIデバイスツリーパッチのレビュー依頼 NXPチームの皆様、こんにちは。 私は、自作のi.MX95 15×15ボード上でADV7535 MIPI-DSI-to-HDMIブリッジを介してHDMI出力を有効にするために、デバイスツリーパッチ（ hdmi_patch_imx95-15x15.patch ）を作成しました。 添付したパッチを確認して、HDMI統合が正しいか確認してもらえますか? HDMI関連の変更点のみに注目してください。 注意: パッチにはイーサネット・スイッチ構成LAN9646含まれています。LAN9646関連の変更は無視し、HDMI統合のみを確認してください。 変更点に漏れや誤りがある場合はお知らせください。また、i.MX95-15x15-FRDMデバイスツリーを参照して、必要な修正案をご提案ください。 再開まで今しばらくお待ちください。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 NXPチームの皆様、こんにちは。 参考資料を共有していただきありがとうございます。ADV7535ブリッジを使用して、自作のi.MX95 15x15ボードでHDMI出力を有効にするための手順を段階的に説明していただきたいです。 説明していただけますか? i.mx95-15x15-FRDMボードで使用されているi.mx95-15x15-FRDM.dtsiファイルを修正する必要があります。 imx95-19x19-evk-adv7535.dtsoを自分のカスタムハードウェアに適合させるにはどうすればよいですか？ 3. 現在、私はi.mx95-15x15-frdmイメージレターを使用していますが、すべて検証済みなので、独自のカスタムマシンイメージを作成します。 各ステップごとに例のコードとコマンドを教えてください。デバイスツリー設定とYoctoの初心者です。 再開まで今しばらくお待ちください。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 こんにちは、 残念ながら、ゼロから行う手順のステップバイガイドはありませんが、EVKベースの新しいレイヤーを使って変更を加えるのはGooアプローチです。前述の投稿を参照してください。 あなたの構成は、このブリッジを使った私たちのリファレンスデザインに合っているようですね。 よろしくお願いいたします。 Re: Guidance for HDMI Bring-Up on Custom i.MX95 Board Using ADV7535 親愛なる@JorgeCas様、 迅速なご返信ありがとうございます。 この投稿で共有されたパッチの変更点 @deepak_k確認していただけますか? EVKボードのADV7535 HDMI構成用の参照DTSOファイルを使用することで、同様のアプローチを採用しています。 実装を確認して、正しく動作させるために必要な追加設定や変更がないか教えていただけますか? ご意見をお聞かせいただければ幸いです。 よろしくお願いします、 アサドゥラ

EIS 电池管理系统参考软件源代码 为了评估和开发 EIS 电池管理系统，我们购买了一块带有 BCC 7426 (EVBMA7X2YDT1) 的评估板。 问题是，我在 NXP 软件包管理器上找到的唯一参考软件是预编译的“SW32K358_EIS_BMU_SW_3.0_CD01_D2605”，需要与“SW32K358_EIS_GUI_SW_3.0_CD01_D2605”结合使用。 版本文档解释了如何使用 GUI 将 S32K358_EIS_BMU 板烧录到提供的 .elf 文件中。是否可以下载参考软件源代码，以便在兼容的开发板（RD-BESSK358BMU）上使用 GUI？该开发板的布局与参考软件基本相同（K358 芯片，MC33665A 芯片，2 个 TPL 端口，调试接口），但 SPI 和 UART 的引脚排列不同。很奇怪，它竟然从一个板换到了另一个板上。 谢谢！ Re: EIS BMS reference software source code 嗨gferretts 当前发布的版本 SW32K358_EIS_BMU_SW_3.0_CD01_D2605该软件包主要提供预编译的 BMU 固件以及相应的 EIS GUI。 根据现有版本内容，BMU 参考软件没有任何可公开下载的完整源代码。

ASA緊急警報処理およびオーディオソース切り替え 主な質問は、Bluetooth/CarPlay/Android 車載経由でSpotifyやFMラジオ局など、他のメディアソースが稼働している間にDABから緊急警報が届いた際の車載の挙動に関するものです。   具体的には、以下の点について技術的なご説明をいただければ幸いです。   自動ソース切り替え:ユーザーがFMラジオやSpotifyを聴いている間にDABでASA緊急警報が受信された場合、システムはどのようにして自動的にDAB緊急アナウンスに切り替わり、関連するアラート情報を表示するのでしょうか?   システム責任：この動作の原因はどのコンポーネントにあるのでしょうか？アラートの検出やトリガーはASAチップ自体が処理しているのか、それともDABレシーバやヘッドユニットが、現在アクティブなメディアソースを中断してDABオーディオにスイッチできる制御インターフェースが必要なのでしょうか?   車載統合:DABレシーバはオーディオソースと表示を直接制御するのか、それとも車載のインフォテインメントシステムにアラート通知やトリガー信号を送り、その後ソース切り替えを行いアラートを表示するのか?   規格と実装:関連するASA/DAB標準はこの挙動やレシーバと車載インフォテインメントシステム間の必要なインターフェースを定義しているのか、それともこれらの実装の詳細はレシーバメーカーや車載OEMに委ねられているのか?   技術的要件:緊急警報が現在アクティブなメディアソースを上書きできるようにするために、特定のハードウェアインターフェース、ソフトウェアAPI、制御信号、またはインフォテインメント統合の要件はありますか?   私たちの目的は、この機能が主にASAレシーバ/デコーダーによって提供されているのか、それとも車載のインフォテインメントシステムとの追加統合が必要なのかを理解することです。   関連する技術ドキュメント、システムアーキテクチャ図、実装ガイドラインなどがあれば大変ありがたいです。 Re: ASA Emergency Alert Handling and Audio Source Switching こんにちは、osmanistlink10さん NXP製品にご関心いただきありがとうございます。 質問の際、NXPの製品部品番号は何ですか?

MX8MP ENET 电压 你好， 我们正在从 MX8X 控制器迁移到 MX8MP 控制器。在旧版本中，ENET0 和 ENET1 支持 1.8V、2.5V、3.3V 电压（RMII 支持所有三种电压，RGMII 仅支持前两种电压）。 MX8MP 取消了 2.5V 选项，但允许选择 1.8V 和 3.3V。绝对最大电压为 3.8V。问题是，当 NVCC_ENET 工作电压为 2.5V 时会发生什么？2.5 不会超过绝对最大值。但是 MAC 信号是如何配置的？长期 2.5V 工作电压会产生什么样的影响？ 我这么问是因为最好不要更新目前电源和VDDIO都为2.5V的旧PHY。 谢谢！ Mike 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: MX8MP ENET voltage 谢谢你，豪尔赫。很喜欢你的头像。 🙂 Re: MX8MP ENET voltage 你好， 正如文档中所述，该接口仅支持两种电压等级，即 1.8 V 和 3.3 V。即使 2.5 V 在整体工作电压范围内，2.5 V 信号也可能不符合有效逻辑电平的规定阈值，这可能会导致不可预测的行为。 我建议此接口使用 1.8V 或 3.3V 电压。 顺祝商祺！

MX8MP ENET voltage Hello, We are migrating from an MX8X controller to MX8MP. In the older one, ENET0 and ENET1 supported voltage 1.8V, 2.5V, 3.3V (RMII all three, RGMII first two only). MX8MP removes the 2.5V option, but allows 1.8V and 3.3V choices. Absolute Vmax is 3.8V. The question is, what happens in a 2.5V operation on NVCC_ENET? 2.5 will not exceed the absolute max. But how are the MAC signals configured and what kind of impact would 2.5V operation have long term? I ask because it would be great to avoid updating the older PHY that is currently running both its supply and VDDIO on 2.5V. Thank you, Mike Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: MX8MP ENET voltage Thank you, Jorge. Love the avatar.  🙂 Re: MX8MP ENET voltage Hello, As mentioned in the documentation, the interface supports only two voltage levels, 1.8 V and 3.3 V. Even if 2.5 V is within the overall operating voltage range, 2.5 V signals may not meet the specified thresholds for valid logic levels, which could result in unpredictable behavior. I recommend using either 1.8 V or 3.3 V for this interface. Best regards.