在 i.MX8M Plus 和 TIM-VX/VSINPU 上，GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。： i.MX8M Plus，aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时，带有 VSINPUExecutionProvider（静态链接到 libtim-vx.so） Vivante OpenCL ICD 已存在且功能正常（Vivante.icd → libVivanteOpenCL.so） 目标： 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试（MLPerf loadgen 测试框架），以便与已收集的现有 NPU（VIP8000Nano）和 CPU 基准测试结果进行比较。 已确认有效的功能： 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备： 设备 0：GC7000UL.6204.0000 设备 1：VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR，没有错误，通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度： ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so（OVXLIB/vsi_nn_* API）。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换（VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等）。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex，但是从 OVXLIB/TIM-VX 到该调用没有明显的管道，这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心，而不管设备索引如何。 具体问题： 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标？或者，此版本中的图编译器是否设计为仅限 NPU？我如何验证是否可以以这种方式运行它？ 如果 TIM-VX 上游支持 GPU 目标图编译，但 NXP 提供的版本中未启用，是否有构建标志/SDK 元器件可以启用它？ 如果无法通过 TIM-VX/ORT 获得支持，NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理（例如通过 OpenCL/OpenVX 层，因为该部分协议栈已被确认功能正常），或者是否有示例应用程序、SDK 组件或参考实现可供我们参考？ 我目前是一名学生，正在尝试进行这项实现，并在 GPU 上运行 ORT，请问是否有任何方法或途径可以使用 GPU 进行推理？ 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO ， 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理，您应该使用 GPU 委托，它允许由 GPU 加速支持的操作，而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南，以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例，可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题，请分享您的模型、BSP 版本以及您正在使用的命令，我将很乐意为您提供进一步的帮助。 此致， 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现，GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU（Arm Mali G310）中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下：VX 代理 ==> TIM-VX ==> GPU/NPU（统一驱动程序） ==> I.MX 8 系列 NPU 和 GPU（GC7000、GC7000L、GC7000UL）。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时，它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作？或者是否有任何手动覆盖或我可以实现的技术，以便我可以手动将编译目标设置为 NPU 或/和 GPU？ 非常感谢您的回复。 亲切的问候， IMX8MPLUS #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好， 是的，还有一条可能的途径，但我不会尝试强制 VSINPU 执行提供程序使用 GC7000UL。 您的结果强烈表明，当前的 NXP TIM-VX/OVXLIB 版本主要针对 VIP8000 NPU 进行了布线。libGAL.so 中的 gcoHAL_SetDeviceIndex() 函数本身并不能将 NN 图重定向到 GPU。 首先在 ONNX 运行时环境之外，使用小型模型直接测试 TIM-VX/OpenVX。 检查您的特定 OVXLIB 是否公开了 GC7000UL/GPU NN 目标。 将您的 NXP TIM-VX 版本与上游 TIM-VX 版本进行比较，特别是其多设备/平台支持。 如果 TIM-VX 无法为 GC7000UL 编译，则直接使用 Vivante OpenCL/OpenVX 堆栈进行 GPU 基准测试。 对于你的 MLPerf 项目，GPU 路径不一定需要 ORT。您可以创建一个单独的 GC7000UL 后端，并将其连接到用于 CPU/NPU 的同一 LoadGen 线束。 所以我会这样组织它： MLPerf 负载生成器 → ResNet50 GPU 后端 → OpenCL/OpenVX → GC7000UL 而不是： MLPerf → ORT → VSINPU → 以某种方式强制 GPU 致以最诚挚的问候， 费萨吉

[SPSDK][i.MX95] nxpele read-common-fuse が失敗する こんにちは、 私はIMX95 19x19 EVKボードでセキュアブートを有効にする作業に取り組んでいます。SPSDKを使用して画像に署名することに成功しました。さて、ヒューズを書き込む前に、`nxpele` を使用してそれらを読み取ろうとしたのですが、以下のエラーが発生します。 ``` $ NXPELE -f MIMx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: レスポンスのメッセージSIZEが無効: 0x4 詳細はデバッグログファイル /home/user/.local/state/spsdk/3.11.0/log/debug.log を参照してください ``` ログには次のように記載されています。 ``` $ tail -60 /home/ユーザー/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"レスポンスのメッセージサイズが無効です: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: レスポンスのメッセージサイズが無効です: 0x4 DEBUG:spsdk:*************************************************** (開始から206ms、spsdk_logger.py:212) DEBUG:spsdk:* SPSDK デバッグログ記録開始 2026-09-03 15:58:44 * (開始から 207ms、spsdk_logger.py:213) DEBUG:spsdk:* SPSDK バージョン: 3.11.0* (開始から207ms、spsdk_logger.py:215) デバッグ:spsdk:* Python バージョン: 3.14.4* (開始から207ms、spsdk_logger.py:216) DEBUG:spsdk:* OS バージョン: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (開始から208ms、spsdk_logger.py:217) DEBUG:spsdk:* 最後のコマンド: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (開始から 208ms、spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (開始から208ms、spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot書き込み -> 無効 (開始から 210ms、 __init__ .py:50) デバッグ:spsdk.uboot.uboot:UbootREAD UNTIL <- => (開始から210ms、uboot.py:271) DEBUG:spsdk.uboot.uboot:チェック中無効なコマンドを送信してシリアルコンソールを開いた場合: "invalid\r\n不明なコマンド 'invalid' - 'help' を試してください\r\nu-boot=> " (開始から 224ms、uboot.py:209) デバッグ:spsdk.utils.database:現在データベースフィンガープリントハッシュ: f0f0598d4e6ae6c755d693693f232e30537cfb3b (開始から226ms、database.py:1967) デバッグ:spsdk.utils.database:ロード済みキャッシュからのデータベース: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (開始から226ms、database.py:1976) デバッグ:spsdk.utils.misc:読み込み中/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml からのテキストファイル (開始から 226ms、misc.py:312) INFO:spsdk.ele.ele_comm:ELEコミュニケーターは、mimx9596のアドレス92800000で196608 Bサイズのバッファを使用しています。リビジョン：最新ターゲット。 デバッグ:spsdk.ele.ele_comm:ELEmsg 0x92800000 0x30000 0602971788000000 (開始から245ms、ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot書き込み -> ele_message 0x92800000 0x30000 0602971788000000 (開始から246ms、 __init__ .py:50) デバッグ:spsdk.uboot.uboot:UbootREAD UNTIL <- => (開始から246ms、uboot.py:271) デバッグ:spsdk.ele.ele_comm:RawELEメッセージ出力: ele_message 0x92800000 0x30000 0602971788000000 060497e1d600000000000000000000200u-boot=> (開始から256ms、ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped出力: 060497e1d600000000000000 (開始から256ms、ele_comm.py:460) デバッグ:spsdk.apps.utils.utils:SPSDK:応答メッセージのサイズが無効です: 0x4 (開始から257ms、utils.py:182) トレースバック（最新の呼び出し）： ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py",172行目、ラッパー内 retval = function(*args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",safe_main の 2189 行目 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1631行目、 __call__ return self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1552行目、メイン rv = self.invoke(ctx) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py"、2032行目、invoke内 return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1415行目、invoke内 return ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",910行目、invoke内 return callback(*args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py",46行目、new_func内 return f(get_current_context().obj, *args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",575行目、cmd_read_common_fuse内 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",588行目、ele_read_common_fuse内 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py",send_message 関数の 519 行目 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py",decode_response の 1235 行目 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py",decode_response の 346 行目 raise SPSDKParsingError(f"レスポンスのメッセージサイズが無効です: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: レスポンスのメッセージサイズが無効です: 0x4 「`」 注：私は`SPDK 3.11.0`を使用しています。 SPSDKのGitHubページにも問題を報告しました。https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 どんなご支援でも大変ありがたく思います。 ありがとうございました。 BR、 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails こんにちは、ジョアンクシー 私はLinux BSPバージョンLF6.18.20_2.0.0(yocto wrynose)を使っています そして、これが nxpele get-info の出力です。 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails このコマンドでどのELEのFWバージョンを使っているか教えてもらえますか?もう一度確認させてください Re: [SPSDK][i.MX95] nxpele read-common-fuse fails この問題を再現し、内部データベースを確認したところ、これは既知の問題であり、spsdk 3.12.0で修正される予定です。

88W8887 RF準拠試験 親愛なる、 私たちは88W8887チップセットをベースにしたWi-Fi/Bluetoothモジュールを使用しています。製品準拠のために、連続パケットの送信や受信モードなどのRFテストを行う必要があります。別のモジュール88W8997については、以下のアプリケーションノードAN14114をたどっています。しかし、アプリケーションノートには88W8887がサポートされているとは記載されていません。 アプリケーションノートにはmwifiexドライバを使用しています。コードを見る限り、88W8887はドライバーがサポートしているはずです。残念ながら、ドライバにはファームウェアファイルsd8887_wlan_a2.binが必要ですが、私たちは見つけることができませんでした。 88W8887でRFテストを行う推奨方法(ANに記載されているものと似ています)は何ですか?NXPはまだこのユースケースをサポートしていますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは@shaun_wu 提供されたリンクにアクセスできません。アクセスを得るために自分の側で何かやるべきことはありますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは、 @YoshiDev さん。 8887はrf_test_modeをサポートしていません。mfg_modeを使えばいい。以下のリンクを参照できる https://www.nxp.com/webapp/Download?colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license よろしくお願いいたします。 ショーン Re: 88W8887 RF compliance testing こんにちは、 @YoshiDev さん。 この文書は機密情報です。NDAチームにチケットを提出してアクセス権を得ることもできます。 よろしくお願いいたします。 ショーン

Wrynose SDKのPowerPCサポート こんにちは、 私たちはDunfellからWrynose Yocto SDKへのT4240rdbベースのボードを移行しようと考えています。Wrynose SDKでPowerPCのボードはサポートされていますか? もし無理なら、PowerPCボードのサポートを得るための選択肢は何でしょうか。 ありがとうございます スッバラオ・ナラジャラ タレスグループのシニアエンジニア Re: PowerPC support for Wrynose SDK こんにちは、 PowerPC/T4240RDBボードはNXP Wrynose Yocto SDKではサポートされていません。これはダンフェル以外のすべての新しいNXP Yoctoリリースに適用されるよく知られた制限です。 WrynoseでPowerPCがサポートされていない理由 NXPのWrynose SDK(Yocto 6.0)は ARMベースの i.MX およびLayerscapeプロセッサ専用です。QorIQ Tシリーズ(T4240を含む)は Power Architecture(e6500コア)を使用しており、これは新しいYocto SDKリリースには引き継がれていません。これはNXPのより広範な戦略と一致している。 「QorIQ SDKは、QorIQ PowerPCベースのPシリーズおよびTシリーズプロセッサファミリー向けの、完全機能かつ成熟したYoctoベースのソフトウェアキットです...Layerscape SDKはLayerscapeファミリープロセッサのハイブリッドUbuntuベースのソフトウェアキットであり、今後はLayerscapeプラットフォーム上で最新のソフトウェアを提供する主要な配信手段となるでしょう。」 T4240RDBにおける最後の公式NXP対応YoctoリリースはDunfell(Yocto 3.1)です。新しいYoctoのリリース(Scarthgap、Wrynoseなど)にはT4240RDBや他のPowerPC Tシリーズボードは含まれていません。 既知のビルドエラーもglibcレベルでこれを裏付けています — ポストDunfell Yoctoでe6500 PowerPC64アーキテクチャ向けにビルドしようとすると、以下のような結果が出ます。 configure: error: The e6500 subspecies of powerpc64 is not supported. 選択肢 オプション1：ダンフェルに滞在する（T4240RDBに推奨） QorIQ Yocto SDKのダンフェル支部は、今もT4240RDBの最新の公式サポートYoctoリリースです。以下でアクセスできます: https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell これは、安定しサポートされたYocto環境を必要とするPowerPC T-Seriesの顧客にNXPが推奨する道です。 オプション2：コミュニティ/アップストリームソースを使用する NXPのPower Architecture PシリーズおよびTシリーズお客様向けの公式ガイダンスは、新しいカーネルおよびU-Bootバージョンについては 、上流のコミュニティソース を活用することです。 「今後は、Power ArchitectureベースのPシリーズおよびTシリーズプラットフォームを利用するお客様には、kernel.org や denx.de(uBoot)などのコミュニティソースから直接イネーブルメントソフトウェアを入手することを推奨します。」 つまり、メインラインソースを使ってT4240RDB向けの新しいカーネル(例:5.xや6.x)を構築できますが、これは手動の統合作業が必要であり、NXPがサポートするSDKではありません。 オプション3:ARMベースのレイヤースケーププラットフォームへの移行 もし新しいYocto SDK(Wrynoseを含む)が必須条件であれば、唯一の方法は ハードウェアプラットフォームを ArmベースのLayerscape® プロセッサ(例:LX2160A、LS1046A、LS1088A)に移行することです。これらはWrynoseおよびFUTUREのNXP Yoctoリリースで完全にサポートされています。これは大規模なハードウェア再設計の取り組みではあるが、NXPの長期的なロードマップに沿ったものである。 オプション4:NXPプロフェッショナル/プレミアムサポート カスタムBSP作業や新しいYoctoベースラインへのT4240RDB移植が必要な場合、NXPは プロセッサーおよびマイクロコントローラのプロフェッショナルサポートを提供しており、Linux/Yoctoのレシピ支援やNXPエンジニアへの直接アクセスも可能です。   よろしくお願いします。

PowerPC support for Wrynose SDK Hi, We are looking to migrate our T4240rdb based board from Dunfell to Wrynose Yocto SDK. Are PowerPC boards supported in Wrynose SDK ? If not what are our options to get support for PowerPC boards. Thanks, Subbarao Nalajala Senior Engineer at Thales Group Re: PowerPC support for Wrynose SDK Hello, PowerPC/T4240RDB boards are NOT supported in the NXP Wrynose Yocto SDK. This is a well-established limitation that applies to all newer NXP Yocto releases beyond Dunfell. Why PowerPC is Not Supported in Wrynose NXP's Wrynose SDK (Yocto 6.0) is exclusively targeted at ARM-based i.MX and Layerscape processors. The QorIQ T-Series (including T4240) uses the Power Architecture (e6500 core), which has not been carried forward into the newer Yocto SDK releases. This is consistent with NXP's broader strategy: "QorIQ SDK is a fully featured and mature Yocto-based software kit for QorIQ PowerPC-based P-series and T-series family of processors... Layerscape SDK is the hybrid Ubuntu-based software kit for the Layerscape family of processors, and going forward will be the primary delivery mechanism for the most up-to-date software on Layerscape platforms." The last officially NXP-supported Yocto release for T4240RDB is Dunfell (Yocto 3.1). Newer Yocto releases (Scarthgap, Wrynose, etc.) do not include T4240RDB or other PowerPC T-Series boards. A known build error also confirms this at the glibc level — attempting to build for the e6500 PowerPC64 architecture in post-Dunfell Yocto results in: configure: error: The e6500 subspecies of powerpc64 is not supported. Your Options Option 1: Stay on Dunfell (Recommended for T4240RDB) The Dunfell branch of the QorIQ Yocto SDK remains the latest officially supported Yocto release for the T4240RDB. You can access it at:  https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell This is the path NXP recommends for PowerPC T-Series customers who need a stable, supported Yocto environment. Option 2: Use Community/Upstream Sources NXP's official guidance for Power Architecture P-Series and T-Series customers is to leverage upstream community sources for newer kernel and U-Boot versions: "Going forward, we encourage customers using Power Architecture-based P-series and T-series platforms to get the enablement software directly from the community sources like kernel.org and denx.de (uboot)." This means you can build a newer kernel (e.g., 5.x or 6.x) for T4240RDB using mainline sources, but this requires manual integration work and is not a turnkey NXP-supported SDK. Option 3: Migrate to an ARM-Based Layerscape Platform If a newer Yocto SDK (including Wrynose) is a hard requirement, the only path is to migrate the hardware platform to an ARM-based Layerscape processor (e.g., LX2160A, LS1046A, LS1088A), which are fully supported in Wrynose and future NXP Yocto releases. This is a significant hardware redesign effort but aligns with NXP's long-term roadmap. Option 4: NXP Professional/Premium Support If you need custom BSP work or a porting effort for T4240RDB on a newer Yocto baseline, NXP offers Professional Support for Processors and Microcontrollers, which includes Linux/Yocto recipe assistance and direct access to NXP engineers.   regards

i.MX RT1064 - PEmicro 连接助手错误和启动配置意外更改 您好， 我正在使用i.MX RT1064控制器，并通过 MCUXpresso IDE 中的PEmicro Multilink接口进行调试/烧录。 有时，我在尝试连接目标设备时会遇到附件中的“PEmicro 连接助手”错误。这个问题似乎是随机发生的；我还没有发现任何特定的软件活动、代码更改或硬件事件会持续触发信号它。 我观察到，当出现此错误时，控制器的启动配置似乎发生了意外变化。在这种状态下，我无法对设备进行刷机或调试。我目前唯一能恢复的方法是将启动配置恢复到其原始设置——内部闪存模式，之后刷写和调试功能就能再次正常工作了。 一些补充细节： MCU：i.MX RT1064 调试探针：PEmicro 多链路通用 Rev E IDE：MCUXpresso IDE 有人遇到过类似的问题吗？ 我希望您能就以下方面提供指导： 什么原因会导致启动配置意外更改？ 是否存在调试器或应用程序代码可能影响启动配置的已知场景。 防止这种情况发生的建议方法。 能否在不手动更改的情况下通过软件更改启动配置 我附上了错误信息的截图供您参考。 谢谢！ i.MX RT106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好， 您能帮我解答以下问题吗？ 你用的是定制主板还是EVK主板？ 您使用的是哪个版本的SDK和IDE？ 你烧断过熔丝吗？ 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置？ 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 我使用的是定制电路板，但这个问题在 EVK 上也出现过。 SDK 版本：26.03.00 IDE 版本：25.6.136 我们没有烧断熔丝。 我们通常使用内部启动模式来烧录代码并进行正常操作，但它会随机导致一些意想不到的问题，所以我们将其更改为串行下载模式，擦除闪存，然后再将其改回内部启动模式，之后再次烧录代码。 请查看附件图片以获取启动配置信息。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好@Subhasri_S ， 通过在 POR_B 的上升沿对 BOOT_MODE0 和 BOOT_MODE1 输入进行采样来初始化 BOOT_MODE 寄存器。对这些输入进行采样后，它们的后续状态不会影响内部 BOOT_MODE 寄存器的内容。 如果 BT_FUSE_SEL = 0，则可以使用 GPIO 引脚而不是 eFuse 来设置特定的启动配置参数。 能否请您在问题出现时，在 RESET 过程中测量一下 BOOT_MODE 和 BT_CFG 引脚的值？ 关于此问题的另一种可能结论，请参阅以下知识库文章： 知识库： RT板恢复调试器连接问题 “当闪存中包含异常应用程序（访问内存不存在、内存损坏、时钟配置错误等）时，会导致板处于未知状态，此时调试器无法控制内核。但是，当将核心置于串行下载器模式时，它将使核心处于已知状态，这样，调试器就可以控制核心。 因此，当RT板出现调试器问题时，尝试在串行下载模式下批量擦除外部闪存，这样就能使板载调试器恢复正常状态。 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 您好，请提供问题发生时记录的 BOOT_MODE 和 BOOT_CFG 引脚值。

Wrynose SDK 对 PowerPC 的支持 您好， 我们正在考虑将基于 T4240rdb 的开发板从 Dunfell 迁移到 Wrynose Yocto SDK。Wrynose SDK 是否支持 PowerPC 板？ 如果以上方法都不行，我们还有哪些途径可以获得对PowerPC主板的支持？ 谢谢！ 苏巴拉奥·纳拉贾拉 泰雷兹集团高级工程师 Re: PowerPC support for Wrynose SDK 你好， NXP Wrynose Yocto SDK 不支持 PowerPC/T4240RDB 板。这是所有较新的 NXP Yocto 版本（Dunfell 之后）都存在的既定限制。 为什么 Wrynose 不支持 PowerPC？ NXP 的 Wrynose SDK（Yocto 6.0）专门针对基于 ARM 的 i.MX 和 Layerscape 处理器。QorIQ T 系列（包括 T4240）采用Power 架构（e6500 内核） ，但该架构并未延续到较新的 Yocto SDK 版本中。这与恩智浦的整体战略是一致的： “QorIQ SDK 是一款功能齐全、成熟的基于 Yocto 的软件工具包，适用于 QorIQ 基于 PowerPC 的 P 系列和 T 系列处理器……Layerscape SDK 是一款基于 Ubuntu 的混合型软件工具包，适用于 Layerscape 系列处理器，未来将成为 Layerscape 平台上最新软件的主要交付机制。” NXP 官方支持的最后一个适用于 T4240RDB 的 Yocto 版本是 Dunfell（Yocto 3.1） 。较新的 Yocto 版本（Scarthgap、Wrynose 等）不包含 T4240RDB 或其他 PowerPC T 系列板。 一个已知的版本错误也证实了这一点，该错误发生在 glibc 层——尝试在 Dunfell 事件后的 Yocto 中为 e6500 PowerPC64 架构进行版本会导致以下结果： configure: error: The e6500 subspecies of powerpc64 is not supported. 您的选择 方案一：留在邓费尔（推荐给 T4240RDB 用户） QorIQ Yocto SDK 的 Dunfell 分支仍然是 T4240RDB 最新官方支持的 Yocto 版本。您可以通过以下方式访问： https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell 这是 NXP 推荐给需要稳定、受支持的 Yocto 环境的 PowerPC T 系列客户的路径。 方案二：使用社区/上游资源 NXP 针对 Power Architecture P 系列和 T 系列客户的官方建议是，利用上游社区资源获取更新的内核和 U-Boot 版本： “今后，我们鼓励使用基于 Power Architecture 的 P 系列和 T 系列平台的客户直接从 kernel.org 和 denx.de (uboot) 等社区资源获取启用软件。” 这意味着您可以使用主线源代码为 T4240RDB 构建更新的内核（例如 5.x 或 6.x），但这需要手动集成工作，并且不是 NXP 支持的交钥匙 SDK。 方案三：迁移到基于 ARM 的 Layerscape 平台 如果必须使用较新的 Yocto SDK（包括 Wrynose），则唯一的途径是将硬件平台迁移到基于 ARM 的 Layerscape 处理器（例如 LX2160A、LS1046A、LS1088A），这些处理器在 Wrynose 和未来的 NXP Yocto 版本中都得到完全支持。这是一项意义重大的硬件重新设计工作，但符合恩智浦的长期发展路线图。 选项 4：NXP 专业/高级支持 如果您需要定制 BSP 工作或将 T4240RDB 移植到更新的 Yocto 基线，NXP 可提供处理器和微控制器的专业支持，包括 Linux/Yocto 配方协助和直接联系 NXP 工程师。   此致问候

i.MX95 Neutron：四分之一的相同 INT4 LLM 测试结果存在 NPU/CPU 差异 摘要 我们在 i.MX95 上运行一个量化的 ONNX，一次在 CPUExecutionProvider 下，一次在 CPUExecutionProvider 下。 NeutronExecutionProvider。两条臂给出的答案并不一致：在 2,466 对配对样本中 多项选择题中，25.7% 的答案与实际答案不同（MMLU 中为 43.6%）。免费 同样的情况也会发生——在 MMLU 提示符下，19 代中有 13 代产生了 不同的答复信。 这不是措辞上的区别。这是模型给出的答案不同的问题。与此同时，综合基准准确率仅下降了 1.8 个百分点。 我们想了解 Neutron 运行时在数值上做了哪些工作，从而产生这些结果。 这一点，以及这种程度的规模是否在预期之内。 设置 请确认您那边可以复现：模型来自 UG10166 表 2，量化方式为： 你自己的配方，未经修改。 - 主板：i.MX95 19x19 EVK (IMX95LPD5EVK-19)，LPDDR5 - BSP：LF6.18.2_1.0.0，设备树 imx95-19x19-evk-neutron.dtb - 运行时：来自 BSP 的 ONNX Runtime 1.22.0 + NeutronExecutionProvider - 中子变流器：3.1.3 - 型号：meta-llama/Llama-3.2-1B-Instruct - 量化：NXP/eiq-olive rev aae820e， examples/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 转换：convert_ort_models_to_neutron.py，应用于 CPU arm 的 model.onnx - 环境：NEUTRON_CMA_512SLOTS=6 两条臂均源自同一个量化模型。The NPU Arm is that model passed through convert_ort_models_to_neutron.py。我们记录源图的 安全散列算法 (SHA)-256 值， 外部砝码——在转换时使用，并在每次测量前重新验证，因此 没有第二次量化运行，也没有第二次导出。 我们观察到的 1.每四件物品中就有一件会得到不同的答案。 来自 MMLU、ARC-Challenge 和 PIQA 的 2,466 个配对项目，零次测试，采用对数似然法评分 候选延续 - 每个候选者向前推进一次，不进行生成，不进行抽样。 对于每个基准，首先计算答案发生变化的项目的比例，然后计算答案发生变化的项目的比例。 正确性已改变： - MMLU（4 个选项）：43.6% 的答案发生了改变，27.1% 的正确性发生了改变。 - ARC挑战（4个选项）：21.3%的答案被修改，13.3%的正确性被修改。 - PIQA（2个选项）：9.4%的答案被更改，9.4%的正确性被更改。 总计：答案更改率为 25.7%，正确率更改率为 17.3%。 这两个数字之所以不同，是因为三分之一的变化（634 处变化中的 208 处）是从一个错误值转移到另一个错误值。 对另一个错误答案的回应——一种真正能带来准确性的行为改变 未受影响。由于PIQA是二进制的，因此不存在这种盲点，它的两个数值完全一致。 确切地。 2. 自由生成中也会发生同样的情况——答案本身会发生变化。 50 个提示，贪婪解码，64 个令牌。对于 MMLU 提示符，预期输出开始 连同答题信一起，就可以直接从生成过程中读取答案。 （n = 19）： - 两臂答案字母不同：19 封信中有 13 封不同 - CPU 正确率：7/19 - 正确答案：19题中的6题 - 双方都犯错且错误答案不同的分歧：13 例中有 6 例 三分之二的答案发生了变化，但得分基本相同（7 分对 6 分）。 样本量很小——我们仅将其作为示例进行报告；以上2466项测量结果。 是定量分析。 举个例子，原话如此。提示列出了四个选项，并要求写一封信。 预期答案是 😧 CPU：“A\n解释：表达式 9(9m + 3t) 等价于 81m + 27t。 最佳答案是A。 NPU：“C\n最佳答案是C。” 两者都错了，错的点不同，而且没有基准分数会记录这一点。 3. 这种分歧在第一个正向传播中就存在，而不是逐渐积累的。 在这种信件格式中，第一个生成的令牌就是答案，并且有 60% 的生成结果都是如此。 两者之间已经存在差异——这是仅由预填充过程生成的令牌，尚未经过任何解码。 步。在所有 50 个提示中，分歧曲线先急剧上升，然后趋于平缓：84% 令牌 4，98% 到令牌 64。这就是初始差异传播的样子 在贪婪解码模式下，不会通过 KV 缓存累积错误。 4. 总体准确率掩盖了所有这些问题。 CPU 使用率为 50.28%，而 Neutron 使用率为 48.50%，相差 1.78 个百分点，且没有其他问题。 三个基准指标各自都具有重要意义。仅限于以下 634 项： 双方意见不一致，CPU 的正确率是 37.1%，而 Neutron 的正确率是 30.1%——235 对 在已决定的项目中，有 191 个，即 55/45，而对称噪声会给出 50/50。 我们排除了哪些选项 - 静默 CPU 回退：ORT 分析报告显示 80/80 个 MatMulNBits 处于开启状态 NeutronExecutionProvider，CPU 占用率为 0。不进行局部植入。 - 两种不同的模型：相同的源文件，图的 安全散列算法 (SHA)-256 值和外部权重 转换时记录，并在得分前重新核实。 - 采样：全程贪婪解码；无温度、无 top-k、无 top-p。 - 不同的输入：两个 Arm 都从同一个物品文件中按相同的顺序读取数据。 相同的固定种子。 - 评分指标：板 仅 捕获 每个标记的对数概率；所有决策 逻辑在主机上离线运行，两个 Arm 的逻辑完全相同。 - NPU 上的运行间噪声：在同一 Neutron 会话中重复播放相同的项目 产生比特相同的对数概率。NPU Arm是可重复的；差异 这是针对CPU的，而不是针对CPU本身的。 我们的问题是 这是 Neutron-S 上 INT4 路径的预期行为吗？如果是，我们应该怎么做？ 验证在 NPU 上部署 LLM 的可行性，前提是总体基准测试准确率明显高于预期。 没有显示出来吗？ 我们并未假定存在缺陷。浮点CPU内核和 整数 NPU 路径是正常的，我们想知道您认为的量级是多少。 正常情况下，你们接受 LLM 端口到 Neutron 的标准是什么？如果 四分之一的答案发生变化在预期之内，这对我们来说是件好事。 了解并围绕其进行设计。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 谢谢你的快速回复！ DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 嗨@DamienSCHNEBELEN IMX95 NPU 只能运行矩阵乘法运算，其 LLM 性能在 NPU 上实际上只是中等水平。因此，您观察到的现象在可预测的范围内，我们不建议在 NPU 上运行 LLM 模型。 B.R

Audifortレビュー：本当に一晩で耳鳴りを止めることができるのか？ Audifortレビュー：本当に一晩で耳鳴りを止めることができるのか？ 毎日耳鳴り、ブンブン、カチカチという音に悩まされているなら、救いを求める過程がどれほど必死になるかをご存知でしょう。オンラインで解決策を探していると、次のような液体栄養剤の積極的な広告を目にするかもしれません。 オーディフォート それは、即効性がある、あるいは一晩で耳鳴りが解消されるといったことを示唆するものです。 簡潔に言うと、答えはノーです。Audifortは耳鳴りを一夜にして止めるものではありません。 経口サプリメントや天然の点滴薬では、慢性的な耳鳴りを即座に治したり、損傷した聴神経を24時間以内に再生したりすることはできません。 しかし、だからといってその公式が無意味だというわけではない。奇跡の治療薬ではなく、天然の栄養補助食品として現実的に評価すると、オーディフォートは内耳の血管を栄養し、過剰に活動している神経信号を時間をかけて鎮めるのに役立つ栄養素を提供します。 この Audifortのレビューでは、販売促進のためのマーケティングにとらわれず、このドロップが実際にどのように作用するのか、その主要成分、現実的な効果発現までの期間、潜在的な副作用、そして偽のオンライン広告を回避する方法などを分析します。

88W8887 射频合规性测试 亲爱的， 我们使用的是基于 88W8887 芯片组的 wifi/蓝牙模块。为了确保产品符合规范，我们需要进行多项射频测试（tx 连续数据包、rx 模式等）。对于另一个模块 88W8997，我们遵循了以下应用节点：AN14114。然而，该应用笔记并未提及支持88W8887。 该应用笔记使用了mwifiex驱动程序。查看代码可知，驱动程序应该支持 88W8887。遗憾的是，该驱动程序需要固件文件sd8887_wlan_a2.bin，但我们未能找到该文件。 在 88W8887 上运行 RF 测试（类似于 AN 中描述的方法）的推荐方法是什么？NXP 是否仍然支持这种使用场景？ 此致敬礼， 吉 Re: 88W8887 RF compliance testing 嗨@shaun_wu 我无法访问提供的链接。我这边需要做些什么才能获得访问权限？ 此致敬礼， 吉 Re: 88W8887 RF compliance testing 你好@YoshiDev 8887 不支持 rf_test_mode。你可以使用 mfg_mode。您可以参考以下链接： https://www.nxp.com/webapp/Download? colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license 顺祝商祺！ 肖恩 Re: 88W8887 RF compliance testing 你好@YoshiDev 该文件属于机密文件。您可以向NDA团队提交工单以获取访问权限。 顺祝商祺！ 肖恩

88W8887 RF compliance testing Dear,  We are using a wifi/bluetooth module based on the 88W8887 chipset. For product compliance, we need to do a number of RF testing (tx continious packets, rx mode etc.). For another module 88W8997, we have followed the following application node: AN14114. However, the application note does not mention the 88W8887 as supported.  The application notes uses mwifiex driver. Looking at the code, the 88W8887 should be supported by the driver. Unfortunately, the driver requires a firmware file sd8887_wlan_a2.bin which we were not able to find.  What is the recommended way to run RF tests (similar as described in the AN) on the 88W8887? Does NXP still support this usecase? Kind regards, Yoshi  Re: 88W8887 RF compliance testing Hi @shaun_wu  I do not have access to the provided link. Anything I need to do on my side to get access? Kind regards, Yoshi Re: 88W8887 RF compliance testing Hello @YoshiDev  8887 do not support rf_test_mode. you could use mfg_mode. You could refer to following link: https://www.nxp.com/webapp/Download?colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license Best Regards Shaun Re: 88W8887 RF compliance testing Hello @YoshiDev  The document is confidential. You could submit a ticket to NDA team get access. Best Regards Shaun

S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hello,  I tried running the example PIL S32CT with MBDT S32K3xx (v1.4.0) on MATLAB 2023a. My setup consists of an S32K3x4EVB-T172 connected via the onboard OpenSDA port. Attempt 1 (OpenSDA COM): I can flash the generated target model successfully, but PIL execution fails immediately with the following error: "The communication channel could not be opened" (see attached screen shot of the error message) Attempt 2 (External USB2Serial Convertor) I kept the OpenSDA port connected for flashing, but connected an external USB2Sireal  connector to J44(1 to TX and 2 to RX) for PIL communication and updated the COM port in the hardware settings. The model flashes successfully, but execution times out with this error: Error: The timeout of 10 seconds for receiving data from the rtiostream interface has been exceeded. There might be multiple reasons for this communications failure. You should: (a) Check that the target hardware configuration is correct, for example, check that the byte ordering is correct. (b) Confirm that the target application is running on the target hardware. (c) Consider the possibility of application run-time failures (e.g. divide by zero exceptions, incorrect custom code integration, etc.). Note (c): To identify possible reasons for the run-time failure, consider using SIL, which supports signal handlers and debugging. If you cannot find a solution, consider using the method setTimeoutRecvSecs of rtw.connectivity.RtIOStreamHostCommunicator to increase the timeout value.   Questions:   1. Does the S32K3x4EVB-T172 board require an external USB2Serial convertor for PIL or can it run PIL over the onboard OpenSDA port ?  2. If an external USB2Serial convertor required , what is the exact hardware UART configuration expected?  3. Am i missing any configuration ? Any guidance i highly appreciated!  Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @PruthviB, Before investigating further, could you clarify why you are using MBDT S32K3xx v1.4.0? The latest available release is v1.8.0, which includes several fixes and improvements. We recommend upgrading to v1.8.0 first and checking whether the issue still reproduces. Regarding your setup, an external USB-to-Serial converter is not required for PIL communication on the S32K3X4EVB-T172. The onboard OpenSDA interface already provides access to the target UART used for host-target communication, so the same USB connection can be used for both programming and PIL communication. Since OpenSDA has direct access to the UART pins, connecting an additional USB-to-Serial adapter is generally unnecessary and may even introduce configuration conflicts if multiple serial interfaces are active. Could you please try the example with: MBDT S32K3xx v1.8.0 Only the onboard OpenSDA USB connection The COM port exposed by OpenSDA selected in the hardware settings Best regards, Dragos Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @dragostoma Thank you for the guidance regarding OpenSDA onboard interface. Regarding the version, MBDT v1.4.0 was the recommended version for MBDT for BMS. Could you please provide guidance on running PIL simulations in v1.4.0 ?  Best Regards, Pruthvi Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @PruthviB, Indeed, you are correct. The BMS Toolbox requires S32K3 Toolbox version 1.4.0. Since the initial discussion did not mention the BMS Toolbox, I assumed the issue was related to the use of an outdated S32K3 Toolbox version. Regarding the PIL simulation in version 1.4.0, the workflow remains unchanged. The example model provided with the toolbox is configured to use the LPUART instance whose RX and TX signals are routed through the OpenSDA interface. If you intend to use a dedicated USB-to-Serial converter, you will need to configure a different LPUART instance and assign the corresponding RX and TX pins to which the converter will be connected. To summarize: Using the OpenSDA interface: the example model included with the toolbox should work without any additional modifications. The required LPUART instance and associated RX/TX pins are already configured. Using a dedicated USB-to-Serial converter: the converter must be connected to specific RX and TX pins on the target device. Consequently, those pins must be configured and mapped to an available LPUART instance, which requires corresponding updates to the project configuration. Please make sure that the correct COM Port is used, and the RX and TX pins from J44 are configured when using the USB2Serial converter. Let us know how it works, Dragos

i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM SUMMARY We run one quantized ONNX on i.MX95, once under CPUExecutionProvider and once under NeutronExecutionProvider. The two arms do not give the same answers: on 2,466 paired multiple-choice items, 25.7 % receive a different answer (43.6 % on MMLU). In free generation the same thing happens - on MMLU prompts, 13 of 19 generations produce a different answer letter. This is not a difference in wording. It is a difference in what the model answers. Meanwhile aggregate benchmark accuracy moves by only -1.8 points. We would like to understand what the Neutron runtime does numerically that produces this, and whether this magnitude is expected. SETUP Reproducible on your side: the model is from UG10166 Table 2 and the quantization is your own recipe, unmodified. - Board: i.MX95 19x19 EVK (IMX95LPD5EVK-19), LPDDR5 - BSP: LF6.18.2_1.0.0, device tree imx95-19x19-evk-neutron.dtb - Runtime: ONNX Runtime 1.22.0 from the BSP + NeutronExecutionProvider - Neutron Converter: 3.1.3 - Model: meta-llama/Llama-3.2-1B-Instruct - Quantization: NXP/eiq-olive rev aae820e, examples/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - Conversion: convert_ort_models_to_neutron.py, applied to the CPU arm's model.onnx - Environment: NEUTRON_CMA_512SLOTS=6 Both arms come from one quantized model. The NPU arm is that model passed through convert_ort_models_to_neutron.py. We record a SHA-256 of the source - graph and external weights - at conversion time and re-verify it before every measurement, so there is no second quantization run and no second export. WHAT WE OBSERVE 1. One item in four gets a different answer. 2,466 paired items from MMLU, ARC-Challenge and PIQA, 0-shot, scored by log-likelihood of the candidate continuations - one forward per candidate, no generation, no sampling. For each benchmark, the share of items whose ANSWER changed, then the share whose CORRECTNESS changed: - MMLU (4 choices): 43.6 % answer changed, 27.1 % correctness changed - ARC-Challenge (4 choices): 21.3 % answer changed, 13.3 % correctness changed - PIQA (2 choices): 9.4 % answer changed, 9.4 % correctness changed - Aggregate: 25.7 % answer changed, 17.3 % correctness changed The two figures differ because a third of the changes (208 of 634) move from one wrong answer to another wrong answer - a real behavioural change that leaves accuracy untouched. PIQA, being binary, has no such blind spot, and its two figures coincide exactly. 2. The same happens in free generation - the answer itself changes. 50 prompts, greedy decoding, 64 tokens. For the MMLU prompts the expected output starts with the answer letter, so the answer can be read directly from the generation (n = 19): - Different answer letter between the two arms: 13 of 19 - Correct on CPU: 7 of 19 - Correct on Neutron: 6 of 19 - Disagreements where both arms are wrong, with different wrong answers: 6 of 13 Two thirds of the answers change, and the score is essentially the same (7 versus 6). The sample is small - we report it as an illustration; the 2,466-item measurement above is the quantitative one. An example, verbatim. The prompt lists four options and asks for a letter, and the expected answer is 😧 CPU: " A\nExplanation: The expression 9(9m + 3t) is equivalent to 81m + 27t. The best answer is A." NPU: " C\nThe best answer is C." Both are wrong, they are wrong differently, and no benchmark score records it. 3. The divergence is present in the very first forward, not accumulated. In this letter format the first generated token IS the answer, and 60 % of generations already differ there - a token produced by the prefill pass alone, before any decoding step. Across all 50 prompts the divergence curve rises steeply then flattens: 84 % by token 4, 98 % by token 64. That is what propagation of an initial difference looks like under greedy decoding, not error accumulating through the KV cache. 4. Aggregate accuracy hides all of it. 50.28 % on CPU against 48.50 % on Neutron, a -1.78 point difference, and none of the three benchmarks is individually significant. Restricting to the 634 items where the arms disagree, CPU is correct 37.1 % of the time against Neutron's 30.1 % - 235 versus 191 among decided items, i.e. 55/45 where symmetric noise would give 50/50. WHAT WE RULED OUT - Silent CPU fallback: ORT profiling reports 80 of 80 MatMulNBits on NeutronExecutionProvider, 0 on CPU. No partial placement. - Two different models: same source file, SHA-256 of graph and external weights recorded at conversion and re-verified before scoring. - Sampling: greedy decoding throughout; no temperature, no top-k, no top-p. - Different inputs: both arms consume the same items file, in the same order, from the same fixed seed. - Scoring artefacts: the board only captures per-token log-probabilities; all decision logic runs offline on the host, identically for both arms. - Run-to-run noise on the NPU: replaying the same items in the same Neutron session yields bit-identical log-probabilities. The NPU arm is reproducible; the discrepancy is against CPU, not against itself. OUR QUESTION Is this expected behaviour for the INT4 path on Neutron-S - and if it is, how should we validate an LLM deployment on the NPU, given that aggregate benchmark accuracy clearly does not surface it? We are not assuming a defect. Some difference between a floating-point CPU kernel and an integer NPU path is normal, and we would like to know what magnitude you consider normal, and what criterion you use yourselves to accept an LLM port to Neutron. If a quarter of answers changing is within expectations, that is a useful thing for us to know and to design around.  Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM Thanks for your quick answer ! D.S Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM Hi @DamienSCHNEBELEN  IMX95 NPU can only run matmul, and LLM performance on NPU is actually only average. Therefore, the phenomenon you observed is within the predictable range, and we do not recommend running LLM models on an NPU. B.R

S32K3x4EVB-T172 PIL 通信错误/超时，MBDT S32K3xx 1.4.0 你好， 我尝试在 MATLAB 2023a 上运行 PIL S32CT 示例和 MBDT S32K3xx (v1.4.0)。我的配置包括通过板载 OpenSDA 端口连接的 S32K3x4EVB-T172。 尝试 1（OpenSDA COM）： 我可以成功刷写生成的目标模型，但是 PIL 执行立即失败，并出现以下错误： “无法打开通信通道”（请参见附件中的错误信息截图） 尝试 2（外置 USB 转串口转换器） 我保持 OpenSDA 端口连接以进行刷写，但将外部 USB2Sireal 连接器连接到 J44（1 到 TX，2 到 RX）以进行 PIL 通信，并在硬件设置中更新了 COM 端口。模型刷写成功，但执行超时并出现以下错误： 错误：从 rtiostream 接口接收数据的超时时间已超过 10 秒。通信失败可能由多种原因造成。 你应该： （a）检查目标硬件配置是否正确，例如，检查字节顺序是否正确。 （b）确认目标应用程序正在目标硬件上运行。 （c）考虑应用程序运行时故障的可能性（例如除以零异常、不正确的自定义代码集成等）。 注（c）：要确定运行时失败的可能原因，请考虑使用 SIL，它支持信号处理程序和调试。 如果找不到解决方案，请考虑使用 rtw.connectivity.RtIOStreamHostCommunicator 的 setTimeoutRecvSecs 方法来增加超时值。 问题： 1.S32K3x4EVB-T172开发板运行PIL时是否需要外接USB转串口转换器，还是可以通过板载OpenSDA端口运行PIL？ 2. 如果需要外部 USB 转串口转换器，所需的硬件 UART 配置具体是什么？ 3. 我是否遗漏了什么配置？ 非常感谢您的指导！ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 在进一步调查之前，能否请您说明一下您使用MBDT S32K3xx v1.4.0 的原因？最新版本为v1.8.0 ，其中包含多项修复和改进。我们建议您先升级到 v1.8.0 版本，然后检查问题是否仍然存在。 关于您的设置， S32K3X4EVB-T172上的PIL 通信不需要外部 USB 转串口转换器。板载OpenSDA 接口已经提供了对用于主机-目标通信的目标 UART 的访问，因此同一个 USB 连接可以用于编程和 PIL 通信。 由于 OpenSDA 可以直接访问 UART 引脚，因此通常不需要连接额外的 USB 转串口适配器，如果多个串口处于活动状态，甚至可能会引入配置冲突。 请您尝试一下以下示例： MBDT S32K3xx v1.8.0 仅板载OpenSDA USB 连接 在硬件设置中选择的 OpenSDA 公开的 COM 端口 此致， 德拉戈斯 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @dragostoma 感谢您对OpenSDA板载接口的指导。 关于版本，MBDT v1.4.0 是推荐用于电池管理系统的 MBDT 版本。请问能否提供在v1.4.0版本中运行PIL仿真的指导？ 顺祝商祺！ 普鲁特维 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 没错，你说得对。The 电池管理系统 Toolbox requires S32K3 Toolbox version 1.4.0. 由于最初的讨论没有提到电池管理系统 工具箱，我假设这个问题与使用过时的 S32K3 工具箱版本有关。 关于 1.4.0 版本中的PIL 模拟，工作流程保持不变。工具箱提供的示例模型配置为使用LPUART 实例，其 RX 和 TX 信号通过 OpenSDA 接口路由。如果您打算使用专用的USB 转串口转换器，则需要配置不同的 LPUART 实例，并将转换器连接的相应 RX 和 TX 引脚分配给该实例。 总结起来： 使用 OpenSDA 接口：工具箱中包含的示例模型无需任何额外修改即可工作。所需的 LPUART 实例和相关的 RX/TX 引脚已配置完毕。 使用专用 USB 转串口转换器：转换器必须连接到目标设备上的特定 RX 和 TX 引脚。因此，必须配置这些引脚并将其映射到可用的 LPUART 实例，这需要对项目配置进行相应的更新。 使用 USB2Serial 变流器时，请确保使用正确的 COM 端口，并配置 J44 的 RX 和 TX 引脚。 与我们联系， 德拉戈斯

[SPSDK][i.MX95] nxpele read-common-fuse fails Hi, I'm working on enabling secure boot on an IMX95 19x19 EVK board. I've successfully signed my images using the SPSDK. Now, before writing the fuses, i wanted to read them using `nxpele` but i'm getting the error below. ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 See debug log file: /home/user/.local/state/spsdk/3.11.0/log/debug.log for more info ``` and in the logs it says the following: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 DEBUG:spsdk:*************************************************** (206ms since start, spsdk_logger.py:212) DEBUG:spsdk:* SPSDK DEBUG LOGGING STARTED 2026-09-03 15:58:44 * (207ms since start, spsdk_logger.py:213) DEBUG:spsdk:* SPSDK version: 3.11.0 * (207ms since start, spsdk_logger.py:215) DEBUG:spsdk:* Python version: 3.14.4 * (207ms since start, spsdk_logger.py:216) DEBUG:spsdk:* OS version: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (208ms since start, spsdk_logger.py:217) DEBUG:spsdk:* Last command: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (208ms since start, spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (208ms since start, spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot WRITE -> invalid (210ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (210ms since start, uboot.py:271) DEBUG:spsdk.uboot.uboot:Checking if the serial console is open by sending invalid command: "invalid\r\nUnknown command 'invalid' - try 'help'\r\nu-boot=> " (224ms since start, uboot.py:209) DEBUG:spsdk.utils.database:Current database finger print hash: f0f0598d4e6ae6c755d693693f232e30537cfb3b (226ms since start, database.py:1967) DEBUG:spsdk.utils.database:Loaded database from cache: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (226ms since start, database.py:1976) DEBUG:spsdk.utils.misc:Loading text file from /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml (226ms since start, misc.py:312) INFO:spsdk.ele.ele_comm:ELE communicator is using 196608 B size buffer at 92800000 address in mimx9596, Revision: latest target. DEBUG:spsdk.ele.ele_comm:ELE msg 0x92800000 0x30000 0602971788000000 (245ms since start, ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot WRITE -> ele_message 0x92800000 0x30000 0602971788000000 (246ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (246ms since start, uboot.py:271) DEBUG:spsdk.ele.ele_comm:Raw ELE message output: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (256ms since start, ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped output: 060497e1d600000000000000 (256ms since start, ele_comm.py:460) DEBUG:spsdk.apps.utils.utils:SPSDK: Message SIZE in response is invalid: 0x4 (257ms since start, utils.py:182) Traceback (most recent call last): File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py", line 172, in wrapper retval = function(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 2189, in safe_main sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1631, in __call__ return self.main(*args, **kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1552, in main rv = self.invoke(ctx) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 2032, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1415, in invoke return ctx.invoke(self.callback, **ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 910, in invoke return callback(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py", line 46, in new_func return f(get_current_context().obj, *args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 575, in cmd_read_common_fuse ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 588, in ele_read_common_fuse ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py", line 519, in send_message msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 1235, in decode_response super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 346, in decode_response raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 ``` Note: i'm using `SPSDK 3.11.0` I've created an issue also on SPSDK's github page https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614  Any help is very much appreciated.  Thank you, BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails Hi joanxie I'm using linux BSP version LF6.18.20_2.0.0 (yocto wrynose) And here is the output of nxpele get-info $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails could you tell me what ele fw version do you use for this command? let me double check it Re: [SPSDK][i.MX95] nxpele read-common-fuse fails I reproduced this issue, and I checked internal data base, this is existed issue and will fixe on spsdk 3.12.0 

HSE FW 2.40.0および2.55.0におけるGCM IV長サポートに関する質問 こんにちは、 S32K358のHSEにおけるGCMの動作について質問があります。 HSEサービスAPIリファレンスマニュアルのAEADサービス説明において、HSE FW 2.40.0および2.55.0の両方でGCMについて以下の事項が明記されています。 GCM: 1 <= ivLength <= 2^32-1。推奨サイズは12バイト以上です。 しかし、HSE FW 2.40.0のマニュアルには、HSE FW 2.55.0のマニュアルには記載されていない以下の注記が追加されています。 GCM操作においては、IV値として正確に12バイトを使用することを推奨します。12バイトを超える任意のIVサイズに対して、GCM暗号化操作によって生成される認証タグが正しくない場合があります。GCM復号操作では、認証チェックが失敗することがあります。 この点に関して、以下の点を明確にしたいと思います。 1. IV長が12バイトでない場合、HSE FW 2.40.0でGCM操作を通常使用できますか? 2. 12バイト以外のIV長を使用した場合、HSE FW 2.40.0と2.55.0の間でGCM操作に挙動的な違いはありますか? 3. IV長が12バイト以外の場合、HSE FW 2.40.0と2.55.0の間でGCM動作の信頼性に違いはありますか？ 私たちのテストでは、IV長が12バイトでなくてもGCM暗号化と復号が成功し、認証結果も正確でした。 したがって、HSE FW 2.40.0で12バイト以外のIV長の使用が完全にサポートされているかどうか、またこの場合のHSE FW 2.55.0使用と機能的に違いがあるのかを確認したいと思います。 ご説明いただきありがとうございます。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 技術的には、ivLengthは異なる長さで設定可能ですが、しかし、その動作が信頼性を保証するわけではないため推奨されません。ご指摘の通り、ドキュメントにはGCM復号操作では、12バイト以外のIV長を使うと認証チェックが失敗する可能性があると記載されています。 異なる長さの点滴チューブを使用したテストに合格したとしても、手術が必ず成功するとは限りません。言い換えれば、特定のテストケースで成功した結果が、その構成が完全にサポートされている、あるいはすべてのシナリオで一貫して動作するという指標と解釈すべきではありません。 さらに、両方のファームウェアバージョンのリリースノートを確認すると、制限事項のリストに同じ推奨事項が記載されていることがわかります。それは、IV値を正確に12バイトにすることです。 この注記はHSE FW 2.55.0からHSEサービスAPIリファレンスマニュアルから削除されましたが、制限自体は変更されていません。 BR、VaneB

i.MX8M PlusおよびTIM-VX/VSINPU上のGC7000UL汎用演算推論パスはNPU専用であるように見える 理事会/BSP: i.MX8M Plus、aarch64 Galcore バージョン 6.4.11.p2.745085 VSINPUExecutionProviderを用いたONNXランタイム(libtim-vx.so に対して静的リンク) Vivante OpenCL ICDの存在と機能(Vivante.icd → libVivanteOpenCL.so) 目標: GC7000UL 3D GPUコア上でResNet50推論ベンチマーク(MLPerfロードゲンハーネス)を実行し、既存のNPU(VIP8000Nano)やCPUベンチマークの結果と比較します。 動作確認済みの項目： Vivante OpenCL ICDを経由したclGetPlatformIDs/clGetDeviceIDsは、1つのプラットフォーム上で2つの独立したデバイスをきれいに列挙します。 デバイス0：GC7000UL.6204.0000 デバイス1：VIP8000Nano-S+I.8002.0000 両者とも、CL_DEVICE_TYPE_ACCELERATORを報告し、エラーはなく、libOpenCL.so → libGAL.so と連携した最小限のCテストプログラムで確認されました。 ORT経由でGPUディスパッチを妨げている原因: ort.get_available_providers()は['VSINPUExecutionProvider', 'CPUExecutionProvider']のみを返します — OpenCLベースのEPはありません。 VSINPUExecutionProviderは静的にリンク libtim-vx.so(OVXLIB/vsi_nn_* API)です。libtim-vx.so と libGAL.so の両方のシンボル/文字列ダンプでは、DEVICE_INDEX/DEVICE_IDスタイルのenv varやconfig surfaceは表示されず、動作の切り替え(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_*など)のみが表示されます。 libGAL.so 生のHALレイヤーでgcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndexをエクスポートしますが、OVXLIB/TIM-VXからその呼び出しまでの配管は見当たりません。これは、VSINPUが使うグラフコンパイラがデバイスインデックスに関係なくNPUコアのみをターゲットにしている可能性を示唆しています。 具体的な質問： このBSP(galcore 6.4.11.p2)上のTIM-VX / OVXLIBは、グラフをコンパイルして一般的な計算対象としてGC7000ULにディスパッチするのをサポートしているのでしょうか?それともこのビルドではグラフコンパイラは設計上NPUのみ対応されているのでしょうか?また、その方法で実行可能かどうかはどうやって確認すればよいのでしょうか? もしTIM-VXの上流でGPUターゲットグラフコンパイルがサポートされているのに、このNXP搭載ビルドでは有効になっていない場合、それを公開するビルドフラグやSDKコンポーネントはありますか? TIM-VX/ORTを通るサポート済みの経路がない場合、NXPが推奨する汎用推論をGC7000UL上で直接実行する方法(例えばOpenCL/OpenVXレイヤー経由、その部分は機能が確認されているため)やサンプルアプリ、SDKコンポーネント、または参照実装などを基準に構築する方法はありますか? 現在学生で、この実装に取り組みながらGPUの上にORTを動かそうとしているのですが、GPUを使って推論できる方法、あるいは他に何か方法はありますか? どうもありがとうございます。 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @WaleedO さん。 NXPサポートまでご連絡いただきありがとうございます。 GPU上で推論を実行するにはGPUデリゲートを使うべきで、これを使うとサポートされた操作をCPUだけで動作するのではなくGPUで加速できます。 利用可能な実行バックエンド、設定の委任、サポートフレームワーク、例のアプリケーションをよりよく理解するために、 Machine Learning ユーザーガイド の確認をお勧めします。ガイドには、GPUデリゲートが正しく読み込まれているか、モデルが期待通りに動作しているかを確認するためのステップバイステップの例も含まれています。 セットアップや実行中に問題が発生した場合は、モデル、BSPバージョン、使用しているコマンドを共有していただければ、喜んでサポートいたします。 よろしくお願いします、 アレハンドロ・ガルシア Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @Chavira はじめまして。 ドキュメントを確認すると、GPUデリゲートとOpenCLパスは95/952 GPU(Arm Mali G310)内で i.MX 使われています。現在、『The IMX8MPLUS』に取り組んでいます。 IMX8M Plusは以下のスタックを持っています:VX delegate ==> TIM-VX ==> GPU/NPU(統一ドライバー)==> I.MX 8シリーズNPU、 GPU(GC7000,GC7000L、GC7000UL)。ドキュメントによると。 現在、私はONNXとORTを扱っています。実行時には、デフォルトでNPU上で実行されます。OpenCLを使って IMX8MPLUS GPUで作業する方法はありますか?あるいは、コンパイルをNPUかGPUに手動で設定できる手動オーバーライドや技術があれば教えてください。 ご返信いただき、誠にありがとうございます。 敬具、 IMX8MPLUS #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 はい、まだ可能な経路はありますが、VSINPU Execution プロバイダにGC7000ULを強制するのは避けたほうがいいです。 あなたの結果は、現在のNXP TIM-VX/OVXLIBのビルドが主にVIP8000 NPU向けに設計されていることを強く示唆しています。gcoHAL_SetDeviceIndex libGAL.so だけではTIM-VXがNNグラフをGPUにリダイレクトできるわけではありません。 まずは、ONNXランタイムの外で、小さなモデルでTIM-VX/OpenVXを直接テストします。 お使いのOVXLIBがGC7000UL/GPUのNNターゲットを公開しているか確認してください。 NXP TIM-VXのビルドとアップストリームのTIM-VXを比較してみてください。特にマルチデバイス/プラットフォームのサポートです。 もしTIM-VXがGC7000ULでコンパイルできない場合は、GPUベンチマークとしてVivante OpenCL/OpenVXスタックを直接使用してください。 MLPerfプロジェクトでは、GPUパスに必ずしもORTは必要ありません。別のGC7000ULバックエンドを作成し、CPU/NPU用の同じLoadGenハーネスに接続することができます。 ですので、次のように構成します。 MLPerf LoadGen → ResNet50 GPU バックエンド → OpenCL/OpenVX → GC7000UL それよりも： MLPerf→ORT→VSINPU→GPUを強制的に使います ベストリグラッド、 フェサジ

参考文档请求：在 S32DS 中将 AI 工具与 Cody Chat 集成 尊敬的NXP社区团队： 我目前正在使用 S32 Design Studio，并使用 IDE 中提供的 Cody Chat 功能。 我想知道是否可以将OpenAI ChatGPT 和 Anthropic Claude等外部 AI 模型集成到 S32 Design Studio 的 Cody Chat 部分中。 我的需求是在 S32DS 内部直接使用 AI 助手来执行以下操作： C/C++ 代码生成及说明 嵌入式 C 开发 调试编译器和链接器错误 CAN、SPI、I2C、UART 和 ADC 开发 S32K3/S32K344 开发 了解并参与当前的S32DS项目项目。 我发现 Sourcegraph Cody 的官方文档描述了对 OpenAI 和 Anthropic 模型的支持，包括模型配置和自带密钥 (BYOK) 选项。 请问您能否澄清一下： S32 Design Studio 中使用的 Cody 集成是否能够连接到 ChatGPT/OpenAI 和 Claude 等外部 AI 提供商？ 我们能否在 Cody Chat 部分为这些 AI 提供商配置我们自己的 API 密钥？ 是否有任何 NXP 官方文档、S32DS 文档、Cody 文档或示例项目说明如何在 S32DS 中配置或将外部 AI 模型与 Cody 集成？ 如果当前 S32DS 版本不直接支持此功能，是否有官方方法可以扩展 Cody/Eclipse 插件以支持外部 AI 提供商？ 与标准的 Sourcegraph Cody 实现相比，S32DS 实现的 Cody 是否存在任何限制？ 作为参考，我找到了以下关于支持的LLM和模型配置的Sourcegraph文档： 支持的LLM 科迪模型配置 Cody 模型配置示例 请问能否提供NXP的相关参考文档或推荐的S32DS实施流程？ 感谢您的支持。 此致， 阿拉文德·托加拉利 Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS 你好， 人工智能工具及其外部使用文档计划于9月26日发布。

Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Dear NXP Community Team, I am currently working with S32 Design Studio and using the Cody Chat feature available in the IDE. I would like to know whether it is possible to integrate external AI models such as OpenAI ChatGPT and Anthropic Claude into the Cody Chat section of S32 Design Studio. My requirement is to use an AI assistant directly inside S32DS for activities such as: C/C++ code generation and explanation Embedded C development Debugging compiler and linker errors CAN, SPI, I2C, UART and ADC development S32K3/S32K344 development Understanding and working with the current S32DS project context I found that the official Sourcegraph Cody documentation describes support for both OpenAI and Anthropic models, including model configuration and Bring Your Own Key (BYOK) options. Could you please clarify: Is the Cody integration used in S32 Design Studio capable of connecting to external AI providers such as ChatGPT/OpenAI and Claude? Can we configure our own API key for these AI providers in the Cody Chat section? Is there any official NXP documentation, S32DS documentation, Cody documentation, or example project explaining how to configure or integrate external AI models with Cody in S32DS? If this functionality is not directly supported in the current S32DS version, is there an official method to extend the Cody/Eclipse plugin to support external AI providers? Are there any restrictions in the S32DS implementation of Cody compared with the standard Sourcegraph Cody implementation? For reference, I found the following Sourcegraph documentation regarding supported LLMs and model configuration: Supported LLMs Cody Model Configuration Cody Model Configuration Examples Could you please provide the appropriate NXP reference documentation or recommended procedure for implementing this in S32DS? Thank you for your support. Best regards, Aravind Togaralli Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Hi,  the release of AI tools with documentation for external usage is planed on September 26. 

PFE EMAC0 ECUウェイクアップ後の無効なバッファアクセス こんにちは、 EMAC0を2500 Mbpsで設定し、必要なSERDESチャネル設定も行っています。ECUの稼働状態中は、イーサネット通信が正常に動作しています。 Eth通信にアクセスするアプリケーションをシャットダウンした後、ECUMからECUスリープリクエストをトリガーし、MCUモードをSOCスタンバイに設定し、HSE_CM7をメインコアとして選択します。 ウェイクアップ後、ECUは通常の動作に戻り、COM、SOAD、TCPIP、ETHIFのレイヤーは期待通りに動作します。EthのIFレイヤーでは、API呼び出し中の「Provide TX buffer」が「Provide TX buffer」が空いていないというエラーを返し、その後Ethフレームの送信が停止します 問題解決のために試された修正方法のリスト: 1. 「Eth_43_Pfe_Deinit」を使ってPFEドライバをシャットダウンし、「Eth_43_Pfe_Init」を呼んでPFEドライバを起動しようとしましたが、実行後にCPUがロックされてしまいました。 2. EthコントローラをEth_43_Pfe_SetControllerモードで下げてアクティブに戻そうとしたところ、バス障害が発生しました この問題の解決策を教えてください。 追伸> 使用コンフィギュレーター:EB tresos Eth PFE RTDバージョン:1.3.0 SDK:GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 1.SOCがスタンバイモードに入ると、パーティション2のPFEクロックが無効になります。ウェイクアップ後にパーティション2が再度有効になっているか確認してください。PFE開始前のPCSの状態PRTN2_STATを確認してみてください。PFE開始前のPCS状態。 2. SERDESが正常に機能しているかどうかを確認します。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z 1.PFEはMコアでのみ使用されています 2. 開発ボードを使っています:S32G-VNP-RDB3 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん お問い合わせいただきありがとうございます。 1. PFEはMコアでのみ使用されますか？Aコアを一緒に使ったことはありますか？ 2. お客様のボードを使っていますか、それとも私たちの開発ボードを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、@Joey_z。 ステータスレジスタのビットフィールドはスリー プ前Partition_2 1のままですが、スリープ中は 0 に更新され、MCUモードが通常に設定された後、ウェイクアップ後には再び 1 に更新されます。 Serdesは正常に動作しています。さらに、ET Phyコネクタ(RJ45)とコントローラー(NXPS32G399A)の間にSERDESが関与しないRGMIIモードでEMAC2を試しましたが、それでも問題は同じままでした。 Partition_2の起動後に再起動シーケンスが必要な場合は、お知らせください。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん 問題は、おそらくウェイクアップ後のPFE初期化に関するものと思われます。クロックと関連するPFE構成を確認し、理想的な状態に初期化されていることを確認してください。 1. PFEの初期化がブートローダーに入力され、起動後にアプリケーション内で正しく再初期化されているか確認してください。 2. スタンバイプロセスに従って該当する構成を確認する。RM 32.5.5「実行モードからスタンバイモードへ」を参照してください。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 スタンバイとウェイクアップシーケンスの操作について教えていただけますか? 1. コアとパーティションはどのように設定しますか？ 2.Do アプリケーションでブートローダーとAコアを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z さん。 以下に睡眠・覚醒の順序を示します。 1. API 「EcuM_SelectShutdownTarget()」 を使ってECUスリープモードをリクエストしています。これにより、ECUMの実装通りにMCUモードがスタンバイに設定されます。 2. ECUMがスリープモードに入ると、ウェイクアップイベントをポーリングし、CANトランシーバーがバスの活動を検出してEcuM_SetWakeupEvent() APIを使ってウェイクアップイベントを設定し、その後ECUは通常の動作を再開します。 ブートローダーについては、NXPのブートローダー(0x0にフラッシュされる)のフラッシュ位置と、Mコアアプリケーションが0x400000にフラッシュされます。Aコアはどこにも使用されていません。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 Avinash_7373 あなたの問題について何か進展はありましたか？もし継続的なサポートが必要な場合は、以下のリンクからコードをアップロードしていただければ問題をより詳しく分析できます。 https://support.nxp.com BR ジョーイ