如何编写NFC芯片 我正在尝试用iPhone 12 Pro Max对NFC 215芯片进行编程。我正在使用NXP标签写入器应用程序。在NXP标签写入器应用程序中，我点击“新建”、“网站”，然后输入描述信息以及URI类型和URI数据。然后我点击“保存并写入”，我收到一条通知，提示“NDEF 记录已成功保存到我的数据集中”。当我关闭应用程序并点击芯片时，没有任何反应。我还尝试用另一部手机，但仍然不行。大家有什么想法或建议吗？ nfc error.PNGNFC错误.PNG

USB init failed: -22 Hi , I have been trying to flash my wic.b2z image to an emmc using uuc tool through a usb port.While flashing an USB init failed: -22 error occured.I am using an imx8mp porcessor. Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot: 0 ## Checking Image at 43800000 ... Unknown image format! Run fastboot ... USB init failed: -22 u-boot=>     i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 Hello,  Please share the complete process and the boot config of your board to analyze what can cause the issue.  

USB 初始化失败：-22 您好， 我尝试使用 uuc 工具通过 USB 端口将 wic.b2z 镜像刷入 eMMC 存储。刷写过程中出现 USB 初始化失败：-22 错误。我使用的是 imx8mp 处理器。 运行 bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr} ; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr} ; else booti ${loadaddr} ${initrd_addr} ${fdt_addr} ; fi; else echo "运行 fastboot ..."; fastboot 0; fi; 按任意键停止自动启动：0 正在检查 43800000 处的图像... 未知图像格式！ 运行 fastboot... USB 初始化失败：-22 u-boot=>     i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 你好， 请提供完整的操作流程和主板的启动配置，以便我们分析问题原因。

[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で修正される予定です。

MCUXpressoセキュアプロビジョニングツールは、USB経由でターゲットボードに接続できません。 こんにちは、NXPさん。 質問があります： 開発ボード：MIMXRT1170-EVKB。MCUXpresso Secure Provisioning Toolを使用して接続できません（画像参照）。 hayden178_0-1788428456159.pnghayden178_0-1788428456159.pnghayden178_0-1788428456159.pnghayden178_0-1788428456159.png コンピュータのデバイスマネージャーには、以下の情報が表示されます。 hayden178_1-1788428566738.pnghayden178_1-1788428566738.pnghayden178_1-1788428566738.pnghayden178_1-1788428566738.png 開発ボードのDIPスイッチを図に示します。 hayden178_2-1788428637373.pnghayden178_2-1788428637373.pnghayden178_2-1788428637373.pnghayden178_2-1788428637373.png プログラムをダウンロードしてIDEを使ってデバッグしましたが、問題はありませんでした。この問題のトラブルシューティング方法を教えてください。よろしくお願いします。 Re: MCUXpresso Secure Provisioning Tool无法通过USB连接目标板 こんにちは、@hayden178 さん。 ご質問ありがとうございます！ ご提供いただいたDIPスイッチの設定と電源オプションを確認しましたが、問題はありませんでした。USB OTG1も問題なく選択できました。 したがって、何らかの異常により、フラッシュローダーがUSBポート経由でSRAMにデータを迅速にロードできない状態になっている可能性があります。まずはUARTインターフェースをお試しください。UARTインターフェースが正常に動作する場合は、USBインターフェースに切り替えてください。この時点で、フラッシュローダーは正常に動作し、USBポートも正しく機能するはずです。 UARTポートにも問題がある場合は、特定の出力を確認する必要があります。詳細なコマンドは、作業ディレクトリにあるgen_scripts/init_flashloader_win.batに記載されています。テストを再実行する前に、以前のログを削除し、新しいログを確認して、どのステップで失敗したかを確認してください。 よろしくお願いします、 ギャビン Re: MCUXpresso Secure Provisioning Tool无法通过USB连接目标板 こんにちは、 @Gavin_Jia さん。 ご支援ありがとうございます！ MIMXRT1170-EVKBとの接続にUARTを使用したところ、問題は解決しました。 新たな問題が発生しました。問題の原因を特定するのを手伝っていただけませんか？ MCUXpresso Secure Provisioning Tool に組み込まれているサンプルでは、mcuboot_opensource&ota_mcuboot の実行に失敗し、画像に示すように、常にリセットが発生します。 hayden178_0-1789004746339.pnghayden178_0-1789004746339.png プロジェクトの構成は以下のとおりです。 hayden178_1-1789004822575.pnghayden178_1-1789004822575.png hayden178_2-1789004848902.pnghayden178_2-1789004848902.png hayden178_4-1789005368832.pnghayden178_4-1789005368832.png hayden178_3-1789005332451.pnghayden178_3-1789005332451.png IDEを使用して両方のプロジェクトを正常に実行できましたが、生成されたバイナリファイルをSPSPを使用してボードにダウンロードすると、同じリセット問題が発生します。 hayden178_5-1789005846515.pnghayden178_5-1789005846515.png

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チームにチケットを提出してアクセス権を得ることもできます。 よろしくお願いいたします。 ショーン

T1042D4RDB 从 SD 卡启动时出现网络问题 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我从 SD 卡启动时，T1042D4RDB 的以太网连接出现问题。 以下是我启动时的输出： SERDES 参考：0x86 网络：正在初始化 Fman MMC 读取：设备 # 0，块 # 2080，计数 128 ... Fman1：7fdf8f88 处的数据不是固件 未找到以太网接口。 按任意键停止自动启动：0 => md 0x7df8f88 07df8f88: deadbeef deadbeef deadbeef deadbeef ................ 07df8f98：死牛肉 死牛肉 死牛肉 死牛肉 ................ 07df8fa8：死牛肉 死牛肉 死牛肉 死牛肉 ................ 07df8fb8：死牛肉 死牛肉 死牛肉 死牛肉 ................ 07df8fc8：死牛肉 死牛肉 死牛肉 死牛肉 ................ 07df8fd8：死牛肉 死牛肉 死牛肉 死牛肉 ................ 07df8fe8：死牛肉 死牛肉 死牛肉 死牛肉 ................ 从 u-boot 代码中可以看出，u-boot 认为它可以从 SD 卡读取数据，但是“0xdeadbeef”表示该地址的 RAM 中没有任何写入操作。 奇怪的是，在 u-boot drivers/net/fm/fm.c 中，blk_dread() 的返回值并没有被检查： printf("\nMMC 读取：设备 # %u，块 # %u，计数 %u ...\n", dev，block，cnt）； mmc_init(mmc); (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt, 地址); } [已删除] /* 如果存在，请上传 Fman 微代码 */ rc = fman_upload_firmware(index, &reg->fm_imem, addr); 如果 (rc) 返回 rc； env_set_addr("fman_ucode", addr); Re: T1042D4RDB networking problems when booting from SD card KrogerFeedback 是一项顾客调查，旨在让购物者有机会分享他们在 Kroger 的购物体验。顾客在完成最近的购物后，可能会被邀请就商店清洁度、产品供应情况、结账速度、员工服务以及整体满意度提供反馈。该调查旨在帮助克罗格公司了解顾客喜欢什么以及哪些方面需要改进。 参与者应妥善保管收据，因为收据上可能包含访问调查所需的信息。诚实、认真地回答这些问题有助于克罗格公司改进其产品和服务。根据当前促销活动的不同，符合条件的参与者还有机会获得奖励或参加抽奖活动。 Kroger反馈 Re: T1042D4RDB networking problems when booting from SD card KrogerFeedback 是一项顾客调查，旨在让购物者有机会分享他们在 Kroger 的购物体验。顾客在完成最近一次购物后，可能会被邀请就商店清洁度、产品供应情况、结账速度等问题提供反馈意见。 Kroger反馈 Re: T1042D4RDB networking problems when booting from SD card Wingstop.com/survey – Mywingstopsurvey.com/usa 这是 Wingstop 提供的一项在线调查，允许顾客对他们上次的用餐体验提供宝贵的反馈。 Wingstop 公司希望您能提供反馈意见，帮助他们了解可以做出哪些改变，以确保顾客获得更好的体验。 Re: T1042D4RDB networking problems when booting from SD card 专为洛克希德·马丁公司员工设计的登录网关称为LMPeople External 。员工可以通过该门户网站访问一系列服务，包括工资单、福利和个人数据。 Re: T1042D4RDB networking problems when booting from SD card 欢迎参加温蒂汉堡顾客满意度调查。我们重视您的坦诚反馈，感谢您抽出时间完成我们的调查。 https://haioly-tsiiv-splieurk.yolasite.com/ Re: T1042D4RDB networking problems when booting from SD card <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 澄清：这不是为 Raspberry Pi 或我的 PC 准备的，而是为 T1042D4RDB 准备的。 Re: T1042D4RDB networking problems when booting from SD card <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我没有使用 SDK v2.0。它相当老旧，而且与 Ubuntu 18 不兼容，我尝试过（据我所知是 Python 2 与 3 之间的兼容性问题）。 我使用的是 Poky 2.6.1 版本。 问题： 1. 为什么 Poky 2.6.1 会发布 3 个不同的版本？ 2. 为什么发货时要附带一个无法正常工作的最新版本？ 干杯， Re: T1042D4RDB networking problems when booting from SD card <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> FMan 微代码版本必须与 SDK 版本保持一致。 我原本以为使用的是 SDK v2.0。 Re: T1042D4RDB networking problems when booting from SD card <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我明白了！谢谢！我之前没意识到 u-boot 镜像中没有包含 fMan 固件。 我试过用 108.5.9，但是不行。T1042D4RDB 出厂预装 106.4.18 版本，并且运行正常。 我觉得很奇怪，既然108.15.9这个地址不能用，为什么还要把它列出来，反而推荐107.4.2呢？ 你是如何得出107.4.2是正确的编程版本的结论的？ $ ls tmp/deploy/images/t1042d4rdb/fsl_*.bin tmp/deploy/images/t1042d4rdb/fsl_fman_ucode_t1040_r1.1_106_4_18.bin tmp/deploy/images/t1042d4rdb/fsl_fman_ucode_t1040_r1.1_107_4_2.bin tmp/deploy/images/t1042d4rdb/fsl_fman_ucode_t1040_r1.1_108_5_9.bin Re: T1042D4RDB networking problems when booting from SD card <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 需要将 FMan 微代码（附件）从 0x820 块写入 SD 卡。 In U-Boot: =>tftp 100000 fsl_fman_ucode_t1040_r1.1_107_4_2.bin =>mmc write 100000 820 37  In Linux: # dd if=fsl_fman_ucode_t1040_r1.1_107_4_2.bin of=/dev/sdb  seek=2080 bs=512 Re: T1042D4RDB networking problems when booting from SD card White Castle 调查为顾客提供了一种简单的方式，让他们可以分享对最近用餐体验的反馈。通过完成调查，您可以对食品质量、服务、清洁度、员工行为和整体满意度发表评论。您的诚实反馈有助于 White Castle 了解顾客喜欢什么以及哪些方面需要改进。如需参与，请准备好您最近的收据，并按照公司提供的调查说明进行操作。 根据您的实际访问情况，认真回答每个问题。根据当前的促销活动，完成调查问卷还有机会获得奖励或特别优惠。花几分钟时间回复，有助于改善您未来在 White Castle 的用餐体验。 WhiteCastle 的顾客

连续两次测量中接收灵敏度相差 10dB 我发现我们一款使用 QN9083 BLE SoC 的产品出现了异常行为。当我测量设备接收器灵敏度时，我发现连续两次测量之间有高达 10dB 的差异。我正在使用 CMW100 的广播模式进行测量，该设备放置在屏蔽的射频盒中。在不打开盒子和/或改变设备位置的情况下，连续进行 RxS 测量，设备的响应差异高达 10dB（即 -91dBm 和 -81dBm），这是意料之外的，以前从未发生过。这种行为是随机的。我正在寻找硬件和软件方面可能的原因。 Re: Rx sensitivity differs by 10dB between consecutive measurements 你好， 连续两次灵敏度测量结果之间出现高达 10 dB 的变化，这通常是我们意想不到的。 能否告知您当前使用的软件/SDK 版本？ 另外，您能否澄清一下： 这种情况是发生在单个设备上还是多个产品上？ 您是否在不同的单元中观察到过同样的情况？ 使用相同的测量设置，能否在 NXP 开发板上重现该问题？ 这些信息将有助于确定问题是硬件、软件还是测试环境特有的。 顺祝商祺！ 里卡多 Re: Rx sensitivity differs by 10dB between consecutive measurements 您好，感谢您的回复。我的回答如下： 能否告知您当前使用的软件/SDK 版本？ 5.0 版本基于156414（控制器子系统）和 156821（主机子系统） 这种情况是发生在单个设备上还是多个产品上？ 同一款产品。使用其他产品从未遇到过问题。 您是否在不同的单元中观察到过同样的情况？ 是的，但并非始终如此。 使用相同的测量设置，能否在 NXP 开发板上重现该问题？ 我需要一块搭载 QN9083 芯片的开发板，以及一个能将芯片设置为广播模式的固件。 谢谢！       Re: Rx sensitivity differs by 10dB between consecutive measurements 关于BLE版本的其他信息： SDK 2.2.3 BLE 1.5.6，支持 BLE Core 5.0。 Re: Rx sensitivity differs by 10dB between consecutive measurements @Ricardo_Zamora 我使用 QN9080-DK 进行了测量。虽然我没有看到 10dB 的差异，但仍然存在 5dB 的波动（见下方数据）。可能是什么原因造成的？ furbani_0-1784214895282.pngfurbani_0-1784214895282.png Re: Rx sensitivity differs by 10dB between consecutive measurements 嗨@Ricardo_Zamora，您有时间查看我发布的数据/答案吗？ 谢谢。 Re: Rx sensitivity differs by 10dB between consecutive measurements 我测量了 W236 FRDM 板，看看辐射 RSSI 的变化有多大。变化幅度可达 4dB。 RomanPBudek_0-1789049903611.png RomanPBudek_1-1789049923585.png

Android オートモーティブ 16.0.0_1.3.0向けのセキュリティアップデート済みプリビルドで、カーネルやU-Bootビルドを壊さずに提供されました こんにちは、 NXPの Android オートモーティブ 16.0.0_1.3.0をカーネル6.12 と、NXPが文書化したプリビルドのリビジョンを使用しています。 プラットフォーム/Prebuilts/Clang/Host/Linux-x86 66acdd82ee62e4AAAA4248F03191C59DFED9DB193 カーネル/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 プラットフォーム/prebuilts/rust 5156e7f81ae254c79ee736e44C960e75AD685C67 プラットフォーム/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 これらは本リリースのNXP Android Automotiveユーザーガイドに記載された改訂版です。 ビルドはこれらのリビジョンで動作しますが、当社のコンテナ脆弱性スキャンでは、 提供されたAndroidプリビルト内でいくつかのHIGHかつCRITICALな発見が報告されています。 例えば、Clangのプリビルド版にはGoの標準ライブラリが組み込まれています。clang-r536225/bin/clang のスキャン結果は以下のとおりです。 合計: 22 高: 21 重大: 1 Go stdlib バージョン: v1.23.2 例: CVE-2025-68121 crypto/tls - 証明書の検証が正しく行われていない 同様の検出パターンは、clang++ および clang-tidy、そして組み込みの Go バージョンが v1.23.4 である新しい clang-r547379 バイナリでも見られます。 NXPが固定しているkernel/prebuilts/build-toolsにも、同じGo-stdlib検出パターンを持つ、影響を受けるsoong_zipバイナリが含まれています。 Rustのプリビルド版には、出荷されるCargoロックファイルに含まれる発見事項も含まれています。例えば、以下のとおりです。 thin-vec 0.2.13 CVE-2026-6654 は 0.2.16 で修正されました。 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 は 0.15.1 で修正されました。 これらのプリビルドはNXPカーネル/U-Bootビルド環境の一部であり、 Android Automotive 16.0.0_1.3.0 / カーネル6.12との互換性を維持したいため、ドキュメント化されたリビジョンを任意の新しいAOSPコミットで置き換えるつもりはありません。 これらのプリビルド製品に対応する、NXPが推奨する、または互換性が確認されている新しいコミットIDはありますか？ 特に、以下の項目に関する最新の改訂版を求めています。 platform/prebuilts/clang/host/linux-x86 カーネル/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP社、あるいはコミュニティの誰かが、これらの改訂版を既に更新し、以下の内容が引き続き正常に動作することを確認しましたか？ 理想的には、更新されたプリビルト車と完全なAndroid Automotiveビルドがまだ動作するかどうかの確認も望んでいます。 セキュリティ調査結果を恒久的に抑制するよりも、影響を受けたプリビルトを更新したいと考えています。 参考までに、失敗した脆弱性スキャンログを添付しました。これには、影響を受けるClang、カーネルビルドツール、およびRustのプリビルド版に関する完全な調査結果が含まれており、検出された組み込みバージョンと利用可能な修正バージョンも含まれています。 ありがとうございます。 Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu こんにちは、 ご指摘いただいた件について調査中です。進捗状況は随時ご連絡いたします。 よろしくお願いします。

FRDM-IMX95のサスペンド時の消費電力を可能な限り低く抑える FRDM-IMX95ボードでサスペンドモード時の消費電力を可能な限り低く抑える方法についてのガイダンスをお探しですか？ベアメタルm7コードを使用し、a55sをオフにすることで、約2.2Wまで消費電力を下げることができました。これは、エキスパンダー/PHY/PD_NETC の電源を完全に切った後の状態です。FRDM-IMX95はどのくらい低く設定できるのでしょうか? FRDMトレーニング Re: Lowest possible SUSPEND power consumption of FRDM-IMX95 最新の調査結果を自分の投稿に追記します…EXT_5V0とEXT_3V3_PWR_ENをオフにしてみましたが、それ以上の改善は見られませんでした。次にDDRセルフリフレッシュをテストしたところ、約193mA/1.1Wまで下げることができました。できればもっと値下げしたいのですが…。 Re: Lowest possible SUSPEND power consumption of FRDM-IMX95 当社の i.MX 95消費電力測定を参照し、参照できる低消費電力のユースケースが多数あります。 i.MX 95の消費電力測定

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エンジニアへの直接アクセスも可能です。   よろしくお願いします。

Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot builds Hi, we are using NXP Android Automotive 16.0.0_1.3.0 with kernel 6.12 and the prebuilt revisions documented by NXP: platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 These are the revisions listed in the NXP Android Automotive User's Guide for this release. The build works with these revisions, but our container vulnerability scan reports several HIGH and CRITICAL findings inside the supplied Android prebuilts. For example, the Clang prebuilts contain embedded Go standard libraries. For clang-r536225/bin/clang, the scan reports: Total: 22 HIGH: 21 CRITICAL: 1 Go stdlib version: v1.23.2 Example: CVE-2025-68121 crypto/tls - incorrect certificate validation The same finding pattern also appears in clang++ and clang-tidy, and in the newer clang-r547379 binaries where the embedded Go version is v1.23.4. The NXP-pinned kernel/prebuilts/build-tools also contains affected soong_zip binaries with the same Go-stdlib finding pattern. The Rust prebuilts also contain findings in shipped Cargo lock files, for example: thin-vec 0.2.13 CVE-2026-6654 fixed in 0.2.16 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 fixed in 0.15.1 We do not want to replace the documented revisions with arbitrary newer AOSP commits, because these prebuilts are part of the NXP kernel/U-Boot build environment and we want to preserve compatibility with Android Automotive 16.0.0_1.3.0 / kernel 6.12. Are there newer NXP-recommended or known-compatible commit IDs for these prebuilts? In particular, we are looking for updated revisions for: platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   Has NXP, or anyone in the community, already updated these revisions and verified that the following still work? Ideally, we would also like confirmation that a complete Android Automotive build still works with the updated prebuilts. We would prefer to update the affected prebuilts instead of permanently suppressing the security findings. I have attached the failed vulnerability scan log for reference. It contains the complete findings for the affected Clang, kernel build-tools and Rust prebuilts, including detected embedded versions and available fixed versions. Thanks. Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu Hello, I'm reviewing your issue, I'll keep you updated.  Regards.

s32设计工作室许可证已过期 您好。 我的S32设计工作室许可证即将到期。 能否续签许可证？ 许可证代码为 085B-C474-AA78-FC99。 谢谢！ Re: s32 design studio license expired 你好， 您的S32DS许可证已延期。

S32DS activation code 软件版本为S32DS_ARM_Win32_v2018.R1_b180326，能否提供 activation code PEG GUI

CodeWarrior 5.1 调试器。“单步执行时禁用可屏蔽中断服务例程” 9S12XEQ512 上的 I 位永久置位 环境： IDE：CodeWarrior 5.1（HC(S)12X 编译器） 目标：MC9S12XEQ512 总线时钟：49.777 MHz BDM接口：使用USB Multilink Universal可复现；使用Cyclone Pro未观察到。 主机操作系统：在Windows 10和Windows 11上均观察到此问题 内存模型：在大容量模型中可复现；在分块模型中不可复现（或复现能力大大降低） 使用的设置： "HC12MultilinkCyclonePro" → "设置..." → "调试选项" → "单步运行时禁用可屏蔽的 ISR" — 已启用。 描述： 在调试器中执行多次单步操作（单步或单步跳过）后，可屏蔽中断（CCR 中的 I 位）将被永久禁用。即使在继续执行（运行/运行）后，中断也不会恢复——它们会一直处于屏蔽状态，直到在 CCR 寄存器视图中手动清除 I 位。在 Windows 10 和 Windows 11 主机上使用 USB 多链路通用 BDM 接口的大内存模型中，这种行为始终可以重现。在其他项目设置完全相同的情况下，Cyclone Pro 界面未出现此问题，Banked 内存模型中也未出现此问题（或几乎未出现）。 目前使用的临时解决方案： 手动清除 CCR 寄存器视图中卡住的 I 位。 要求： 这是 USB Multilink Universal 固件/驱动程序与 CodeWarrior 5.1 在 S12X 内核上使用的单步仿真功能结合使用时已知的问题吗？对于此设备/接口组合上的中断驱动型大型模型项目，是否存在固定的 Multilink Universal 固件版本，或者推荐的替代工作流程？ 谢谢

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

USB初期化失敗: -22 こんにちは、 USBポート経由でuucツールを使用してwic.b2zイメージをeMMCに書き込もうとしています。書き込み中にUSB初期化失敗：-22エラーが発生しました。imx8mpプロセッサを使用しています。 bootcmd_mfg を実行します: mfgtool_args を実行します。iminfo が${initrd_addr}の場合、test が${tee}の場合、bootm が${tee_addr} ${initrd_addr} ${fdt_addr}の場合、booti が${loadaddr} ${initrd_addr} ${fdt_addr}の場合、fi を実行します。それ以外の場合は、echo "fastboot を実行します..." を実行します。fastboot 0 を実行します。fi を実行します。 自動起動を停止するには、任意のキーを押してください: 0 ## 43800000 番地の画像を確認中... 不明な画像フォーマット！ fastbootを実行... USB初期化失敗: -22 u-boot=>     i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 こんにちは、 問題の原因を分析するために、ボードの起動設定と全過程を共有してください。