Wi-Fi command response timeout I'm working on a project using i.MXRT1062 crossover MCU and Murata 2EL M.2 wireless card based on NXP IW612 chipset. The project uses MCUXpresso SDK and FreeRTOS. The current SDK version is 25.12. During the firmware operation, sometimes I get the following output in the debug console: `[wifi] Warn: Command response timed out. command 0x0, len 1514, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 66, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 190, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 60, seqno 0x16` I don't know what do these lines mean, probably some problem with wireless module. After that a task list is printed, panic is triggered and the firmware stalls. I think the problem happens after ~30 minutes during more or less heavy traffic through the wireless connection. A corresponding place in the SDK files is located at `middleware/wifi_nxp/wifidriver/wifi.c` in `wifi_wait_for_cmdresp` function. This is further confirmed that there's a pause of roughly 20 seconds between the previous debug console print and this line. How can I troubleshoot the problem? I can work with you to provide further debugging information or test SDK fixes. Re: Wi-Fi command response timeout Hi, I understand you are using a custom application, but which SDK example did you use as a starting point? If you can reproduce the same behavior using an unmodified SDK example, it would significantly help isolate the issue. Seems the driver was waiting for a command response, and did not receive it before the timeout expired. Please enable the following debug macros in wifi_config.h: CONFIG_WIFI_CMD_RESP_DEBUG CONFIG_WIFI_EVENTS_DEBUG CONFIG_WIFI_IO_INFO_DUMP CONFIG_WIFI_EXTRA_DEBUG Once the macros are enabled; rebuild the example and test it again. Please share the output. I would be a good idea to test it with the latest SDK and see if the problems still occurs. Re: Wi-Fi command response timeout This is the debug output when the firmware hangs up. Please let me know if you need any previous log lines. 23/06/2026 12:27:48.808 [RX] - [wifi] Warn: Command response timed out. command 0x0, len 890, seqno 0x16 SDIO multiple port group registers value: **** Dump @ 20218FC0 Len: 196 **** 00 00 00 00 ff 00 00 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 7f 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 03 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 00 00 00 00 00 87 0c 00 00 00 00 00 00 00 00 00 00 1c c2 06 c0 f4 de 09 c0 00 1e ff ff 00 0a 36 01 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 10 cc f0 ff ff ff ff ff 00 00 ff ff ff ff ff ff f4 74 04 c0 80 98 04 c0 00 00 00 00 ******** End Dump ******* Name State Priority Stack Num ================================================== main_task X 3 581 6 print_dhcp R 0 683 17 IDLE R 0 92 2 tcp/ip B 3 400 1 Tmr Svc B 4 196 3 supplicant_main_tas B 2 1456 14 nfc_cfg B 0 715 7 dhcpd_task B 3 406 15 HTTP server B 1 888 18 wifi_scan_task B 1 255 11 wlcmgr_task B 3 244 13 wifi_drv_task B 3 228 10 lwip_rx B 3 431 8 wifi_core_task B 3 276 12 [wifi] Start to process hanging [wifi] initiating wifi-deauth [FW Download] S 23/06/2026 12:27:48.824 [RX] - tart to download firmware from 0x602319fc: 1618224 23/06/2026 12:27:54.807 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_reinit failed. status code -1 ASSERT: wlan_process_hang: 550 Assert failed: Panic! ASSERT ERROR " 0 ": file "C:/tmp/mcuxsdk/mcuxsdk/middleware/wifi_nxp/wifidriver/incl/mlan_api.h" Line "65" function name "panic" Re: Wi-Fi command response timeout Hi @DanielRuvalcaba , is there any update on this issue? This also happens on SDK 26.03, do you need more debug info from me?

NFCアンテナにおける固体平面の機能 こんにちは、 私たちはNFCアンテナをコントローラボードに統合しています。 当社のアンテナは、約90mm×40mmのサイズで、3ターン巻かれています。 既に両側を地上の飛行機に囲まれている。グランドプレーンとアンテナ間の距離は約5mmです。 多層基板の製造業者から、内層のアンテナ領域を銅で埋めるように指示されています。 NXPのNFCデモボードで同様の実装例を見つけたので、うまくいくはずだと考え、同様の方法で実装したいと思っています。 なぜこれらの評価ボードでこのように実装されたのでしょうか? 銅の面積は、どの程度範囲に影響しますか？ 銅箔面積はEMCに影響を与えますか？良くなったのか、悪くなったのか？ 銅部分とアンテナ間の最小距離はどれくらいにすべきですか？ 広い面積を1つ使うのと、小さな面積を複数使うのとでは、どちらが良いでしょうか？ どうもありがとうございました。よろしくお願いいたします。 マイケル Re: Function of solid plane in the NFC antenna こんにちは、マイケルさん。 この内部金属配線を使用する主な理由は、主にデモンストレーション目的で、例えばPOS端末内におけるNFCアンテナ周辺の現実的な環境をシミュレートするためです。 また、この金属充填は、アンテナが内部の「金属負荷」によって既に同調されているため、他の物体による同調ずれの影響を軽減するのに役立つ可能性がある。 しかし製品なら、内部に充填のない従来のNFCアンテナを選びます。 BR トマス Re: Function of solid plane in the NFC antenna こんにちは、トーマスさん。 情報提供ありがとうございました。 その後、アンテナ表面の上下両面に銅製のタイル（8mm×8mm、2mm間隔、各2層）を接着して試験を実施しました。 次にアンテナを測定し、再調整しました。 機能面(航続距離、電流測定、EMI)で違いは検出できません。 あなたは従来型の設計を推奨すると書いていましたね。 その理由はあるのでしょうか?もしあれば、それは何でしょうか? 8×8mmで間隔が2mmの領域よりも、間隔の広い小さな領域をいくつか設けた方が良いかもしれません。 どうもありがとうございます、 マイケル Re: Function of solid plane in the NFC antenna こんにちは、 @michael_d_1983 さん、 前述の通り、よりリアルな環境を表現するために銅製のタイルを使用しています。 これは、受信範囲が若干狭くなる可能性があることを意味します。これは、自由空間にある理想的なアンテナよりも、より現実的な状況を反映しています。これは、金属タイルがエネルギーの一部を吸収するためです。 しかし、チューニングが同じままであれば、送信電流とEMIに変化はありません。 したがって、そのような設計を「実際の」製品に実装する必要はありません。 BR トマス Re: Function of solid plane in the NFC antenna こんにちは、トーマスさん。 ご意見ありがとうございます！ 実際には、銅の領域は一切含めたくないのです。基板メーカーは私たちにそうしてほしいと望んでいます。 （その理由は、プリント基板上の銅の分布が不均一だと、プリプレグに含まれる樹脂が不足している銅を補うのに十分ではないため、プリント基板製造における積層工程で気泡や剥離などの問題が発生するからである。） 私たちがまだ考慮していない、これに対する根本的な反対理由があるかどうかを明確にしたいだけです。 （リーダー機能について）テスト済みです。すべて通常通りに機能しているようです。 よろしくお願いします、 マイケル

QorIQ T1024:Linuxイーサネットドライバーがトラフィックが多い状態で止まる こんにちは、 私はQorIQ T1024プロセッサを搭載したカスタムボードを持っており、Linuxカーネルバージョン5.4.3(ソース https://github.com/nxp-qoriq/linux)を搭載しています。現在、カーネルバージョン6.6.52（ブランチlf-6.6.y）への移行を試みています。新しいカーネルは正常に起動し、イーサネット接続(100Mb、全てのデュプレックス、自動無効)以外はすべて正常に動作します。SSHやSFTP（大容量ファイルの転送）を使用した通常の通信は正常に動作します。しかし、トラフィックが大量に発生すると、再起動するまで接続が停止してしまいます。なお、これは送信方向でのみ発生します。PCからターゲットへの方向でiperfテストを実行する場合、高トラフィック時でもRX方向は正常に動作します。5.4.3カーネルではこの問題は発生しませんでした。ターゲット->方向にiperfテストを制限ビットレート1Mb/sで実行すると、eth接続は持ちこたえますが、フルビットレートになるとそのイーサネット接続が即座に動作しなくなり、PCにpingも送信できなくなります。インターフェースは依然としてUP(ipリンクコマンド)として表示されます。インターフェースの統計(ethtool -S )を取得しようとすると、ethtoolがフリーズします。カーネルドライバーが固まって応答しないことがわかりました。インターフェースをオフにしようとすると、カーネルメッセージが出力されます。添付の内容を参照してくださいip_link_driver_busy.png トラフィックが多い場合、処理が停止すると、レジスタ FMQM_PnS のビット PBSY_DF が設定され、クリアされません。ドキュメントによると、Qmanからの返答が届かなかったことを示しています。トラフィック量が多い場合、送信方向のリソースの割り当て/解放に何らかの問題が発生し、ロック状態が続くようです。ドライバーはハードウェアやロック、システムリソースを待つ間に詰まっているようです。復旧するには再起動するしかない。インターフェースを上下に設定しても効果がありません。 Fmanマイクロコードをfsl_fman_ucode_t1024_r1.0_108_4_9.binにアップグレードしましたが、効果はありませんでした。 QorIQ T1024は6.6.yでもまだサポートされていますか？カーネル？T1024と互換性のない変更点について、何かご存知ですか？ 6.6.yでもFSL SDK DPAAやFSL SDK FMANドライバーは維持されていますか?カーネル？バージョン5.4.3と6.6.52の間で、T1024の機能に支障をきたす可能性のある変更点はありますか？ 私が使用しているカーネルソース： 旧バージョン: https://github.com/nxp-qoriq/linux/tree/134788b16485dd9fa81988681d2365ee38633fa2 新規: https://github.com/nxp-qoriq/linux/tree/e0f9e2afd4cff3f02d71891244b4aa5899dfc786 私のカーネル6.6.52の設定の一部を以下に示します。 # # Frame Manager support # CONFIG_FSL_SDK_FMAN=y # CONFIG_FSL_SDK_FMAN_TEST is not set # # FMAN Processor support # # CONFIG_FMAN_P3040_P4080_P5020 is not set # CONFIG_FMAN_P1023 is not set # CONFIG_FMAN_V3H is not set CONFIG_FMAN_V3L=y # end of FMAN Processor support # CONFIG_FSL_SDK_FMAN_RTC_API is not set # CONFIG_FMAN_MIB_CNT_OVF_IRQ_EN is not set CONFIG_FSL_FM_MAX_FRAME_SIZE=1522 CONFIG_FSL_FM_RX_EXTRA_HEADROOM=64 # CONFIG_FMAN_PFC is not set # end of Frame Manager support CONFIG_FSL_SDK_DPAA_ETH=y # CONFIG_FSL_DPAA_HOOKS is not set CONFIG_FSL_DPAA_OFFLINE_PORTS=y CONFIG_FSL_DPAA_ADVANCED_DRIVERS=y # CONFIG_FSL_DPAA_ETH_JUMBO_FRAME is not set # CONFIG_FSL_DPAA_TS is not set # CONFIG_FSL_DPAA_1588 is not set CONFIG_FSL_DPAA_ETH_MAX_BUF_COUNT=1024 CONFIG_FSL_DPAA_ETH_REFILL_THRESHOLD=512 CONFIG_FSL_DPAA_CS_THRESHOLD_1G=0x06000000 CONFIG_FSL_DPAA_CS_THRESHOLD_10G=0x10000000 CONFIG_FSL_DPAA_INGRESS_CS_THRESHOLD=0x10000000 CONFIG_FSL_DPAA_ETH_DEBUGFS=y CONFIG_FSL_DPAA_ETH_DEBUG=y # CONFIG_FSL_DPAA_DBG_LOOP is not set どんなご支援でも感謝いたします。 ありがとう、 ジリ QorIQ T1デバイス Re: QorIQ T1024: Linux Ethernet driver stucks on high traffic こんにちは、 QorIQ Power Architecture Tシリーズソフトウェアのサポート状況に基づき、T1024は新しいソフトウェアで公式にサポートされているとは見なすべきではありません lf-6.6.y カーネルブランチ。 NXPのT1024/Tシリーズ向け公式SDKサポートは、旧QorIQ SDKラインで終了しました。ドキュメントのガイダンスによると、SDK 2.0-1703以降はT1024のSDKリリースがなく、SDK 2.0-1703はカーネル4.1.35を使用していました。NXPのガイダンスでは、新しいLinux BSPにはまだT1024関連ファイルが含まれている可能性があるが、公式にはTシリーズをサポートするリリースはされていません。別のNXPサポート声明によると、Tシリーズ製品のSDK 2.0-1703以降の公式リリースはなく、その製品ラインナップのSDKsアップグレード計画も継続していません。 つまり、T1024、DPAA、FMAN、QMan、またはBManのコードが存在することです lf-6.6.y これは、NXPがそのカーネルブランチにおけるT1024の動作を検証したと解釈すべきではありません。パブリック nxp-qoriq/linux リポジトリは一般的なQorIQ Linuxツリーですが、分岐の内容だけでは6.6.xのT1024サポートや検証を確立できません これはPHYや自己陰負の問題ではありません。証拠はTX DPAA/QManが検証されていないT1024カーネルベースライン上でハングしていることを示しており、実務的な方法は動作するサポート/検証済みベースラインに留まるか、カスタムメンテナンスとして6.6ポートをデバッグすることです。 よろしくお願いします。  

Neutron 変換された YOLOv8n モデルが i.MX95 で適切な出力を生成しない やあ、 Ultralytics から完全に量子化された int8 YOLOv8n オブジェクト検出モデルをエクスポートしました。最新の eIQ Toolkit バージョン 1.17 の Neutron コンバーターを使用して NPU で実行できるように変換し、i.MX95 ハードウェアで実行しようとしました。 NPU デリゲートを使用して、変換されたモデルと変換されていないモデルの両方を試しましたが、変換されたモデルに存在する Neutron Graph のみが NPU で実行されるようです。 両方のモデルからの生の出力を比較すると、変換されたモデルは 95% を超えるスコアで複数の誤検知を示しています。変換されたモデルと変換されていないモデルの両方に同じスクリプトを使用していますが、変換されたモデルでのみ問題が発生します。複数のアプローチで検証しましたが、毎回同じ結果になりました。 両方のモデルを Netron アプリで調べたところ、変換されたモデルに大きなアーキテクチャ上の変更があることがわかりました。 ここで私が聞きたいのは、 1.YOLOv8 や YOLOv11 などの最新のオブジェクト検出アーキテクチャは、eIQ Toolkit バージョン 1.17 を搭載した Neutron コンバータでサポートされていますか?もしそうなら、どのような手順を踏んでいるのか教えてください。 2. i.MX95 で NPU を使用して YOLOv8 と YOLOv11 をテストしましたか?はい、そうであれば、検証とポストプロセッシング手順用のモデルも送信していただけますか。 3.i.MX95 の Neutron NPU で Neutron Graph とは別の操作を実行したい場合、どのようなプロセスになりますか? 4. 上記のモデルを i.MX95 の GPU で実行する場合のプロセスはどのようなものですか? 機械学習ユーザーガイドも確認しましたが、関連する詳細は見つかりませんでした。これをデバッグするために私の側から詳細を知りたい場合は、遠慮なく質問してください。 ありがとう、 ヴァツサル Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 こんにちは、 Neutron に変換された YOLOv8n モデルからの誤検出で発生している問題は、既知の課題です。i.MX95 NPU 上の YOLOv8 モデルの現在のサポートはまだ最適化中であり、変換中のアーキテクチャの変更がパフォーマンスに影響する可能性があります。 具体的なご質問に関して： 1. eIQ Toolkit 1.17 の YOLOv8 アーキテクチャ サポートはまだ改善中です。推奨される変換ワークフローは次のとおりです。 - モデルをエクスポートする際に適切な int8 量子化を保証する - Neutronコンバータによる変換には最新のeIQ Toolkit (v1.17)を使用してください - コマンド: `./neutron-converter --input [your-model].tflite--target imx95 --use-python-prototype` 2. YOLOv8 はサポートされていますが、まだ完全に最適化されていない可能性があります。YOLOv5 は、現在の NPU 実装との互換性が優れていることが示されています。NXP チームは、YOLOv8/YOLOv11 サポートの改善に積極的に取り組んでいます。 3. NPU で Neutron Graph を超える操作を実行するには、eIQ または netron ツールを使用してモデルを分析し、どの演算子が NPU で実行できるように正常に変換されているかを特定する必要があります (neutronop コンテンツとして表示されます)。変換されない演算子は CPU 上で実行されます。 4. i.MX95 での GPU 実行では、NPU デリゲートの代わりに TensorFlow Lite GPU デリゲートを使用します。これには、GPU デリゲートを使用するように推論コードを変更する必要があります。 変換されたモデルを netron で調べることで、モデル操作の分散を確認できます。つまり、「neutronop」コンテンツを持つすべての演算子は NPU で実行され、その他の演算子は CPU に残ります。 よろしくお願いします。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 前回のチャットでYOLOv5がNeutronコンバータで良好な結果をもたらしていると主張していたように、カスタムデータセットを使用してYOLOv5sで再度トレーニングを実行し、推論を試みました。YOLOv5 でもこの問題は依然として存在します。参考までに結果も添付します。変換済みおよび非変換済みの int8 tflite YOLOv5s モデルを試しました。 さて、YOLOv5 が良い結果をもたらしていると主張するのであれば、検証済みのモデルを私たちと共有してみませんか。エクスポート、量子化から変換までのすべての手順と、ポストプロセッシングで実行している手順も共有してください。これにより、お客様のモデルを検証し、お客様が実行した手順を当社側で再現できるようになります。 共有できる場合は、i.MX95 のベンチマークとプロファイリング データも共有してください。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 こんにちは@Bio_TICFSL ！ NXPチームが--use-python-prototype フラグの使用を推奨しているようですが、私のNeutronコンバーターでは認識されません。Windowsでもサポートされているのでしょうか、それともLinux eIQリリースのみ対応しているのでしょうか？ Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 それは私にとっても疑問です。Linux eIQ を試してみましたが、うまく動作しませんでした。SO、私はそれをスキップし、ターゲット引数のみを渡してモデルを変換しようとしました。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 こんにちは、 @Bio_TICFSL 、 長い時間が経っているので、まだあなたの方からの返事を待っています。私たちはここで行き詰まっており、また緊急性も抱えています。できるだけ早くご返信いただきますようお願いいたします。 よろしくお願いいたします。 ヴァツサル [i.MX95 NPU] YOLOv5n/v8n/v11n Neutron-converted Models Run but Return No Detections (Zero Output) 問題の説明 私はNeutronコンバーターを使ってi.MX95 NPU上のYOLO物体検出モデルを評価しています。 INT8量子化されたTFLiteモデルはCortex-A55 CPU上で正常に動作しオブジェクトを検出しますが、コンパイルされたneutron.tflite版は、推論をクラッシュせずに実行しても、NPUにオフロードしても検出ゼロ(空/出力なし)ができません。 環境およびハードウェアのセットアップ   ハードウェア： i.MX95 19x19 LPDDR5 EVK（A1リビジョン） OS/カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXPツールチェーン: MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 テストされたモデル: YOLOv5nu、YOLOv8n、YOLOv11n(ウルトラリティクス) ワークフローの手順と使用されるコマンド 1. 量子化（Ultralyticsエクスポート） モデルはINT8のフル整数量子化で320x320解像度でエクスポートされました。 yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状態： CPU上で完全に動作します。yolovXn_full_integer_quant.tflite は、A55 コア上でオブジェクトを正しく検出します。 2. Neutron 編纂 TFLiteモデルは、Neutronコンバータを用いてi.MX95 NPU向けにMCU_SDK_25.09.00+Linux_6.12.34_2.1.0でコンパイルされました: ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状態： NPU上のオブジェクトを検出できませんでした。コンパイルされたモデルは構文や実行エラーを投げることなく推論を読み込み実行しますが、出力テンソルはまったく同じテスト画像に対して検出をゼロ返します。 観察された症状と疑われる根本原因   オペレーターの代替手段: コンバーターは特定のYOLOレイヤー(カスタムアンカー、SiLU/Swinのアクティベーション、Non-Max Suppressionなど)でCPUにフォールバックしましたか? 量子化のスケーリング/非対称性: Ultralytics経由でエクスポートされるYOLOモデルは、しばしば非対称量子化を用いたり、特定の出力テンソルスケーリングを用いており、Neutron NPUドライバーが誤解することがあります。 出力テンソルのフォーマット：推論は実行されるため、入力パイプラインは問題ないと思われますが、出力バウンディングボックス/スコアが空白であるか、完全にゴミ値になっています。 NXPのエキスパートへの質問   Ultralytics YOLOアーキテクチャ特有のNeutron変換器には既知の制限や必須の最適化フラグはありますか? TFLiteモデルをNeutronコンバーターに渡す前に、NMS(Non-Max Suppression)レイヤーを取り除くべきでしょうか? i.MX95 Neutron SDKは、出力層を正しく解析するために対称量子化(per_channel=TrueまたはFalse)を必要としますか? i.MX95 NPU向けのガイダンス、リファレンススクリプト、またはYOLOの導入に関する作業手順書などがあれば、大変ありがたいです。        

Could I use any GPIO pin as interrupt input signal which worked at edge detection mode? Hi， Because 6 dedicated IRQ(0~5) pins are not enough for me, I need other GPIO pin work as interrupt input signal. So, I have below two questions: 1. Could any GPIO be used as interrupt signal input, which worked at edge detection mode?  2. If above 1 is yes, what difference between dedicated IRQ and GPIO?  Maybe is response priority? Thanks in advance! Best regards! Jason

S32K144 FLASH allocates custom fields to store the data that the program wants to write. Hello to NXP's technical staff I encountered a problem during the development of the S32K144 chip. I want to put some variables into my custom ROM fields, but I'm not sure how to do it in the program. I defined the storage fields in S32K144_64_flash.ld And CALC_RAM is defined in SECTIONS. #define CALC_RAM_ATTRIBUTE__attribute__ ((section(".CALC_RAM"))) CALC_RAM_ATTRIBUTE const uint8_t my_flash_array[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_brray[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_crray[] = {0x01, 0x02, 0x03, 0x04}; The code above has placed my array into a custom field in CALC_RAM. My question is that this method is rather cumbersome. Since the macro CALC_RAM_ATTRIBUTE needs to be added before every newly defined array, is there a more convenient way to batch-store a piece of data into my custom field CALC_RAM? Looking forward to your reply Thank you so much! Re: S32K144 FLASH分配自定义字段 将程序中想要写入的数据放入自定义字段 Hi @Ni_, You generally have three options: OPTION 1. Keep the attributes as you do it. OPTION 2. Put everything into a dedicated source file, for example: /* cal_data.c */ #include const uint8_t table1[] = { 0x01, 0x02, 0x03, 0x04 }; const uint8_t table2[] = { 0x10, 0x20, 0x30, 0x40 }; const uint8_t table3[] = { 0xAA, 0xBB, 0xCC, 0xDD }; Then in the linker file: MEMORY { int_flash_interrupts : ORIGIN = 0x00000000, LENGTH = 0x00000400 int_flash_config : ORIGIN = 0x00000400, LENGTH = 0x00000010 int_flash : ORIGIN = 0x00000410, LENGTH = 0x0007BBF0 calib_flash : ORIGIN = 0x0007C000, LENGTH = 0x00004000 int_sram_results : ORIGIN = 0x1FFF8000, LENGTH = 0x00000100 int_sram : ORIGIN = 0x1FFF8100, LENGTH = 0x0000DF00 int_sram_stack_c0 : ORIGIN = 0x20006000, LENGTH = 0x00001000 ram_rsvd2 : ORIGIN = 0x20007000, LENGTH = 0 } .flash_config : { KEEP(*(.flash_config)) } > int_flash_config .calib_flash : { . = ALIGN(4); __calib_flash_start = .; KEEP(*cal_data.o(.rodata*)) . = ALIGN(4); __calib_flash_end = .; } > calib_flash .flash : { . = ALIGN(4); *(.startup) . = ALIGN(4); *(.systeminit) . = ALIGN(4); *(.text.startup) . = ALIGN(4); In the .map file: OPTION 3. Use a section pragma/macros. Some compiler support it, not GCC though. Regards, Daniel Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.      

S32K388電源 こんにちは、S32K388。 私はそのS32K388を自分のアプリケーションの一つに使っています。V11はV15のラストマイルレギュレーターNMOSから供給されることを想定しています。しかし、この1.5Vは外部のDC/DCコンバーターから供給したいと考えています。それは実現可能でしょうか？ よろしくお願いいたします。 ジュールズ Re: S32K388 power supplies こんにちは、 @JulesW さん、 S32K388 Power Architectureに基づき、V11はハードウェア設計ガイドラインに記載されている通り、V15レールからの外部NMOSラストマイルレギュレータを使用して生成しなければなりません。 ただし、1.5V V15レール自体が外部のDC/DCコンバーターから供給できるかどうかが質問であれば、それは可能です。これはS32K388 EVBでも採用されているアプローチで、ジャンパーオプションの一つとして、1.5V電源レールをPMICによって外部で生成するオプションがあります。 よろしくお願いいたします。 パベル

MPC574xP BCTRL 您好： 我的客户正在使用MPC5741P进行汽车电子调速应用。 目前，最终 OEM 厂商询问了他们有关 BCTRL 引脚特性（例如电压区域）的问题。 您能帮忙核实一下吗？谢谢。 下图是波形，它是三角波，OEM 要求在 MCU 侧的基极控制输出引脚上添加去耦电容。 Re: MPC574xP BCTRL 数据手册推荐的晶体管型号如下所示： 此外，还需要进行适当的旁路/解耦。主要关注VDD_LV_COR：

MPC574xP BCTRL こんにちは： 私のお客様はMPC5741Pを車載ESCのアプリケーションに使っています。 現在、エンドOEMからBCTRLピンの特性（電圧領域など）について問い合わせを受けている。 確認と確認を手伝ってもらえますか?ありがとう。 下は波形で、三角形で、OEMからMCU側からベースコントロール出力ピンのCap.デカップルを追加してほしいと依頼されました。 Re: MPC574xP BCTRL データシートでは異なるトランジスタを推奨しており、以下の通りです。 また、適切にバイパス／分離する必要がある。VDD_LV_CORに特に注意してください。

QorIQ T1024: Linux Ethernet driver stucks on high traffic Hello, I have a custom board with QorIQ T1024 processor running Linux Kernel version 5.4.3 (source https://github.com/nxp-qoriq/linux). I am now trying to migrate to the kernel version 6.6.52 (branch lf-6.6.y). The new kernel boots fine and all work as expected except Ethernet connection (100Mb, duplex full, autoneg off). Normal traffic using SSH or SFTP (transfer of large files) works. However, when I generate high traffic the connection stops working until reboot. Note that, this happens only in TX direction. RX direction works fine also on high traffic when running iperf test in direction PC -> target. I did not experience this issue on 5.4.3 kernel. When I run iperf test in direction target -> PC with limited bitrate 1Mb/s, the eth connection survives but full bitrate causes that functional Ethernet connection immediately stops working and stucks so I can't send data anymore nor ping the PC. The interface still appears as UP (ip link command). When I attempt to get interface statistics (ethtool -S ), ethtool hangs. I've learnt that the kernel driver is stuck and does not respond. When I attempt to turn off the interface, kernel messages are outputted - see attached ip_link_driver_busy.png On high traffic, when it stucks, bit PBSY_DF is set in register FMQM_PnS and does not get cleared. Documentation says that it means response from Qman did not arrive. It appears like on high traffic, there is some problem with allocation/deallocation of resources in TX direction and it remains in locked state. The driver seems to be stucked while waiting for HW, a lock or a system resource. The only way to recover is reboot. Setting the interface down and up does not help. I have upgraded Fman microcode to fsl_fman_ucode_t1024_r1.0_108_4_9.bin without any effect. Is QorIQ T1024 still supported in 6.6.y kernels? Are you aware of any changes incompatible with T1024? Are the FSL SDK DPAA and FSL SDK FMAN drivers still maintained in 6.6.y kernels? Are there any changes between version 5.4.3 and 6.6.52 that might break the functionality on T1024? Kernel sources I am using: Old: https://github.com/nxp-qoriq/linux/tree/134788b16485dd9fa81988681d2365ee38633fa2 New: https://github.com/nxp-qoriq/linux/tree/e0f9e2afd4cff3f02d71891244b4aa5899dfc786 Snippet of my kernel 6.6.52 config: # # Frame Manager support # CONFIG_FSL_SDK_FMAN=y # CONFIG_FSL_SDK_FMAN_TEST is not set # # FMAN Processor support # # CONFIG_FMAN_P3040_P4080_P5020 is not set # CONFIG_FMAN_P1023 is not set # CONFIG_FMAN_V3H is not set CONFIG_FMAN_V3L=y # end of FMAN Processor support # CONFIG_FSL_SDK_FMAN_RTC_API is not set # CONFIG_FMAN_MIB_CNT_OVF_IRQ_EN is not set CONFIG_FSL_FM_MAX_FRAME_SIZE=1522 CONFIG_FSL_FM_RX_EXTRA_HEADROOM=64 # CONFIG_FMAN_PFC is not set # end of Frame Manager support CONFIG_FSL_SDK_DPAA_ETH=y # CONFIG_FSL_DPAA_HOOKS is not set CONFIG_FSL_DPAA_OFFLINE_PORTS=y CONFIG_FSL_DPAA_ADVANCED_DRIVERS=y # CONFIG_FSL_DPAA_ETH_JUMBO_FRAME is not set # CONFIG_FSL_DPAA_TS is not set # CONFIG_FSL_DPAA_1588 is not set CONFIG_FSL_DPAA_ETH_MAX_BUF_COUNT=1024 CONFIG_FSL_DPAA_ETH_REFILL_THRESHOLD=512 CONFIG_FSL_DPAA_CS_THRESHOLD_1G=0x06000000 CONFIG_FSL_DPAA_CS_THRESHOLD_10G=0x10000000 CONFIG_FSL_DPAA_INGRESS_CS_THRESHOLD=0x10000000 CONFIG_FSL_DPAA_ETH_DEBUGFS=y CONFIG_FSL_DPAA_ETH_DEBUG=y # CONFIG_FSL_DPAA_DBG_LOOP is not set Appreciate any help. Thank you, Jiri QorIQ T1 Devices Re: QorIQ T1024: Linux Ethernet driver stucks on high traffic Hello, Based on the support status of the QorIQ Power Architecture T-series software, T1024 should not be considered officially supported on the newer lf-6.6.y kernel branch . NXP’s official SDK support for T1024/T-series ended with the older QorIQ SDK line. The documented guidance says there is no SDK release for T1024 after SDK 2.0-1703 , and SDK 2.0-1703 used kernel 4.1.35 . NXP guidance also states that newer Linux BSPs may still contain T1024-related files, but they are not released to officially support T-series . Another NXP support statement says there is no official release after SDK 2.0-1703 for T-series products and no continuing SDK upgrade plan for that product line . So the presence of T1024, DPAA, FMAN, QMan, or BMan code in lf-6.6.y should not be interpreted as NXP validation of T1024 operation on that kernel branch. The public nxp-qoriq/linux repository is a general QorIQ Linux tree, but the branch contents alone do not establish T1024 support or validation for 6.6.x This is not a PHY/autoneg issue; the evidence points to a TX DPAA/QMan hang on an unvalidated T1024 kernel baseline, so the practical path is either stay on the working supported/validated baseline or debug the 6.6 port as custom maintenance. Regards  

Function of solid plane in the NFC antenna Hello, We have integrated our NFC antenna onto a controller board. Our antenna measures approximately 90 mm x 40 mm and has 3 turns. It is already surrounded by ground planes on two sides. The distance between the ground planes and the antenna is approximately 5 mm. Our PCB manufacturer (of a multi-layer PCB) wants us to fill the antenna area of the inner layers with copper. Since I found NFC demo boards from NXP where this is implemented in a similar way, I think it should work and would like to implement it similarly. Are there any reasons why it was implemented this way on these evaluation boards? To what extent does the copper area affect the range? Does the copper area affect EMC? Is it better or worse? What should be the minimum distance between the copper area and the antenna? Is it better to use a single large area or several small areas? Thank you very much, and best regards, Michael Re: Function of solid plane in the NFC antenna Hello Michael,  The main reason why we use this inner metallization is mainly for a demonstration purpose to simulate a realistic environment around the NFC antenna e.g. in the POS terminal.  Also this metal filling may help to reduce the detuning effect by a different object because the antenna is already tuned with the "metal loading" inside.   However for the real product, I would go for a conventional NFC antenna without any filling inside. BR Tomas  Re: Function of solid plane in the NFC antenna Hi Tomas, Thank you very much for the information. We have since conducted tests by gluing copper tiles (8 mm x 8 mm, spaced 2 mm apart, 2 layers each) to the antenna surface on both the top and bottom. We then measured the antenna and rematched it. We can’t detect any differences in terms of functionality (range, current measurement, and EMI). You wrote that you would recommend a conventional design. Are there reasons for this, and if so, what are they? Maybe several smaller areas with more spacing between them would be better than the 8x8 mm with 2 mm spacing? Thank you very much, Michael Re: Function of solid plane in the NFC antenna Hello @michael_d_1983 , As mentioned, we use the copper tiles to demonstrates a a bit more realistic environment. This means that you may observe a slightly lower reading range, which is more reflecting the reality than an ideal antenna in free space. This because of some energy is absorbed the the metal tiles.  But there is no change in the TX current and EMI, if the tuning stays the same.  Therefore there is no need to implement such design into the "real" product.  BR Tomas  Re: Function of solid plane in the NFC antenna Hi Tomas, Thanks for your feedback! We actually don’t want to include the copper areas at all. The PCB manufacturer wants us to do that. (The reason is that if the copper distribution on the PCB is uneven, problems arise during the lamination process in PCB production—such as air pockets and delamination—because the resin in the prepregs isn’t sufficient to compensate for the missing copper.) We just want to clarify whether there’s any fundamental reason against this that we haven’t considered yet. We’ve tested it (reader functionality). Everything seems to be working as usual. Best regards, Michael

How to build the libcamera for iMX95 FRDM I have currently cloned and able to build libcamera in my HOST PC which runs on ubuntu 20.04. The README provided doesnt provide any information regarding the tool chain needed to be used. How to overcome this ? Is there a source provided for yocto build for the IMX95 FRDM so with that we can able to populate SDK and build accordingly. Re: How to build the libcamera for iMX95 FRDM Option 1 (Recommended): Build libcamera inside Yocto If your goal is to modify or rebuild libcamera for FRDM-i.MX95: Download the i.MX BSP release corresponding to your board/kernel version. Set up the Yocto environment. Build libcamera as a Yocto package: bitbake libcamera or include it in your image: IMAGE_INSTALL:append = " libcamera" Then rebuild: bitbake imx-image-full ` This ensures: Correct aarch64 compiler Correct kernel headers NXP Neo pipeline support Matching IPA binaries Matching GStreamer libcamerasrc plugin This is the safest route for i.MX95. Option 2: Cross-build libcamera outside Yocto If you already cloned libcamera on Ubuntu 20.04 and want to cross-build it manually: You should not use the host gcc. Instead generate the SDK from Yocto: bitbake imx-image-full -c populate_sdk The i.MX Linux User's Guide explicitly references SDK generation and Yocto-based workflows. After the SDK is generated: tmp/deploy/sdk/*.sh Install it: ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh Source the environment: source /opt/fsl-imx-xwayland/ /environment-setup-aarch64-poky-linux Then build libcamera using meson: Shell meson setup build \ --cross-file= ninja -C build The exact cross-file depends on the SDK release and BSP version. Is there Yocto source available for i.MX95? Yes. Based on the internal Linux User Guide, i.MX95 support is provided through the standard NXP Yocto BSP and meta-imx infrastructure. The guide also references: bitbake imx-image-full and points users to the meta-imx README and Yocto documentation. [UG10163_i....-09_review | PDF] For FRDM-i.MX95 specifically, the board ships with an Embedded Linux Yocto solution according to the board collateral

S32K144 FLASHは、プログラムが書き込みたいデータを保存するためにカスタムフィールドを割り当てます。 NXPの技術スタッフの皆様、こんにちは。 S32K144チップの開発中に問題が発生しました。 カスタムROMフィールドにいくつかの変数を設定したいのですが、プログラム内でどのように設定すればよいのか分かりません。 S32K144_64_flash.ldでストレージフィールドを定義しました。 CALC_RAMはSECTIONSで定義されています。 #define CALC_RAM_ATTRIBUTE__attribute__ ((section(".CALC_RAM"))) CALC_RAM_ATTRIBUTE const uint8_t my_flash_array[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_brray[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_crray[] = {0x01, 0x02, 0x03, 0x04}; 上記のコードは、私の配列をCALC_RAMのカスタムフィールドに配置しました。 私の疑問は、この方法がかなり面倒だということです。マクロCALC_RAM_ATTRIBUTEを新しく定義する配列ごとに追加する必要があるため、カスタムフィールドCALC_RAMにデータを一括保存するもっと便利な方法はありますか？ お返事をお待ちしております。 どうもありがとうございます！ Re: S32K144 FLASH分配自定义字段 将程序中想要写入的数据放入自定义字段 こんにちは、 @Ni_ さん。 一般的に、選択肢は3つあります。 選択肢1。 作業を進める際は、属性を維持してください。 選択肢2。 すべてを専用のソースファイルに記述してください。例えば、次のようになります。 /* cal_data.c */ #include const uint8_t table1[] = { 0x01, 0x02, 0x03, 0x04 }; const uint8_t table2[] = { 0x10, 0x20, 0x30, 0x40 }; const uint8_t table3[] = { 0xAA, 0xBB, 0xCC, 0xDD }; 次にリンカーファイルで： MEMORY { int_flash_interrupts : ORIGIN = 0x00000000, LENGTH = 0x00000400 int_flash_config : ORIGIN = 0x00000400, LENGTH = 0x00000010 int_flash : ORIGIN = 0x00000410, LENGTH = 0x0007BBF0 calib_flash : ORIGIN = 0x0007C000, LENGTH = 0x00004000 int_sram_results : ORIGIN = 0x1FFF8000, LENGTH = 0x00000100 int_sram : ORIGIN = 0x1FFF8100, LENGTH = 0x0000DF00 int_sram_stack_c0 : ORIGIN = 0x20006000, LENGTH = 0x00001000 ram_rsvd2 : ORIGIN = 0x20007000, LENGTH = 0 } .flash_config : { KEEP(*(.flash_config)) } > int_flash_config .calib_flash : { . = ALIGN(4); __calib_flash_start = .; KEEP(*cal_data.o(.rodata*)) . = ALIGN(4); __calib_flash_end = .; } > calib_flash .flash : { . = ALIGN(4); *(.startup) . = ALIGN(4); *(.systeminit) . = ALIGN(4); *(.text.startup) . = ALIGN(4); .mapファイル内ファイル： 選択肢3。 セクション pragma/macros を使用します。 一部のコンパイラはサポートしていますが、GCCはサポートしていません。 よろしくお願いいたします。 ダニエル Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.      

QorIQ T1024：Linux 以太网驱动程序在高流量下卡住 你好， 我有一块定制的电路板，搭载 QorIQ T1024 处理器，运行 Linux 内核版本 5.4.3（来源：https://github.com/nxp-qoriq/linux ）。我现在正尝试迁移到内核版本 6.6.52（分支 lf-6.6.y）。新内核启动正常，一切运行正常，但以太网连接（100Mb，全双工，自动协商关闭）除外。使用 SSH 或 SFTP 进行正常流量传输（传输大文件）正常。但是，当网络流量过大时，连接就会停止工作，直到重启电脑才能恢复。请注意，这种情况仅在 TX 方向上发生。即使在流量较高的情况下，运行 iperf 测试时，从 PC 到目标的 RX 方向也能正常工作。我在 5.4.3 内核上没有遇到这个问题。当我以 1Mb/s 的限速运行 iperf 测试，方向为目标 -> PC 时，以太网连接可以保持，但全速运行时，该以太网连接会立即停止工作并卡住，因此我无法再发送数据，也无法 ping 通 PC。接口仍然显示为 UP（ip link 命令）。当我尝试获取接口统计信息（ethtool -S ）时，ethtool 卡住了。我发现内核驱动程序卡住了，没有响应。当我尝试关闭接口时，内核会输出消息——请参见附件 ip_link_driver_busy.png 在高流量情况下，当系统卡住时，寄存器 FMQM_PnS 中的位 PBSY_DF 会被设置，并且不会被清除。文档显示，这意味着 Qman 没有响应。似乎在高流量情况下，TX 方向的资源分配/释放出现了一些问题，导致服务器处于锁定状态。驱动程序似乎在等待硬件、锁或系统资源时卡住了。唯一的恢复方法是重启。放下和抬起接口都无济于事。 我已将Fman微码升级到fsl_fman_ucode_t1024_r1.0_108_4_9.bin，但没有任何效果。 QorIQ T1024 在 6.6.y 版本中是否仍然受支持内核？您是否知道有任何与T1024不兼容的更改？ FSL SDK DPAA 和 FSL SDK FMAN 驱动程序在 6.6.y 版本中是否仍然维护？内核？5.4.3 版本和 6.6.52 版本之间是否存在任何可能导致 T1024 功能失效的更改？ 我使用的内核源代码： 旧版本： https://github.com/nxp-qoriq/linux/tree/134788b16485dd9fa81988681d2365ee38633fa2 新增： https ://github.com/nxp-qoriq/linux/tree/e0f9e2afd4cff3f02d71891244b4aa5899dfc786 我的内核 6.6.52 配置片段： # # Frame Manager support # CONFIG_FSL_SDK_FMAN=y # CONFIG_FSL_SDK_FMAN_TEST is not set # # FMAN Processor support # # CONFIG_FMAN_P3040_P4080_P5020 is not set # CONFIG_FMAN_P1023 is not set # CONFIG_FMAN_V3H is not set CONFIG_FMAN_V3L=y # end of FMAN Processor support # CONFIG_FSL_SDK_FMAN_RTC_API is not set # CONFIG_FMAN_MIB_CNT_OVF_IRQ_EN is not set CONFIG_FSL_FM_MAX_FRAME_SIZE=1522 CONFIG_FSL_FM_RX_EXTRA_HEADROOM=64 # CONFIG_FMAN_PFC is not set # end of Frame Manager support CONFIG_FSL_SDK_DPAA_ETH=y # CONFIG_FSL_DPAA_HOOKS is not set CONFIG_FSL_DPAA_OFFLINE_PORTS=y CONFIG_FSL_DPAA_ADVANCED_DRIVERS=y # CONFIG_FSL_DPAA_ETH_JUMBO_FRAME is not set # CONFIG_FSL_DPAA_TS is not set # CONFIG_FSL_DPAA_1588 is not set CONFIG_FSL_DPAA_ETH_MAX_BUF_COUNT=1024 CONFIG_FSL_DPAA_ETH_REFILL_THRESHOLD=512 CONFIG_FSL_DPAA_CS_THRESHOLD_1G=0x06000000 CONFIG_FSL_DPAA_CS_THRESHOLD_10G=0x10000000 CONFIG_FSL_DPAA_INGRESS_CS_THRESHOLD=0x10000000 CONFIG_FSL_DPAA_ETH_DEBUGFS=y CONFIG_FSL_DPAA_ETH_DEBUG=y # CONFIG_FSL_DPAA_DBG_LOOP is not set 非常感谢您的帮助。 谢谢你， 吉里 QorIQ T1 设备 Re: QorIQ T1024: Linux Ethernet driver stucks on high traffic 你好， 根据 QorIQ Power Architecture T 系列软件的支持状态，T1024 不应被视为在新版 lf-6.6.y 上获得官方支持。内核分支。 NXP 对 T1024/T 系列的官方 SDK 支持随着旧版 QorIQ SDK 系列的推出而结束。文档指南指出，在 SDK 2.0-1703 之后，T1024 没有 SDK 版本，而 SDK 2.0-1703 使用的是内核 4.1.35。NXP 指南还指出，较新的 Linux BSP 可能仍然包含与 T1024 相关的文件，但它们并未正式发布以支持 T 系列。NXP 的另一份支持声明称，T 系列产品在 SDK 2.0-1703 之后没有正式版本发布，并且该产品线也没有持续的 SDK 升级计划。 因此， lf-6.6.y 中存在 T1024、DPAA、FMAN、QMan 或 BMan 代码。不应将其解释为 NXP 对 T1024 在该内核分支上的运行的验证。公开的 nxp-qoriq/linux 仓库是一个通用的 QorIQ Linux 代码库，但仅凭分支内容无法证明其对 6.6.x 版本的 T1024 支持或验证。 这不是 PHY/autoneg 问题；证据表明，TX DPAA/QMan 在未经验证的 T1024 内核基线上挂起，因此实际可行的办法要么是继续使用受支持/已验证的工作基线，要么作为自定义维护对 6.6 端口进行调试。 此致  

中子转换后的 YOLOv8n 模型无法在 i.MX95 中正常输出 您好， ，我从 ultralytics 导出了完全量化的 int8 YOLOv8n 物体检测模型。我已经使用最新的 eIQ Toolkit 版本 1.17 中的中子变流器将其转换成在 NPU 上运行，我曾尝试在 i.MX95 硬件上执行它。 我用 NPU 委托试过转换模型和非转换模型，但似乎只有转换模型上的中子图才能在 NPU 上执行。 当我比较两个模型的原始输出时，转换后的模型给出了多个假阳性，得分超过 95% 。我对已转换和未转换的模型都使用了相同的脚本，但只对已转换的模型有问题。我用多种方法进行了验证，但每次的结果都一样。 当我用 netron 应用程序检查这两个模型时，我发现转换后的模型在结构上发生了重大变化。 在此，我想问几点： 1.eIQ Toolkit 版本 1.17 的 Neutron 变流器是否支持像 YOLOv8 和 YOLOv11 这样的最新物体检测架构？ 2.您在 i.MX95 上使用 NPU 测试过 YOLOv8 和 YOLOv11 吗？如果回答为 "是"，请将模型和后处理步骤一并发送到 3.如果我们要在 i.MX95 中的 Neutron NPU 上执行 Neutron Graph 以外的操作，流程是什么？ 4. 如果我们要在 i.MX95 中的 GPU 上执行上述模型，流程是什么？ 我也翻阅了《机器学习用户指南》，但没有找到相关细节。 谢谢， Vatsal。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 你好 您遇到的 Neutron 转换 YOLOv8n 模型误报问题是一个已知的难题。目前 i.MX95 NPU 对 YOLOv8 模型的支持仍在优化中，转换过程中的架构变化可能会影响性能。 关于您的具体问题： 1. eIQ 工具包 1.17 中的 YOLOv8 架构支持仍在改进中。推荐的转换工作流程是： - 在导出模型时确保正确的 int8 量化 - 使用最新的 eIQ 工具包 (v1.17) 使用变流器进行转换 - 命令：`./变流器 --input [你的模型].tflite`--target imx95 --use-python-prototype` 2.虽然支持 YOLOv8，但可能尚未完全优化。YOLOv5 与当前的 NPU 实现具有更好的兼容性。恩智浦团队正在积极改进对 YOLOv8/YOLOv11 的支持。 3. 要在 NPU 上执行 Neutron Graph 以外的操作，需要使用 eIQ 或 netron 工具分析模型，以确定哪些运算符已成功转换为在 NPU 上运行（显示为 neutronop 内容）。未转换的运算符将在 CPU 上运行。 4.在 i.MX95 上执行 GPU 运算时，应使用 TensorFlow Lite GPU 委托而不是 NPU 委托。这需要修改推理代码以使用 GPU 委托。 您可以通过在 netron 中检查转换后的模型来验证模型操作的分布情况--任何含有"neutronop" 内容的运算符都在 NPU 上执行，而其他运算符仍在 CPU 上执行。 此致 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 我们再次使用带有自定义数据集的YOLOv5s进行了训练，并尝试进行推断，因为您在之前的聊天中声称YOLOv5使用中子变流器取得了不错的结果。YOLOv5 也仍然存在这个问题。我也附上结果以供参考。在这里，我们尝试了已转换和未转换的 int8 tflite YOLOv5s 模型。 现在，如果你声称 YOLOv5 能够带来良好的效果，那么为什么不与我们分享经过验证的模型呢？请分享从导出、量化到转换的所有步骤，以及后期处理的步骤。这样我们就可以验证您的模型，并在我们这里复制您所遵循的步骤。 如果可以的话，也请与i.MX95共享您的基准测试和我的数据。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 你好，@Bio_TICFSL！ 我注意到恩智浦团队建议使用 --use-python-prototype 标志，但是我的中子变流器无法识别它。它是在 Windows 上支持的，还是只与 Linux eIQ 版本兼容？ Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 这对我来说也是一个问题。我使用过 Linux eIQ，但效果不佳。因此我跳过了它，尝试只通过目标 arg 转换模型。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 您好@Bio_TICFSL, 由于时间已久，我仍在等待您的回复。我们被困在这里，我们也有一些紧迫感。请尽快回复。 谨致 Vatsal [i.MX95 NPU] YOLOv5n/v8n/v11n Neutron-converted Models Run but Return No Detections (Zero Output) 问题描述 我正在使用 Neutron 变流器在 i.MX95 NPU 上评估 YOLO 目标检测模型。 虽然 INT8 量化的 TFLite 模型在 Cortex-A55 CPU 上运行成功并能检测到物体，但编译后的 neutron.tflite 版本在卸载到 NPU 时，尽管执行推理时没有崩溃，却产生了零检测结果（空/无输出）。 环境及硬件设置   硬件： i.MX95 19x19 LPDDR5 EVK（A1 版本） 操作系统/内核： Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXP 工具链： MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 测试型号： YOLOv5nu、YOLOv8n、YOLOv11n（Ultralytics） 工作流程步骤和使用的命令 1. 量化（Ultralytics 导出） 模型导出为 INT8 全整数量化格式，分辨率为 320x320： yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状态：在CPU上运行完美。yolovXn_full_integer_quant.tflite 在 A55 内核上能够正确检测对象。 2. 中子汇编 TFLite 模型是使用 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 中的 Neutron 转换器为 i.MX95 NPU 编译的： ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状态：无法在 NPU 上检测到对象。编译后的模型可以加载并运行推理，不会抛出语法或执行错误，但对于完全相同的测试图像，输出张量返回零检测结果。 观察到的症状和疑似根本原因   操作回退：变流器是否会针对特定的 YOLO 层（如自定义锚点、SiLU/Swin 激活或非最大值抑制）回退到 CPU？ 量化缩放/不对称性：通过 Ultralytics 导出的 YOLO 模型通常使用不对称量化或具有 Neutron NPU 驱动程序可能误解的特定输出张量缩放。 输出张量格式：推理运行正常，这表明输入管道没有问题，但输出边界框/分数要么为空白，要么完全是垃圾值。 向恩智浦专家提问   中子变流器是否存在针对 Ultralytics YOLO 架构的已知限制或必需的优化标志？ 在将 TFLite 模型传递给 Neutron 转换器之前，是否应该去除 NMS（非极大值抑制）层？ i.MX95 Neutron SDK 是否需要对称量化（per_channel=True 或 False）才能正确解析输出层？ 任何关于 i.MX95 NPU 的指导、参考脚本或 YOLO 部署说明都将不胜感激。        

NFC天线中固体平面的作用 你好， 我们已将NFC天线集成到控制器板上。 我们的天线尺寸约为 90 毫米 x 40 毫米，有 3 圈。 它两侧已被地面包围。地平面与天线之间的距离约为 5 毫米。 我们的PCB制造商（生产多层PCB）要求我们在内层天线区域填充铜。 由于我找到了 NXP 的 NFC 演示板，其中以类似的方式实现了此功能，我认为它应该可行，并且我想以类似的方式实现它。 这些评估委员会采用这种方式实施的原因是什么？ 铜矿区对射程的影响程度如何？ 铜箔面积会影响电磁兼容性吗？是更好还是更糟？ 铜区域与天线之间的最小距离应该是多少？ 使用一个大区域好，还是使用几个小区域好？ 非常感谢，并致以最诚挚的问候。 迈克尔 Re: Function of solid plane in the NFC antenna 你好，迈克尔， 我们使用这种内部金属化的主要原因是为了演示目的，模拟 NFC 天线周围的真实环境，例如在 POS 终端中。 此外，这种金属填充物可能有助于减少其他物体造成的失谐效应，因为天线内部的“金属负载”已经使其调谐。 但是对于实际产品而言，我会选择内部没有任何填充物的传统 NFC 天线。 BR 托马斯 Re: Function of solid plane in the NFC antenna 嗨，托马斯， 非常感谢您提供的信息。 此后，我们进行了测试，将铜片（8 毫米 x 8 毫米，间隔 2 毫米，每片 2 层）粘到天线表面的顶部和底部。 然后我们测量了天线并重新匹配。 我们在功能方面（范围、电流测量和电磁干扰）检测不出任何差异。 您曾写道，您会推荐传统的设计方案。 造成这种情况的原因是什么？如果有，原因是什么？ 或许几个间距更大的小区域会比间距为 2 毫米的 8x8 毫米区域更好？ 非常感谢， 迈克尔 Re: Function of solid plane in the NFC antenna 你好@michael_d_1983 ， 如前所述，我们使用铜瓦来展示更真实的场景。 这意味着您可能会观察到读数范围略低，这比自由空间中的理想天线更能反映实际情况。这是因为部分能量被金属瓦片吸收了。 但如果调谐保持不变，则发射电流和电磁干扰不会发生变化。 因此，没有必要将这种设计应用到“实际”产品中。 BR 托马斯 Re: Function of solid plane in the NFC antenna 嗨，托马斯， 感谢您的反馈！ 我们其实根本不想把铜矿区包括在内。PCB制造商希望我们这样做。 （原因是，如果PCB上的铜分布不均匀，在PCB生产的层压过程中就会出现问题，例如气泡和分层，因为预浸料中的树脂不足以弥补铜的缺失。） 我们只是想澄清一下，是否存在我们尚未考虑到的反对这一做法的根本原因。 我们已经测试过了（阅读器功能）。一切似乎都正常运转。 此致， 迈克尔

如何为 iMX95 FRDM 构建 libcamera 目前我已经克隆并能够在运行 ubuntu 20.04 的主机 PC 上构建 libcamera。提供的 README 文件没有提供任何关于所需工具链的信息。如何克服这个问题？是否有适用于 IMX95 FRDM 的 Yocto 构建源代码，以便我们能够填充 SDK 并进行相应的构建？ Re: How to build the libcamera for iMX95 FRDM 选项 1（推荐）：在 Yocto 内部构建 libcamera 如果您的目标是修改或重新构建适用于 FRDM-i.MX95 的 libcamera： 下载与您的开发板/内核版本对应的 i.MX BSP 版本。 设置 Yocto 环境。 将 libcamera 构建为 Yocto 软件包： bitbake libcamera 或者将其包含在您的图片中： IMAGE_INSTALL:append = " libcamera" 然后重建： bitbake imx-image-full ` 这确保： 正确的 aarch64 编译器 正确的内核头文件 NXP Neo 流水线支持 匹配的IPA二进制文件 匹配 GStreamer libcamerasrc 插件 这是 i.MX95 最安全的路线。 方案二：在 Yocto 之外交叉编译 libcamera 如果您已经在 Ubuntu 20.04 上克隆了 libcamera，并且想要手动交叉编译它： 你不应该使用主机上的 gcc 。 而是从 Yocto 生成 SDK： bitbake imx-image-full -c populate_sdk i.MX Linux 用户指南明确提到了 SDK 生成和基于 Yocto 的工作流程。 SDK生成之后： tmp/deploy/sdk/*.sh 安装它： ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh 环境来源： 源 /opt/fsl-imx-xwayland/ /environment-setup-aarch64-poky-linux 然后使用 meson 构建 libcamera： shell meson 设置 版本 \ --cross-file= ninja -C 版本 具体交叉文件取决于 SDK 版本和 电路板支持包。 版本。 是否有适用于 i.MX95 的 Yocto 源代码？ 是的。根据内部 Linux 用户指南，i.MX95 支持通过标准的 NXP Yocto 电路板支持包和 meta-imx 基础架构提供。该指南还提到： bitbake imx-image-full 并引导用户查看 meta-imx README 和 Yocto 文档。[UG10163_i....-09_review | PDF] 具体到 FRDM-i.MX95，根据电路板说明书，该电路板预装了嵌入式 Linux Yocto 解决方案。

NFC PN7160 こんにちは、 私はNXP PN7160 NFCデバイスを搭載したカスタム基板を持っています。 目標はMIFARE PlusをLinux上で動作させることです。 現在、私たちはlibnfc-nciを使用しており、バッジ（タグの到着と出発）を検出することができています。 NXPが提供するMIFARE Plusを管理するライブラリはありますか? もしそうなら、このライブラリはバッジにAESキーを書き込む機能も提供していますか? ありがとうございます Re: NFC PN7160 こんにちは、 @angelobticino さん。 あなたの調子が良いといいのですが。 MIFAREデバイスをサポートするPN7160ソフトウェアはNDA(秘密保持契約)の下で保護されており、情報は公開されておらず、 PN7160 セキュアファイルの下に位置しています。 ただし、利用可能なソフトウェアはMIFARE DESFireデバイスのみに対応していることをお伝えしなければなりません。MIFARE Plusに関連する機能は、 MIFARE Plus EV2 のドキュメントに基づいて実装する必要があります(関連ドキュメントもNDAの下で保護されており、MIFAE Plus EV2 Secure Filesを通じてリクエストする必要があります)。 もしこれらのリソースに興味があれば、 NDAのオンラインフォームから直接NDAを申請してみてください。申請が処理された後、NXPのNDAチームから連絡が来るはずです。ご不明な点がある場合は、秘密保持契約に関するよくある質問（FAQ）をご覧ください。 NXPと有効なNDAを取得した場合、またはすでに有効なNDAを持っている場合は、このページの指示に従ってSecure Access Rightsを通じてこの文書へのアクセスを申請する必要があります: Secure Access Rights | NXP Semiconductors。また、 Secure Access Rights FAQs(セキュリティアクセス権FAQs)も確認することをお勧めします。NXP Semiconductors。 よろしくお願いいたします。 エドゥアルド。

通过 MU 安装 HSE 固件时出现 S32K3 恢复问题 我们目前正在使用 HSE 在 S32K344/S32K314 上开发安全启动功能，该功能基于 `S32K344_Advanced_SecureBoot` 演示程序，该演示程序来自 `S32K3_HSE_DemoExamples`。我们已经完成了大部分功能开发，并且可以成功进行调试。在我们的配置程序中，我们使用 ED25519 计算 BM、FBL 和 APP 的签名，将它们写入闪存中的指定地址，并为这三个应用程序配置 SMR 和 CR（BM 作为启动前 SMR，FBL 和 APP 作为启动后 SMR）。但是，我们遇到了一些不清楚的问题，希望您能提供帮助。我们目前使用的是 HSE 的FULL_MEM形式。 由于我们使用 ED25519 算法来计算所有应用程序二进制文件的签名，因此配置程序需要很长时间才能执行。如果在程序完成之前意外发生断电，我们发现 HSE 会进入不可恢复的错误状态。重启或重新刷新固件后，HSE 不再响应任何主机请求。通过检查 `0x4039C028` (HSE_CONFIG_GPR3) 处的寄存器，我们发现其值为 `0xC0`；第 0 位已变为 `0`，这表明 HSE 固件可能已被 SBAF 擦除。上电后，MU0 FSR 寄存器也为“0”。因此，我们尝试重新安装 HSE 固件。由于通常基于 IVT 的安装方法不再有效，我们尝试通过 MU 界面进行安装。 我们模拟了文档中描述的步骤，但发现将粉色图像的 SRAM 地址写入 MU Tx 寄存器（步骤 5）后，HSE_CONFIG_GPR3 中的值立即从 `0xC2` 变回 `0xC0` – 即，位 1 从 `1` 变为 `0` – 我们始终无法收到预期的成功响应 `0xDACACADA`。 我们在论坛上也提到过类似的问题： S32K3_HSE 的 MU 安装 AB_SWAP 过程不正确。我们尝试在步骤 5 之后立即执行功能 RESET，但 RESET 后仍然无法安装新的 HSE 固件。 请问如何处理和恢复这种损坏的 HSE 状态？ 如果需要任何调整，请告诉我。 Re: S32K3 recovery issue when install HSE fw via MU 嗨@成金王 我无法读取您分享的项目中的源文件，因为它们已被加密。请提供包含纯文本（未加密）文件的版本。 几天前，我创建了一个 Trace32 脚本，用于通过 MU 接口恢复 HSE AB_SWAP 固件，所以我很快将其修改为 FULL_MEM 版本。我这边可以正常工作——我收到了 0xDACACADA 响应。 在输入粉色图像位置后，您是否会等待大约 1.5 秒再执行任何进一步操作？FULL_MEM 安装过程中没有明确提及此延迟，但 AB_SWAP 版本需要此延迟。这可能是问题所在。 如果你在使用 Trace32，请告诉我，我可以分享我的脚本。 此致， Lukas Re: S32K3 recovery issue when install HSE fw via MU 这是我通过 MU 安装 HSE 固件时使用的恢复程序；您能帮忙看一下哪里出了问题吗？ Re: S32K3 recovery issue when install HSE fw via MU 附件是我当前使用的项目的未加密版本。我的测试中使用了 S32K344 芯片、PE 调试器和附件中的 S32DS 项目。我尝试在写入粉色图像后等待几秒钟，以接收来自 SBAF 的成功响应，但这也没有奏效。直接执行功能重置也无效。请您检查一下附件项目中我的 MU 安装程序是否存在任何问题？ Re: S32K3 recovery issue when install HSE fw via MU 我在我的开发板上测试了这个项目。首先，我必须修复启动文件中的 RAM 初始化问题，因为当粉色文件复制到 RAM 时出现了硬故障。这些 HSE 演示示例中的 RAM 初始化并不理想，所以我做了如下快速修复： Pemicro 调试器会自动初始化 RAM，并且在功能复位后 RAM 内容仍会保留，因此您可能没有遇到此问题。但通电后却无法工作。我使用 Trace32 进行调试，所以一开始就看到了这个问题。 然后我修改了 IVT——我删除了指向粉色文件的指针，这样在第一次RESET后它就不会自动安装，我可以通过 MU 确认安装。 结果——我得到了 0xDACACADA，固件已通过 MU 安装。所以，这个步骤显然是正确的。 问题是为什么在你那边不起作用。 您的设备上的SBAF版本是什么？请读取 0x4039_C020 处的双字。 此致， Lukas Re: S32K3 recovery issue when install HSE fw via MU 这是我读到的结果。 Re: S32K3 recovery issue when install HSE fw via MU 此外，我们目前使用的是 HSE 固件版本 0.2.55.0。 Re: S32K3 recovery issue when install HSE fw via MU 你好， @lukaszadrapa 。这个问题我还没解决。如果您那边有任何进展，请告诉我。谢谢。 Re: S32K3 recovery issue when install HSE fw via MU 谢谢你！我通过直接触发 SWAP 请求成功恢复了 HSE 固件。然而，令我困惑的是，我一直都在使用 FULL_MEM 固件——那么为什么最终固件是通过 AB_SWAP 恢复的呢？ Re: S32K3 recovery issue when install HSE fw via MU 很抱歉回复晚了。 您的 SBAF 版本为 0.15.0，与 HSE 固件 0.2.55.0 完全兼容。这没问题。 为了进行测试，我使用 HSE_SRV_ID_ERASE_FW 服务完全擦除了固件，因此被动分区中没有有效的备份。 就你的情况而言，备份似乎可用，所以流程可能有所不同（不确定为什么这样做行不通）。我从你的代码中看到，只交换功能没有实现。您能否尝试将其添加到您的代码中？这或许能解决问题。 此致， Lukas Re: S32K3 recovery issue when install HSE fw via MU 那很有意思。坦白说，我犯了个错误——我同时要服务很多客户，不知何故，我误以为你们使用的是 AB_SWAP，而不是 FULL_MEM。否则我不会推荐它。我看到了两种可能的解释——如果固件仍有有效的备份，那么即使在 FULL_MEM 的 MU 程序中没有描述“swap”命令，该命令也可能适用于 FULL_MEM 版本。第二种可能是，恢复应用程序触发的功能重置迫使 SBAF 完全擦除固件，然后安装成功。不太确定，这很难重现和确认……

S32K144 FLASH分配自定义字段 将程序中想要写入的数据放入自定义字段 恩智浦的技术人员你们好 我在开发S32K144芯片的过程中遇到了一个问题 我想将一些变量放入我自定义的ROM字段  我不清楚该怎么在程序中实现 我在S32K144_64_flash.ld中定义了存储字段 并且在SECTIONS 中定义了CALC_RAM #define CALC_RAM_ATTRIBUTE __attribute__((section(".CALC_RAM"))) CALC_RAM_ATTRIBUTE const uint8_t my_flash_array[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_brray[] = {0x01, 0x02, 0x03, 0x04}; CALC_RAM_ATTRIBUTE const uint8_t my_flash_crray[] = {0x01, 0x02, 0x03, 0x04}; 通过以上代码我已经将我的数组放入了CALC_RAM自定义字段   我的问题是  这样的操作方式比较繁琐  在新定义的 数组前  都需要加入CALC_RAM_ATTRIBUTE 这个宏定义 有没有更便捷的方法将  一段数据批量放入  我自定义的字段CALC_RAM  ？ 期待您的回复    万分感谢！ Re: S32K144 FLASH分配自定义字段 将程序中想要写入的数据放入自定义字段 嗨@Ni_ ， 你通常有三种选择： 方案一。 修改时保留这些属性。 方案二。 将所有内容放入一个专用的源文件中，例如： /* cal_data.c */ #include const uint8_t table1[] = { 0x01, 0x02, 0x03, 0x04 }; const uint8_t table2[] = { 0x10, 0x20, 0x30, 0x40 }; const uint8_t table3[] = { 0xAA, 0xBB, 0xCC, 0xDD }; 然后在链接器文件中： MEMORY { int_flash_interrupts : ORIGIN = 0x00000000, LENGTH = 0x00000400 int_flash_config : ORIGIN = 0x00000400, LENGTH = 0x00000010 int_flash : ORIGIN = 0x00000410, LENGTH = 0x0007BBF0 calib_flash : ORIGIN = 0x0007C000, LENGTH = 0x00004000 int_sram_results : ORIGIN = 0x1FFF8000, LENGTH = 0x00000100 int_sram : ORIGIN = 0x1FFF8100, LENGTH = 0x0000DF00 int_sram_stack_c0 : ORIGIN = 0x20006000, LENGTH = 0x00001000 ram_rsvd2 : ORIGIN = 0x20007000, LENGTH = 0 } .flash_config : { KEEP(*(.flash_config)) } > int_flash_config .calib_flash : { . = ALIGN(4); __calib_flash_start = .; KEEP(*cal_data.o(.rodata*)) . = ALIGN(4); __calib_flash_end = .; } > calib_flash .flash : { . = ALIGN(4); *(.startup) . = ALIGN(4); *(.systeminit) . = ALIGN(4); *(.text.startup) . = ALIGN(4); 在 .map 中文件： 选项 3. 使用 pragma/macros 部分。 有些编译器支持它，但 GCC 不支持。 此致， 丹尼尔 Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.