Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
補足説明が必要:QSPIフラッシュメモリの容量がデータシートと実際のハードウェアで一致しない NXPチームの皆様、こんにちは。 指定された部品番号のボードを購入しましたが、オンボードのQSPIフラッシュ容量に関して不一致があることに気づきました。 MCIMX6ULL-EVK データシートによると、このボードには256MBのQSPIフラッシュメモリが搭載されているとのことです。しかし、オペレーティングシステムからフラッシュメモリのサイズを確認すると、32MBとしか表示されません。 これを確認するために、デザインファイルをダウンロードし、BOMを確認しました。私も同じフラッシュデバイスの部品番号をDigiKeyとMouserで調べてみましたが、どちらも256Mbitのフラッシュメモリと記載されており、これは256MBではなく32MBに相当します。 Element14の代理店を通じてボードを購入しました。 以下の点について明確にしていただけますか: データシートに誤植があり、256 MBではなく256 Mbitと記載されるべきです。 データシートと実際のハードウェアでストレージの分類が異なるように見える理由について、他に何か説明があるのだろうか? 私の調査によると、搭載されているフラッシュメモリは256MBではなく、256Mbit(32MB)のようです。 ご確認いただければ幸いです。 よろしくお願いします。 i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware おっしゃる通りです。関係部署に報告します。256Mbitということは、32MBということですね。
記事全体を表示
PCF8563TS 生命周期状态和长期供货情况 你好呀.... 我们目前在我们的一款产品中使用了PCF8563TS RTC,并希望更好地了解其长期生命周期状况。 过去,我们的产品是基于PCF8563BS的,但该芯片最终已达到生命周期结束 (EOL)。因此,我们不得不进行完整的硬件重新设计,以迁移到另一个封装,这产生了额外的工程工作量、验证和制造成本。 鉴于以往的经验,我们想问: 是否有任何迹象表明PCF8563TS即将停产或处于 NRND 状态? 这款设备是否有长期供货计划? NXP能否分享一些关于其预期产品生命周期或路线图的信息? 对于围绕 PCF8563TS 设计新产品的客户,有什么建议吗? 我们理解未来的计划可能会有所改变,但任何关于该设备预期寿命的指导都将有助于我们做出明智的设计决策,并降低未来重新设计的风险。 感谢您的支持。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 我做了一些调查,对于像 PCF8563TS $0.5 这样的芯片,由于存货很大,停止生产并不容易。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 你好,维克多, 感谢您对恩智浦半导体产品的关注,也感谢您给我们提供支持的机会。 我们拥有长期供应计划下的产品,可确保未来 10-15 年的稳定供应。 长寿计划 然而, PCF8563TS 不属于产品延保计划,因此没有停产通知或最后购买日期。具体情况将取决于客户需求。 此致, 阿隆德拉 技术支援 恩智浦半导体
記事全体を表示
eFlexPWM入力キャプチャがS32K364でキャプチャされない - フラグは設定されているがCAPTCOMPBはゼロのまま 私はS32K364マイクロコントローラのeFlexPWMモジュール(インスタンス IP_EFLEXPWM_0)を使って、入力キャプチャを通じて外部信号の周波数と周期を測定しています。私は サブモジュール2 (SM[2])を使用しています。私の構成は以下の通りです: SM2_CAPTCTRLB->EDGB0 = 0x02; (キャプチャ回路0の場合、立ち上がりエッジでキャプチャ) SM2_CAPTCTRLB->EDGB1 = 0x02; (キャプチャ回路1の立ち上がりエッジでのキャプチャ) SM2_ARMB = 1; (キャプチャー回路をArm) コードを実行した後、以下のことが確認されました。 で SM2_CAPTCTRLBのカウンタステータスビットは以下を示します。 CB0CNT = 0x4 CB1CNT = 0x4 で SM2_STS 、両方のフラグビットがセットされています。 CFB0 = 1 CFB1 = 1 しかし、取得された値( SM2_CAPTCOMPB )は 0 どちらのキャプチャ回路においても、データはラッチされません。 これは何が原因でしょうか?他に何か必要な設定(例えば、クロックの有効化、入力多重化、カウンタの設定など)で、私が見落としているものはありますか?フラグはキャプチャイベントが検出されたことを示しますが、キャプチャされた値は更新されません。どんなご意見でも大変ありがたく思います。 必要に応じて、ピン多重化設定やカウンターモードなどの詳細情報を追加してください。幸運を! Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero ハイ まず、最新のS32K3 RTD 7.0.xを確認しました。しかし、 S32設定ツール はまだ eFlexPWM E-Capture 機能をサポートしていません。 もしよければ、S32K396でテストしたいので、あなたのプロジェクトを共有してもらえますか?(残念ながら、私はS32K364を持っていません。私は S32K396-BGA-DC1 評価ボードしか持っていません。) 次に、 S32K396RM(Rev. 4、11/2024) の 「56.3.14 拡張キャプチャ(E-Capture)」の セクションを確認してください。そのセクションで言及されているレジスタ、特に図 254 のレジスタを確認してください。E-キャプチャ ロジック。eFlexPWM_0レジスターのスクリーンショットも共有しても構いません。 SM2_CAPTCTRLBの[EDGB0]、[EDGB1]、[ARMB]で言及されたビット以外に、 SM2_CAPTCTRLBの他のビットはどのように設定しましたか?   SM2_CAPTCTRLB[CB0CNT] = 0x4および[CB1CNT] = 0x4を確認されたとのことですので、対応するレジスタ値SM2_CVAL4 、 SM2_CVAL4CYC 、 SM2_CVAL5 、およびSM2_CVAL5CYCを確認されましたか?   さらに、 SM2_CAPTCOMPB[EDGCNTB]の値を読みたい場合は、まず SM2_CAPTCTRLB[EDGCNTB_EN] と SM2_CAPTCOMPB[EDGCMPB]を有効にしてください。 なぜ SM2_CAPTCOMPB[EDGCMPB] を0に設定しているのか分かりません。図254のコンパレータが使えなくなるように見える からです。E-キャプチャロジック が正しく機能しない。 よろしくお願いいたします ロビン Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero こんにちは、 @Robin_Shen さん。 MCTRLレジスタとCAPTCTRLBレジスタを適切に設定することで、外部周波数測定を正常に実装できました。しかし、テストの結果、私が達成できる最低周波数は5kHzであり、私の要求は1Hz程度の低周波数をサポートすることになっています。 プリスケーラーとプリスケーラー代替設定を調整してみましたが、改善は見られませんでした。何か提案やトラブルシューティングの方法を教えていただけますか?サポートありがとうございます。 Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero サブモジュール2の周期が短すぎるようです。「 56.3.18.3 サブモジュール0よりも低い周波数でサブモジュールを実行する」を読んで、サブモジュール2にAUX_CLKやEXT_CLKなどのより低い周波数のクロックソースを選択してみてください。
記事全体を表示
i.MX95 Neutron NPU用にYOLOv8/YOLO11 TFLiteモデルをコンパイルできません こんにちは、NXPサポートチームの皆さん、 私たちはNeutron SDK v3.1.3を用いてFRDM i.MX95プラットフォーム上の物体検出を評価していますまた、NPU互換モデルを生成できません。Neutronコンバータはモデルを正常にロードしますが、 Neutron NPUに割り当てられたオペレーターは0個と報告します。 環境 対象ボード:FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: YOLO11とYOLOv8の両方でテスト済み eIQツールキット:ONNXからTFLiteへの変換に使用 モデル:カスタムの単一クラスペグ検出器 トレーニング司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=モデル \ name=peg_detector_v8 エクスポートコマンド $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml また、別のワークフローもテストしました。 PyTorchをエクスポート → ONNX NXP eIQツールキットを使用してONNXをINT8 TFLiteに変換する Neutron SDKでコンパイルした場合、両方のワークフローは同じ結果を生み出しました。   Neutron コンパイル ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   コンバータ出力 コンバーターは次のように報告しています: インポート後のオペレーター数:341 最適化後の演算子数:367 変換された演算子: 0 オペレーター変換率:0 / 367 Number of Neutron graphs: 0 警告: 警告:グラフの演算子はニュートロンにマッピングされていません。 警告:変換されたモデルは入力モデルと同じで、演算子が中性子にマッピングされていないためです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています!これによりコンバージョン率が低くなることがあります。 その他の情報 以下のケースでも同様の挙動が観察されました。 YOLO11 YOLOv8 ダイレクトUltralytics TFLiteエクスポート ONNX → eIQ ツールキット → INT8 TFLite 生成されたすべてのTFLiteモデルは、Neutronコンパイラによって 0演算子をマッピング します。 質問 YOLOv8またはYOLO11のオブジェクト検出モデルは、i.MX95用のNeutronコンパイラで公式にサポートされているのでしょうか? i.MX95 NPUをターゲットにしたYOLOモデル向けの推奨エクスポートパイプラインはありますか? 現在のNeutron SDK(v3.1.3)には既知の制限はありますか?YOLO検出ヘッドに関してですか? NXPはi.MX95 NPU向けに正常にコンパイルできるリファレンスYOLOv8/YOLO11モデルを提供していますか? 演算子マッピングを有効にするために、追加のコンパイラオプションや前処理手順が必要ですか? i.MX95 Neutron NPUで動作することが知られているガイダンス、推奨ワークフロー、または参照モデルがあればぜひ教えていただけるとありがたいです。 よろしくお願いします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU そして、あなたの人生を本当に大切にしてください。 もし本当に 、私がこのゲームを望むなら、私はこのゲームを L に x x 95 でイノシシd. 私たちは今、AR A2 を手に入れたので、そのキャパビリのつながりと 、あなたたちの兄弟の絆を活用します。 私たちはNXで実際にデモを作ったことがあるし、あなたはこのマットで最初に知られるだろうと、もっと早くアプリに報告されるだろう. あなたの LPに感謝します。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Model zooのyolo8mモデルをimx95ボードで試し、LF 2026年Q2リリースイメージを使いました。カーネルバージョンはNeutron SDK 3.1.2を使用して6.18.2です。うまくいく。     まずは以下から試してみることもできます: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-Smart.imx95.tflite --external_delegate_path=/USR/LIB/libneutron_delegate.so 詳細はREADMEのeiq-model-zoo/tasks/ビジョン/object-detection/yolov8を参照してください。NXP/eiq-model-zoo さらに、モデルやコンプリエーションの詳細なログを添付することもできます。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU コンバーターログに基づくと、最初に解決すべき問題は、生成されたTFLiteモデルに依然としてFLOAT演算子が含まれていることです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! i.MX95 Neutronの場合、ニュートロンコンバータへの入力は、演算子と量子化フォーマットがNeutronコンパイラと互換性のあるTFLiteモデルでなければなりません。特に、i.MX95中性子流は量子化されたTFLiteと対称int8重みを期待しています。UltralyticsエクスポートやONNXからTFLiteへの変換後もモデルにFLOAT演算子/テンソルが残っている場合、コンバーターは報告された結果と整合するNeutron互換の部分グラフを作成できない可能性があります。 変換された演算子: 0 中性子グラフの数:0 YOLOv8はi.MX95上で一部のフローにおいて評価されていますが、任意のUltralyticsエクスポートにおいて、エンドツーエンドのYOLOv8/YOLO11オフロードが完全に実現されるとは限りません。エクスポートされたTFLiteグラフによっては、モデルの一部のみがNeutronGraphに変換され、サポートされていない演算子はCPU上に残ります。したがって、次の推奨ステップは生成されたTFLiteモデルを検査・プロファイリングし、以下のことを確認することです: グラフは完全に量子化されており、 FLOAT演算子はありません。 重みは対称な int8、 入出力テンソルタイプは互換性があり、該当する場合はNeutron変換器のuint8からint8への変換オプションで変換されます。 デコードやNMSなどのYOLO後処理は、SDKで正確な演算子がサポートされていることが確認されない限り、NPUグラフの外に保管されます。 また、Neutron-Converter版とボード上のNeutronランタイム/ファームウェア/デリゲートが同じ互換性のあるSDK/BSPリリースから来ていることも確認してください。 推奨される手順として、NXP/eIQ変換パスをお試しください。 PyTorch -> 静的入力形状のONNX -> 代表的な較正データを用いたNXP/eIQ量子化 ->量子化されたTFLite -> Neutron-converter --ターゲットIMX95 モデルにuint8の入力/出力テンソルがある場合は、以下もテストしてください: --入力値をuint8からint8に変換 --出力をuint8からint8に変換 FLOAT演算子を削除した後も変換結果にマッピングされた演算子が0と表示される場合は、以下の情報を共有してください。 - 詳細/プロファイリング出力を含む完全な中性子変換ログ - TFLiteオペレーターリスト、 - テンソルデータ型と量子化パラメータ、 - FRDM i.MX95ボード上のBSP/実行時Neutronデリゲート/ファームウェアバージョンの正確なバージョン、 - YOLO検出ヘッドにNMSやその他の後処理が含まれているかどうか。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 私のテストでは、 自分でトレーニングもエクスポートもしていません。eIQ Model Zooのプリ生成されたYOLOv8モデルを使い、i.MX95プラットフォームで動作することを確認しました。 私が実際に使用したコマンドはこれだけです。 ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 モデルでは: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite カスタムモデルの場合、推奨されるNXPフローは以下の通りです: PyTorch ↓ ONNX(静的入力形状) ↓ eIQツールキット ONNX2Quant ↓ eIQツールキット ONNX2TFLite ↓ 量子化されたTFLite ↓ Neutron-converter --ターゲットIMX95 あなたのモデルが報告しているので: プレーンテキスト 変換された演算子: 0 Number of Neutron graphs: 0 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! あなたの生成されたTFLiteグラフは、eIQ Model Zooの参照モデルとは構造的に異なるのではないかと推測しています。まず最初におすすめしたいのは、以下の2つのモデルを比較することです: 入力/出力テンソル型(INT8 vs UINT8) FLOAT演算子の存在 グラフ内のデコード/NMSレイヤー Netron / TFLiteアナライザーによって報告されたオペレーターリスト Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推奨されるエンドツーエンドのワークフロー モデルトレーニング(PC) お好みのフレームワークを使用してトレーニングしてください。 ウルトラリティクス YOLOv8 PyTorch テンソルフロー ONNXネイティブワークフロー 物体検出に関しては、NXPはすでにeIQモデルズーでYOLO参照レシピを提供しており、YOLOv8オブジェクト検出モデルも含まれています。[github.com] 、[github.com] 例: シェル YOLO検出トレーニング model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ エポック数=100 ` ONNX形式でエクスポート NXPは一般的に、量子化および展開の前に、交換フォーマットとしてONNXを使用することを推奨しています。 YOLOエクスポート model=best.pt \ フォーマット=onnx Neutron イネーブルメントのプレゼンテーションは、以下に基づくフローを明示的に記述しています: プレーンテキスト PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ Neutron コンバータ 訓練アーティファクトから直接展開を狙うのではなく、 eIQツールキットを使用した量子化 Neutronのワークフロードキュメントでは、eIQ Toolkitの量子化ユーティリティの使用を推奨しています: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: 「 に続く: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite もっと行を表示 この流れはi.MX95 Neutron イネーブルメント材料に明示的に記録されています。 i.MX95 Neutron NPU用にコンパイル Neutron-converter \ --ターゲット imx95 \ --input model_int8.tflite \ --出力 model_neutron.tflite ニュートロンコンバーターは、NPUにオフロードできるNeutron特有のグラフパーティションを作成します。 コンバージョン率の検証 NPUのデプロイが成功すると、以下のようなレポートが表示されます。 変換されたオペレーターの数 > 0 Number of Neutron graphs > 0 次のような場合: 変換された演算子: 0 Number of Neutron graphs: 0 この場合、モデルはNPUによって加速されていません。 あなたの抱えている問題は、このカテゴリーに該当します。 FRDM-i.MX95に展開する TensorFlow LiteでNeutronデリゲートを使い実行します: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 または ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX Machine Learning User Guideでは、 Neutron Delegate がi.MX95 TensorFlow Liteモデルの加速機構として特定されています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU yolov8m_full_integer_quant.tfliteをどのように変換してIMX95のNPUで動作させたのか教えてもらえますか? 手順に従って環境設定データ(HOST)を経て...私たちにとって大いに助けになるでしょう。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは 私はUbuntu 24.04を使用していますが、eiq_toolkitは20.04.03でのみ利用可能です。 eiqToolkitとeIQ Toolkitを使った量子化の使い方 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ ToolkitはUbuntu 20.04で検証済みであるため、最も安全な方法は以下のとおりです。 Docker Ubuntu 24.04ホスト上でUbuntu 20.04コンテナを実行します。 docker run -it --name eiq \ ubuntu:20.04 /bin/bash 次に、コンテナ内に必要な依存関係とeIQ Toolkitをインストールします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Toolkit(onnx2quant)を使ってカスタムYOLOv8 ONNXモデルを変換する際に信頼度を維持できない 概要 こんにちは、NXPチームの皆さん、 私はfdm i.MX95上でeIQ Toolkitを使ってカスタムYOLOv8単一クラスオブジェクト検出モデルを展開しようとしています。 変換パイプライン全体は正常に実行されますが、onnx2quant の後、信頼度出力がすべてゼロになり、バウンディングボックス出力は有効なままです。 環境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX ランタイム 1.21.1 - テンソルフロー 2.21 - Neutron-コンバータ 3.1.3 - ターゲット:FRDM i.MX95(tflite_runtime 2.19+Neutronデリゲート) 変換パイプライン 1. 列車 Yolo Detect Train Model=yolov8N.pt data=dataset.yaml imgsz=640 epochs=50 2. ONNXのエクスポート Yolo export model=best.pt format=onnx opset=13 3. ONNXの検証 入力:(1,3,640,640) 出力:(1,5,8400) ONNXランタイム推論: 信頼チャネル最大値 = 0.773 4. キャリブレーションデータセットの生成 形状:(1,3,640,640) dtype : float32 範囲:0.0 - 1.0 5. 量子化 onnx2quant best.onnx -c "images;キャリブレーション/画像」 -o best_quant.onnx また、以下の項目もテストしました。 onnx2quant best.onnx -u どちらも同じ結果を生み出す。 6. 量子化されたONNXの検証 出力:(1,5,8400) バウンディングボックスチャネルは有効のままです。 自信: 最小値 = 0 最大値 = 0 平均 = 0 デコードされた検出数 = 0 7. TFLite形式に変換する onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron Neutron-converter --ターゲット IMX95 --入力 best.tflite --出力 best_neutron.tflite コンパイルに成功しました。 オペレーター変換率:278 / 325 (85.5%) 調査実施 検証済み: • PyTorchモデルの動作 • ONNX輸出作品 • ONNXランタイム推論の動作 • キャリブレーションデータセットは正確です • 実数およびランダムキャリブレーションで同一の結果が得られます • TFLiteは量子化されたONNX出力を再現します • NeutronはTFLite出力を再現します この問題は以下以下に初めて現れます: ONNX ↓ onnx2quant ↓ 量子化されたONNX(信頼度がゼロになる) 追加の観察 NXPの参照モデル: 入力:(1,640,640,3) INT8 出力:(1,84,8400)INT8 私の改造モデル: 入力:(1,3,640,640) FLOAT32 出力:(1,5,8400) FLOAT32 カスタムYOLOv8モデルの信頼度を保つ推奨されるエクスポートや量子化のワークフローはありますか? これは、(1,5,8400)出力を持つモデルのonnx2quantの制限やバグでしょうか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU AEチームと話し合っています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240のエンドツーエンド評価は実施されましたか?データシートには、シグモイドやNMSなどの後処理操作を実行できる2つのベクターコアが記載されています。コンパイラはNMSの操作をベクターコアにマッピングできますか?
記事全体を表示
UG10215はIMX708をサポートしていると記載されていますが、どのカーネルドライバーを使うべきでしょうか? こんにちは、 私はUG10215(i.MX 95カメラ移植ガイド)に従って、Raspberry PiのSony IMX708カメラをi.MX 95ベースのボードに統合する作業に取り組んでいます。 ドキュメントの「サポートされているカメラセンサーモジュール一覧」の表には、サポートされたリファレンスカメラモジュールとしてRaspberry Pi Sony imx708が記載されています。しかし、linux-imxリポジトリ(lf-6.18.yのブランチ )で対応するドライバー(例:imx708.c)が見つかりませんでした😞 https://github.com/nxp-imx/linux-imx/commits/lf-6.18.y/drivers/media/i2c i.MX 95のIMX708センサにどのカーネルドライバが使われる予定か、詳しく教えていただけますか?IMX708ドライバは公開BSPに含まれていますか? よろしくお願いいたします。
記事全体を表示
需要澄清:数据手册与实际硬件的 QSPI 闪存容量不匹配 您好,NXP团队, 我购买了一块符合指定零件编号的电路板,但我发现板载 QSPI 闪存容量存在差异。 MCIMX6ULL-EVK 数据手册显示,该电路板包含 256 MB QSPI 闪存。但是,当我从操作系统中检查闪存大小时,它只显示 32 MB。 为了验证这一点,我下载了设计文件并检查了物料清单。我还在 DigiKey 和 Mouser 上查找了相同的闪存设备部件号,两家都将其列为 256 Mbit 闪存,这相当于 32 MB,而不是 256 MB。 我通过 Element14 代理商购买了这块板。 请问您是否可以澄清以下事项: 数据手册中有一处拼写错误,应该写成 256 Mbit 而不是 256 MB? 或者,数据手册和实际硬件似乎使用了不同的存储分类,还有其他解释吗? 根据我的调查,安装的闪存设备似乎是 256 Mbit (32 MB) 而不是 256 MB。 希望您能确认一下。 谢谢! i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware 你说得对,我会向相关团队汇报,是 256Mbit,也就是 32MB。
記事全体を表示
PCF8563TS Lifecycle Status and Long-Term Availability Hello there.... We are currently using the PCF8563TS RTC in one of our products and would like to better understand its long-term lifecycle status. In the past, our product was based on the PCF8563BS, which eventually reached End of Life (EOL). As a consequence, we had to perform a complete hardware redesign to migrate to another package, generating additional engineering effort, validation, and manufacturing costs. Considering this previous experience, we would like to ask: Is there any indication that the PCF8563TS is approaching EOL or NRND status? Is there a long-term availability plan for this device? Can NXP share any information regarding its expected product lifecycle or roadmap? Are there any recommendations for customers designing new products around the PCF8563TS? We understand that future plans may be subject to change, but any guidance regarding the expected longevity of this device would help us make informed design decisions and reduce future redesign risks. Thank you for your support. Re: PCF8563TS Lifecycle Status and Long-Term Availability I did some research, and for chips like the PCF8563TS $0.5, which have a large inventory, it's not so easy to stop production. Re: PCF8563TS Lifecycle Status and Long-Term Availability Hello Victor,  Thank you for your interest in NXP Semiconductors products and for the opportunity to support you. We have products under longevity program which ensures a stable supply for the next 10-15 years.  Longevity program  However PCF8563TS is not part of the longevity program there is no discontinuation notice or last purchase date. Will depend on customer's demands Best regards, Alondra Technical Support NXP Semiconductors
記事全体を表示
i.MX95 FlexSPIブートイメージ用のAPPコンテナソフトウェアバージョンを更新できません こんにちは、専門家の皆様。 i.MX95プラットフォームの開発を進めており、ROLLBACK_INDEX_IN_CONTAINERを使ってロールバック保護を有効にしています。 local.confに以下の変数を追加しました。 export ROLLBACK_INDEX_IN_CONTAINER = "1" この値はビルドプロセス全体に伝播され、ビルドログにはmkimage_imx8が「1」で呼び出されたことが記録されています。 eMMCブートイメージを構築する際、生成されたイメージを解析するとコンテナソフトウェアのバージョンが正しく更新されていることが確認されます。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   しかし、FlexSPIのブートイメージ(imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi)を構築する際には、画像を解析してもデフォルトのソフトウェアバージョンが報告されます ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 iMX95/soc.mak で興味深い点に気づきました。flash_a55_flexspi のビルド時に sw_version が含まれていないのです。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 私の質問は以下のとおりです。 FlexSPIのブートイメージのソフトウェアバージョンを更新するROLLBACK_INDEX_IN_CONTAINER期待されていますか? FlexSPIイメージは、ロールバックインデックスやソフトウェアバージョンを別々に設定する必要がある別のコンテナ生成フローに従っているのでしょうか? これは、i.MX95のimx-mkimageビルドフローにおける既知の制限事項または問題でしょうか? もしi.MX95でFlexSPIブートイメージのROLLBACK_INDEX_IN_CONTAINERを成功裏に有効にした方がいれば、予想されるフローや追加設定について教えていただけますか? よろしくお願いいたします! よろしくお願いいたします。 アルン・クマール Re: Unable to update APP container software version for i.MX95 FlexSPI boot image こんにちは、@arun16598さん FlexSPIイメージはAHABフォーマットの別のバリエーションではなく、まずブートコンテナを生成し、次にU-Boot/ATFコンテナを追加するという複合的なプロセスを採用しています。あなたの-sw_version 1はu-boot-atf-container.imgに設定されています。ただし、flash_a55_flexspiが最初に作成するSM/M33、OEI、SPL、FCBを含むAPPコンテナは-sw_versionオプションを通さないため、そのコンテナは依然としてSWバージョン0を表示します。ROLLBACK_INDEX_IN_CONTAINERはセカンダリのU-Boot/ATF APPコンテナを生成するために使われますが、flash_a55_flexspiが作成したプライマリAPPコンテナには渡されません。最初のFlexSPI APPコンテナに同じソフトウェアバージョンが必要な場合は、flash_a55_flexspiのmkimage_imx8呼び出しに-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)を追加する必要があります。 真の AHAB アンチロールバックの強制が目的であれば、確認および設定すべき重要な設定はsw_versionだけでなくfuse_versionと-fuse_versionです。S PSDKのi.MX95アンチロールバックの例では、OEMアンチロールバックはAHABコンテナYAMLで指定されたfuse_versionを使用し、そのバージョンはその後ELEのOEM_FW_FUSEコミットプロセスを介して送信されることが明確に示されています。 よろしくお願いします、 志明
記事全体を表示
KW47拡張広告 こんにちは、 私が使っているSDKのバージョンは26.06です。 ルーチンは kw47loc_loc_reader_freertos です。 #define gAppIsPeripheral_d                   1U   BluetoothLEHost_StartExtAdvertising の呼び出しの戻り値は 4(gBleFeatureNotSupported_c) であることが判明しました。 拡張広告を利用したいです。どうかサポートしてください。   よろしくお願いします!   Re: KW47 extended advertising こんにちは、 あなたの調子が良いといいのですが。 サンプルコードにどのような変更を加えましたか?アプリケーション内で拡張広告を設定するには、最初のステップはGap_SetExtAdvertisingParametersで拡張広告パラメータを設定し、Gap_SetExtAdvertisingDataを呼び出して広告データを設定することです。 セットアップ手順とパラメータの詳細については、こちらのガイドをご覧ください: 拡張広告 — MCUXpresso SDKドキュメント   お役に立てば幸いです! よろしくお願いします、 アナ・ソフィア。 Re: KW47 extended advertising こんにちは、 私が使っているSDKバージョンは26.06です。インポートされたルーティンはkw47loc_loc_reader_freertosです。 ルーチン内のgAppIsPeripheral_dのマクロ定義を1に修正し、同時にBluetoothLEHost_AppInit関数にBleApp_Start()を追加します。 他に何も変更されていません。 BluetoothLEHost_StartExtAdvertising の呼び出しの戻り値は 4(gBleFeatureNotSupported_c) であることが判明しました。   よろしくお願いします! Re: KW47 extended advertising こんにちは、 @wjw2026 さん。 拡張広告ガイドの手順を踏めたかどうか確認していただけますか?拡張広告のペリフェラル設定にはいくつかの必要なステップがあり、それらの設定を確認することで、観察している動作のトラブルシューティングに役立つかもしれません。 よろしくお願いします、 アナ・ソフィア。
記事全体を表示
Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware Hello NXP Team, I have purchased a board with the specified part number, and I noticed a discrepancy regarding the onboard QSPI flash capacity. MCIMX6ULL-EVK  The datasheet states that the board includes 256 MB QSPI flash. However, when I check the flash size from the operating system, it reports only 32 MB. To verify this, I downloaded the design files and checked the BOM. I also looked up the same flash device part number on DigiKey and Mouser, and both list it as 256 Mbit flash memory, which corresponds to 32 MB, not 256 MB. I purchased the board through the Element14 distributor. Could you please clarify whether: The datasheet contains a typo and should state 256 Mbit instead of 256 MB? Or is there another explanation for why the datasheet and the actual hardware appear to use different storage classifications? From my investigation, it appears that the installed flash device is 256 Mbit (32 MB) rather than 256 MB. I would appreciate your confirmation. Thank you. i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware You are right, I will report it to related team, it is 256Mbit, that means 32MB.
記事全体を表示
无法为 i.MX95 Neutron NPU 编译 YOLOv8/YOLO11 TFLite 模型 您好,NXP支持团队, 我们正在使用Neutron SDK v3.1.3在FRDM i.MX95平台上评估目标检测功能。并且无法生成与 NPU 兼容的模型。Neutron 变流器成功加载了模型,但报告称0 个算子映射到 Neutron NPU 。 环境 目标板:FRDM i.MX95 Neutron SDK:3.1.3 Ultralytics:已使用 YOLO11 和 YOLOv8 进行测试 eIQ 工具包:用于 ONNX 到 TFLite 的转换 型号:定制单类钉子检测器 训练司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 导出命令 $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml 我们还测试了另一种工作流程: 导出 PyTorch → ONNX 使用 NXP eIQ 工具包将 ONNX 转换为 INT8 TFLite 使用 Neutron SDK 编译时,两种工作流程都产生了相同的结果。   中子汇编 〜/下载/eiq-neutron-sdk-linux-3.1.3/bin/neutron-变流器--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   变流器输出 变流器报告: 导入后运算符:341 优化后的运算符数:367 已转换运算符:0 操作员转换率:0 / 367 中子图数量:0 警告: 警告:图中所有运算符均未映射到 Neutron。 警告:转换后的模型与输入模型相同,因为没有将任何算符映射到 Neutron。 警告:图表中包含不支持的 FLOAT 运算符!这会导致转化率低。 更多信息 我们观察到以下情况也存在同样的现象: YOLO11 YOLOv8 直接 Ultralytics TFLite 导出 ONNX → eIQ 工具包 → INT8 TFLite 所有生成的 TFLite 模型都导致 Neutron 编译器映射 0 个算符。 问题 Neutron 编译器是否正式支持 i.MX95 的 YOLOv8 或 YOLO11 目标检测模型? 对于目标平台为 i.MX95 NPU 的 YOLO 模型,是否有推荐的导出流程? 当前 Neutron SDK (v3.1.3) 是否存在任何已知限制?关于YOLO检测头? NXP 是否提供可在 i.MX95 NPU 上成功编译的 YOLOv8/YOLO11 参考模型? 启用运算符映射是否需要额外的编译器选项或预处理步骤? 我们非常希望获得任何与 i.MX95 Neutron NPU 兼容的指导、推荐工作流程或参考模型。 谢谢! Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 谢谢你的回复。​​ 我想咨询一下是否有标准程序可用于在IM X95板上进行模型的训练、导出和部署。​​​​​​​​​​​ 由于我们目前拥有ARA2 ,我们正在寻求充分利用其功能并定制我们的模型。我们将在NXP技术日上进行演示,如果您能在这方面提供帮助,我们将不胜感激。​​​​​​​​​​​ 感谢您的帮助。​​ Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在 imx95 主板上尝试了 eIQ 模型库中的 yolo8m 模型,使用了 LF 2026 Q2 版本镜像。内核版本为 6.18.20,使用 Neutron SDK 3.1.2,运行正常。     您可以先尝试以下方法: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so 更多信息请参阅 README 文件eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo 此外,您还可以附加转换/编译的模型和详细日志。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 根据变流器日志,首先要解决的问题是生成的 TFLite 模型仍然包含 FLOAT 运算符: 警告:图表中包含不受支持的浮点运算符! 对于 i.MX95 Neutron,中子变流器的输入必须是 TFLite 模型,其算符和量化格式与 Neutron 编译器兼容。具体来说,i.MX95 中子流需要量化的 TFLite 和对称的 int8 权重。如果模型在 Ultralytics 导出或 ONNX 到 TFLite 转换后仍然包含 FLOAT 运算符/张量,则变流器可能无法创建任何 Neutron 兼容的子图,这与报告的结果一致: 已转换运算符:0 中子图数量:0 YOLOv8 已在 i.MX95 上进行过一些流程的评估,但对于任意 Ultralytics 导出,不应假定完全端到端的 YOLOv8/YOLO11 卸载。根据导出的 TFLite 图,模型可能只有一部分会转换为 NeutronGraph,而不支持的操作符将保留在 CPU 上。因此,建议的下一步是检查/分析生成的 TFLite 模型并确认: 该图已完全量化。 没有浮动操作商。 权重是对称的int8, 输入/输出张量类型兼容,或者如果适用,可以使用 Neutron 变流器 uint8 到 int8 选项进行转换。 除非 SDK 确认支持确切的操作符,否则 YOLO 后处理(例如解码/NMS)将保留在 NPU 图之外。 另外,请确保板上的 Neutron 变流器版本和 Neutron 运行时/固件/委托来自同一个兼容的 SDK/电路板支持包 版本。 建议采用 NXP/eIQ 转换路径: PyTorch -> ONNX(静态输入形状) -> NXP/eIQ 量化(使用代表性校准数据) -> 量化后的 TFLite -> 中子变流器 --target imx95 如果模型具有 uint8 输入/输出张量,请同时进行以下测试: --将输入的 uint8 转换为 int8 --convert-outputs-uint8-to-int8 如果移除浮点运算符后,转换结果仍然显示 0 个已映射运算符,请分享: - 完整的 中子变流器 日志,如有详细/分析输出,请提供。 - TFLite 操作员列表, - 张量数据类型和量化参数, - FRDM i.MX95 板上确切的 电路板支持包/运行时 Neutron 代理/固件版本, - YOLO 检测头是否包含 NMS 或 TFLite 图中的其他后处理。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在我的测试中,我没有自己训练或导出模型。我使用了 eIQ 模型库中预先生成的 YOLOv8 模型,并验证了它在 i.MX95 平台上运行。 我实际使用的唯一命令是: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 以该模型为例: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite 对于定制模型,NXP 推荐的流程如下: PyTorch ↓ ONNX(静态输入形状) ↓ eIQ 工具包 ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ 量化 TFLite ↓ 中子变流器 --target imx95 由于您的模型报告: 纯文本 已转换运算符:0 中子图数量:0 警告:图表中包含不支持的 FLOAT 运算符! 我怀疑您生成的 TFLite 图在结构上与 eIQ 模型库参考模型不同。我首先建议做的是比较这两个型号的以下方面: 输入/输出张量类型(INT8 与 UINT8) 浮式经营者的存在 图内的解码/NMS层 Netron/TFLite 分析器报告的运营商列表 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 你好 我运行的是 ubuntu 24.04,但是 eiq_toolkit 仅适用于 20.04.03 版本。 如何使用 eiqToolkit 和使用 eIQ Toolkit 进行量化 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 请问您是如何将 yolov8m_full_integer_quant.tflite 转换为能够在 imx95 NPU 上运行的? 以下步骤和环境设置数据(主机)将对我们非常有帮助。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推荐的端到端工作流程 模型训练(PC) 使用您偏好的框架进行训练: Ultralytics YOLOv8 PyTorch Tensorflow ONNX原生工作流 对于目标检测,NXP 已经在 eIQ 模型库中提供了 YOLO 参考配方,包括 YOLOv8 目标检测模型。[github.com] ,[github.com] 示例: shell yolo 检测训练 \ model=yolov8n.pt \ data=dataset.yaml imgsz=640 \ epochs=100 ` 导出到 ONNX NXP 通常建议在量化和部署之前使用 ONNX 作为交换格式。 yolo 导出 \ model=best.pt \ format=onnx Neutron 启用演示文稿明确描述了基于以下流程的说明: 纯文本 PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ 中子变流器 而不是直接从训练工件中寻找部署目标。 使用 eIQ 工具包进行量化 Neutron 工作流程文档建议使用 eIQ Toolkit 量化工具: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c 输入:: `` 其次是: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite 显示更多行 该流程在 i.MX95 Neutron 实现材料中有明确记录。 为 i.MX95 Neutron NPU 编译 中子变流器 --target imx95 \ --输入 model_int8.tflite \ --输出 model_neutron.tflite Neutron 变流器创建 Neutron 特有的图分区,这些分区可以卸载到 NPU 上。 验证转化率 NPU 部署成功后,应报告类似以下内容: 转换的操作员数量 > 0 中子图数量 > 0 如果你看到: 已转换运算符:0 中子图数量:0 那么该模型就没有被NPU加速。 你目前的问题就属于这一类。 部署在 FRDM-i.MX95 上 使用 TensorFlow Lite 和 Neutron 委托运行: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 或 ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX 机器学习用户指南将Neutron Delegate定义为 i.MX95 TensorFlow Lite 模型的加速机制。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于 eIQ Toolkit 已在 Ubuntu 20.04 上验证过,因此最安全的方法是: Docker 在 Ubuntu 24.04 主机上运行 Ubuntu 20.04 容器: docker run -it --name eiq \ ubuntu:20.04 /bin/bash 然后,在容器内安装所需的依赖项和 eIQ Toolkit。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 使用 eIQ Toolkit (onnx2quant) 转换自定义 YOLOv8 ONNX 模型时,无法保留置信度输出。 概述 NXP团队您好, 我正在尝试使用 eIQ Toolkit 在 FRDM i.MX95 上部署自定义 YOLOv8 单类目标检测模型。 整个转换流程运行成功,但在 onnx2quant 之后,置信度输出全部变为零,而边界框输出仍然有效。 环境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX 运行时 1.21.1 - TensorFlow 2.21 - 中子变流器 3.1.3 - 目标:FRDM i.MX95(tflite_runtime 2.19 + Neutron delegate) 转换管道 1. 火车 yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. 导出 ONNX yolo export model=best.pt format=onnx opset=13 3. 验证 ONNX 输入:(1,3,640,640) 输出:(1,5,8400) ONNX 运行时推理: 置信度通道最大值 = 0.773 4. 生成校准数据集 形状:(1,3,640,640) 数据类型:float32 范围:0.0 - 1.0 5. 量化 onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx 同时测试了: onnx2quant 最佳.onnx -u 两者产生的结果相同。 6. 验证量化的 ONNX 输出:(1,5,8400) 边界框通道仍然有效。 信心: 最小值 = 0 最大值 = 0 平均值 = 0 解码检测结果 = 0 7. 转换为 TFLite 格式 onnx2tflite best_quant.onnx -o best.tflite 8. 为 Neutron 编译 neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite 编译成功。 操作员转化率:278 / 325 (85.5%) 已展开调查 已核实: • PyTorch 模型有效 • ONNX 导出工作 • ONNX 运行时推理功能正常 • 校准数据集正确 • 真实校准和随机校准产生相同的结果 • TFLite 重现量化的 ONNX 输出 • Neutron 可以重现 TFLite 的输出 该问题首次出现于以下情况: ONNX ↓ onnx2quant ↓ 量化 ONNX(置信度变为零) 补充观察 恩智浦参考模型: 输入:(1,640,640,3) INT8 输出:(1,84,8400) INT8 我转换后的模型: 输入:(1,3,640,640) FLOAT32 输出:(1,5,8400) FLOAT32 对于自定义 YOLOv8 模型,是否有推荐的导出或量化工作流程,能够保留置信度输出? 对于输出为 (1,5,8400) 的模型,这可能是 onnx2quant 的一个限制或错误吗? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 与AE团队讨论。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240 的端到端性能是否已经过评估?数据手册中提到了两个矢量核心,可以执行诸如 sigmoid 和 NMS 之类的后处理操作。编译器能否将 NMS 操作映射到向量核心?
記事全体を表示
S32K148はセキュアブート機能を備えているが、JTAGを無効にするとブートローダーが起動しない。 NXP様、こんにちは。 弊社のK148には、ブートローダーとアプリケーションパーティションの2つのパーティションがあります。アプリケーションパーティションには、JTAGを無効にする機能があります。アプリケーションでJTAGを無効にすると、リセット後にブートローダーが起動せず、チップが動作不能になります。調査の結果、ブートローダーは32KBで、アドレス0x00から0x8000の範囲であることが判明しました。JTAGを無効にするには、アドレス0x408に0xFFu 、0xFFu 、 0xFFu 、 0xFFu 、 0xFCu 、 0x7Fu 、 0xFFu 、 0xFFuを書き込む必要があり、これによりフラッシュメモリの内容が変更されます。リセット後、CSEcがブートローダーに対して異なるboot_mac値を計算してしまうため、チップが動作不能になります。NXPは、この問題を解決するための成熟したソリューションを提供していますでしょうか?よろしくお願いいたします。 Re: S32K148有secureboot功能,但是bootloader在jtag关闭后起不来 こんにちは、 @lukaszadrapa 上記のマニュアルによると、 BOOT_MACは一度だけ書き込まれる不可逆的な値です。この値を変更できる公式APIはありますか?もしあれば、そのAPIを提供していただけますか? Re: 晶振波形异常 御社のFS32K144HFT0MLHT MCを使用しています 水晶発振器は8MHzの受動型水晶発振器(AV08000009)ですが、波形が異常です。この波形は貴社製MCUにとって許容範囲内でしょうか?また、正常な動作に影響はありますか? Re: S32K148有secureboot功能,但是bootloader在jtag关闭后起不来 こんにちは@vurtual 一般的な方法は、デバッグインターフェースを製造時に無効にすることであり、アプリケーションから後から無効化するのではなく、その場合、このプロセスは単一の生産ステップで完了します:フラッシュ構成フィールド(FCF)を再プログラムしてデバッグポートを無効化し、正しいBOOT_MAC値をプロビジョニングするか(または次のリセット後にCSEcが自動的に計算できるようにします)。 製品ライフサイクルの後半でデバッグインターフェースを無効化する必要がある場合も可能です。しかし、FCFが再プログラムされると、セキュアブートの計算には変更されたFCFの内容が含まれるため、BOOT_MACも更新する必要があります。そうしないと、セキュアブートの検証が失敗します。 BOOT_MACは標準的なSHEメモリ更新プロトコルを用いて更新可能で、CSEcキーの更新と同じ方法で行えます。BOOT_MACを新しいFCFの内容に合わせて更新した後、デバッグポートを無効にした状態でセキュアブートが正しく動作するはずです。 よろしくお願いいたします。 ルーカス
記事全体を表示
PCF8563TSのライフサイクル状況と長期的な供給状況 こんにちは.... 現在、 PCF8563TS RTCを製品の一つに使用しており、その長期的なライフサイクル状況をよりよく理解したいと考えています。 過去には、私たちの製品は PCF8563BSをベースにしており、最終的にはエンド・オブ・ライフ(EOL)に達しました。その結果、別のパッケージへの移行のためにハードウェアの全面的な再設計を行い、追加のエンジニアリング作業、検証、製造コストが発生しました。 こうした過去の経験を踏まえ、私たちは以下の点について質問したいと思います。 PCF8563TSがEOL(販売終了)またはNRND(新製品化)に近づいている兆候はありますか? このデバイスの長期的な供給計画はありますか? NXPは今後の製品ライフサイクルやロードマップについて何かCAN情報を共有できますか? PCF8563TSで新製品をデザインするお客様におすすめはありますか? 今後の計画は変更される可能性があることは理解していますが、この装置の期待される寿命に関する指針があれば、デザイン上の判断を下し、将来の再設計リスクを減らすのに役立ちます。 再開まで今しばらくお待ちください。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 調べてみたところ、PCF8563TS $0.5のように在庫が多いチップでは、生産を止めるのは簡単ではありません。 Re: PCF8563TS Lifecycle Status and Long-Term Availability こんにちは、ビクターさん。 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 今後10〜15年間安定した供給を保証する長寿命プログラムの製品もあります。 長寿プログラム しかしPCF8563TSは長寿プログラムには含まれておらず、販売終了の通知や最終購入日はありません。お客様の要望次第です 敬具 アロンドラ 技術サポート NXPセミコンダクターズ
記事全体を表示
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.     You can try it firstly by: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores?
記事全体を表示
PN7221 fails to detect ISO 14443-3B We ported PN7221 in accordance with the document AN14880 PN7160/PN7220 - Android 16 porting guide. During testing, ISO 14443-3B (NfcB) cards cannot be detected. Moreover, after tapping such a card, the NFC function malfunctions and fails to recognize any cards. It is necessary to toggle NFC off and on again to restore normal operation. Relevant logs are attached below for your analysis. ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.516 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF Interface = Frame RF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Protocol = Unknown 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Mode = B Passive Poll 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 type=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.519 530 6385 D NxpNciX : len = 12 > 0000091D0000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.519 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.520 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.521 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.523 530 6384 D NxpNciR : len = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.523 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.525 530 6385 D NxpNciX : len = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.525 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.527 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.528 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB97166900000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.532 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:???? UNKNOWN SUBSTATE (18) 07-16 09:24:28.533 1599 6381 I libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... Re: PN7221 fails to detect ISO 14443-3B We've upgraded to version 3.2.5, but the test results remain unchanged. 07-17 01:13:52.157 533 542 D NxpHal : FW version found on the device = 0x30205 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Please update to 3.2.5, you can get the FW file by going: nfc-NXPNFCC_FW/InfraFW/pn7220 at master · NXP/nfc-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : FW version found on the device = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  which is the version of FW? if it low 3.2.5, please update to the newest, and test again. If still has question, please provide full log to us. Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Could you provide libnfc-nci.conf and libnfc-nxp.conf files?
記事全体を表示
27MHzリファレンス・デザインにおけるC16コンデンサ定格に関する質問MRF300AN こんにちは、NXPサポートチームの皆さん、 現在、MRF300AN 27MHzのリファレンスデザインをレビューしており、出力側のコンデンサC16について質問があります。 私が持っているBOM(例:Farnellのデータシート)によると、C16は39,000 pF(39 nF)/50Vチップコンデンサ(ATC部品200B393KT50XT)と指定されています。MRF300ANは50Vのドレイン電圧で動作し、出力段は高RFパワー(最大300W+)を処理するため、この位置で50V定格のコンデンサでは長期的な安定した動作には不十分ではないかと懸念しています。 私の質問は以下のとおりです。 BOMのC16の50V定格は正しいのでしょうか、それとも誤字かもしれませんか? この回路におけるC16の正確な役割は何ですか?それは出力整合回路の一部ですか?それとも直流阻止コンデンサですか?あるいはバイパス/デカップリングコンデンサですか? もし本当にRF出力経路にDCを遮断したりコンデンサを合わせているなら、電圧の過渡現象や定在波を処理するには、より高い電圧定格(例えば100V以上)の方が適切ではないでしょうか? この件についてご説明いただけると大変ありがたいです。お時間をいただき、サポートありがとうございます。 よろしくお願いいたします。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design こんにちは、フォンユチー 良い一日! 300Wという電力は、コンデンサにかかる電圧ストレスを直接決定するものではありません。 コンデンサの電圧定格は、そのコンデンサ両端の実際のRF電圧と比較し、アンプ出力電力と比較するのではありません。 C16は必ずしもRF出力電圧を完全に受信しているわけではありません。 リファレンス・デザインBOMによると、C16は電源デカップリング/RFバイパスネットワークに属しており、50 Ω出力コネクタを直接挟んでいたわけではありません この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。
記事全体を表示
DSP实现方式:微控制器或FPGA 大家好,我知道这个话题在这个子版块已经被反复讨论过了,但我只是想从这个领域的专家那里得到一些特定领域的建议。我想知道的是,如果我对通信领域的 DSP 应用感兴趣,并且想从事相关的实现工作,那么花时间学习微控制器编程是否值得?我是一名电子与计算机工程专业的本科生,所以我想知道我是否应该直接专注于FPGA,说实话,我对FPGA更感兴趣。我很困惑,因为我看到有人建议说,要使用现在越来越多地采用的片上系统 (SoC),确实需要具备嵌入式软件编程技能。 如果这个问题很重复,我真的非常抱歉!我一直没能找到关于此事的合适答案,现在我可能需要稍微调整一下优先事项。非常感谢您的建议! Re: DSP Implementation: Microcontrollers or FPGAs 你好@endros , 如果您主要对通信领域的 DSP 感兴趣,那么专注于 FPGA 绝对是值得的,特别是对于高吞吐量或实时实现而言。也就是说,掌握基本的嵌入式 C 技能仍然很有用,因为许多 SoC/FPGA 平台都涉及软件控制、驱动程序和系统集成。我会优先学习 FPGA/DSP 基础知识,但也会花足够的时间学习 MCU 编程,以便熟悉嵌入式工作流程。你不需要成为一名纯粹的嵌入式软件工程师,但也不应该完全忽视它。 希望对您有所帮助。 BR 塞莱斯特
記事全体を表示
I.MX6 VPUエンコーディング機能 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> カメラ画像ストリームからH.264へのエンコードを行うためのi.mx6 VPUの評価を行っています。 私はi.MX6でのストリームエンコーディングは全くの初心者なので、センサの選択に惹かれました。私はその点に関して少し疑問を持っています。 1. VPUがH.264エンコーディングでサポートする最大解像度はどれくらいですか? 2. H.264エンコーディングにおいて、最大解像度でサポートされる最大フレームレートはどれくらいですか? 3. VPUがH.264エンコーディングでサポートする入力カラースペースは何ですか? 4. 例えば640×480ピクセルの解像度が低い場合、H.264エンコードで1920×1080ピクセルと比べてより高いフレームレートを得られるのでしょうか? 5. フレームレートはビットレートによって制限されますか? 6.IPUからVPUへストリームをルーティングしてエンコードすることは可能ですか? ありがとうございます グナ グラフィックスとディスプレイ i.MX6Quad Linux マルチメディア Yocto Project Re: I.MX6 VPU Encoding Features こんにちは、アルトゥール 1920x1080 30FPSの動画をデコードしながら、同時に1920x1080 30FPSの動画をエンコードすることは可能ですか?また、この情報が真実であるかどうかについて、文書に明記されていないのでしょうか? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本当にありがとうございます Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.ホリソント解像度は1080ピクセルに制限されていますが、MJPEGのBPプロファイルでは最大8192x8192ピクセルまで画質が設定可能です。 2. ピクセル/秒と動作周波数の直接的な仕様はありません。さらに、VPUのスループットはエンコード処理とデコード処理で異なる。1つの1920x1080@30fpsストリームをエンコードし、1つの1920x1080@30fpsストリームと1つのD1@30fpsストリームをデコードすることができます。 アルトゥール Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> アルトゥール・ペトゥホフ、 ご回答ありがとうございます。 念のため確認ですが、VPUで1600 x 1200(UXGA)h264エンコーディングが@ 352Mhzでもできないということですか? VPUの動作周波数におけるスループットの計算方法は?266MHz動作時のスループットは約72,576,000ピクセル/秒だと読みました。これについて手伝ってもらえますか? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Q1.VPUがH.264エンコードでサポートする最大解像度はどれくらいですか? Q2.H.264エンコーディングにおいて、最大解像度でサポートされる最大フレームレートはどれくらいですか? A1-2。i.MX6シリーズプロセッサのビデオ処理ユニット(VPU)は 最大1920x1080@30fpsの解像度/フレームレートでビデオストリームをエンコード/デコードします。 Q3.H.264エンコーディングにおいて、VPUがサポートする入力カラースペースは何ですか? A3. サポートされている入力カラースペースは、MJPEG コーデックを除き YUV4:2:0 です。 4:2:0、4:2:2、2:2:4、4:4:4、4:0:0をサポートしています。 Q4.例えば640×480ピクセルの解像度が低い場合、H.264エンコードで1920×1080ピクセルと比べてより高いフレームレートを得られるのでしょうか? A4. はい。 Q5.フレームレートはビットレートによって制限されますか? A5. エンコードされたビデオストリームのビットレートのことでしょうか?もしそうなら、答えはこうです:フレームレートとビットレートの間に直接的な関係はなく、結果となるビットレートは主に使用されるコーデックとエンコードプロファイルに依存します。 Q6.IPUからVPUへストリームをルーティングしてエンコードすることは可能ですか? A6. はい、システムメモリ内のフレームバッファを使用すれば可能です。例えば、IPUはカメラでキャプチャしたフレームをダブルバッファ方式を用いてシステムメモリに保存し、その後VPUがそこからフレームを取り出してエンコードする。 すてきな一日を、 アルトゥール ----------------------------------------------------------------------------------------------------------------------- 注:この記事があなたの質問への回答になっている場合は、「正解」ボタンをクリックしてください。ありがとう! ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう。私はそれを使って遊び始めました。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 答えは教えられない。 http://www.chipsnmedia.com/ に連絡してみて。 調べた参考文献も答えは出ていません。 http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http %3A% 2F %2Fwww.chipsnmedia.com% 2Fsupport %2Fdown% 2Fcnm-codadx6-datashe… 船内で試してみることをおすすめします。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武、 もしそうなら、640 x 480 @ 90fpsで実現することは可能でしょうか? ありがとうございます グナ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> #1 最大ビットレートや最大クロック周波数は気にしません。 h264エンコードの場合、 1920*1080*30以下の通常の「幅*高さ*フレームレート」であれば問題ないと思います。 #2 i.MX プラットフォームにはDMAやキャッシュの整合性を扱う「物理メモリ 割り当てAPI」が必要です。 「IPU出力」と「VPU入力」が同じメモリと画像フォーマットを共有している場合、コピーや変換は不要です。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武、 ご返信ありがとうございます。 いくつか疑問があります。 1.4と5については、 制限が幅×高さ×fpsの場合、VPUがサポートする最大ビットレートはどれくらいですか?ドキュメントには記載されていませんでした。私の知る限り、VPUの動作速度は最大352MHzまで上がることがあります。 2. 6の場合、 SDMAはこれに使えますか?はいの場合、何か制限事項はありますか? ありがとうございます グナ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 略して: #1,2 1920x1080@30fps #3 YUV422(NV12)、YUV420 #4,5 制限値は「幅×高さ×フレームレート」だと思います。 #6 フォーマット変換かmemcpyが必要になるかもしれません。 詳細は以下をご覧ください。 http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…
記事全体を表示
IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) Hello NXP team, I need help upgrading IMX95LPD5EVK-19CM from the factory BSP to LF_v6.18.2-1.0.0 for eIQ Neutron NPU YOLO inference. UUU eMMC flashing fails on both Linux and Windows with different libusb errors at SDPS:boot. Details below. --- ## 1. Hardware | Item | Detail | |------|--------| | Board | IMX95LPD5EVK-19CM (i.MX 95 19×19 EVK, SOM + baseboard) | | Yocto machine / hostname | imx95-a1-19x19-lpddr5-evk | | Silicon | i.MX 95 A1 | | Storage | 64 GB eMMC (factory pre-flashed Linux) | | Power | 12 V on J5, SW4 ON | | Debug | J31 USB-C → host (serial, 115200) | | Flash port | J8 USB1 OTG USB-C → host | | Camera | Logitech C920 on J7 (/dev/video13) | --- ## 2. Software versions ### Current (factory eMMC — Linux boots normally) | Component | Version | |-----------|---------| | BSP | LF6.12.34_2.1.0 | | Kernel | 6.12.34-lts-next-gbe78e49cb433 | | Boot cmdline | root=/dev/mmcblk0p2 | | Neutron delegate | v1.0.0-be8bf399 | | libneutron_delegate.so | /usr/lib/libneutron_delegate.so | | Host converter (old) | eIQ Toolkit 1.17 / neutron-converter 2.1.3 | ### Target (downloaded, not yet flashed to eMMC) | Component | Version / file | |-----------|----------------| | BSP release | LF_v6.18.2-1.0.0 (SCR-6.18.2-1.0.0) | | Kernel (expected) | 6.18.2-1.0.0 | | Image package | LF_v6.18.2-1.0.0_images_IMX95 | | Boot image | imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all | | Rootfs | imx-image-full-imx95evk.wic (~11 GB) | | Neutron delegate (expected) | v1.0.0-7399a58e | | Host converter (ready on host) | eIQ Neutron SDK 3.0.1 (converter 3.0.1+0Xd5d7918e) | Reference: NXP forum engineer (Zhiming_Liu) validated YOLOv8m on i.MX95 with L6.18.2 + eIQ Neutron SDK 3.0.1 + delegate 7399a58e. --- ## 3. Application goal USB webcam person detection with YOLO (v8n / v11n) using: - INT8 TFLite export (Ultralytics) - neutron-converter --target imx95 - tflite_runtime + libneutron_delegate.so on board On current BSP (6.12.34): - NXP forum yolov8m_full_integer_quant_converted.tflite → SEGFAULT on NPU invoke (exit 139) - Custom yolov8n_neutron.tflite → invoke OK but 0 person detections - Headless backbone on NPU → constant garbage output (~1.13); CPU split pipeline works (56–90% detections) Conclusion: need L6.18.2 BSP on eMMC before NPU models converted with SDK 3.0.1 can be validated. --- ## 4. Host setup | Host | UUU version | Path | |------|-------------|------| | Ubuntu 24.04 (x86_64) | libuuu_1.5.243-0-g230f1b1 | /usr/local/bin/uuu | | Windows 10/11 | libuuu_1.5.243-0-g230f1b1 | uuu.exe (from mfgtools uuu_1.5.243 release) | Image directory on both hosts: LF_v6.18.2-1.0.0_images_IMX95 --- ## 5. Boot switch SW7 (per IMX95LPD5EVK-19CM QSG, 1=ON 0=OFF) | Mode | SW7-1 | SW7-2 | SW7-3 | SW7-4 | |------|-------|-------|-------|-------| | Serial Download (UUU) | 1 | 0 | 0 | 1 | | eMMC boot (normal) | 1 | 0 | 1 | 0 | eMMC boot (SW7=1010) works normally. Full power cycle performed before each SW7 change. --- ## 6. Flash procedure (eMMC via UUU) Board preparation (same for Linux and Windows): - SW7 = 1001 (Serial Download) - J8 (USB1 OTG) connected to host PC (not J31) - J31 connected for optional serial console - J5 12 V power connected - Board powered ON when uuu displays "Wait for Known USB Device" Command: uuu -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all imx-image-full-imx95evk.wic (Linux: sudo uuu ... | Windows: uuu.exe ... from image directory) --- ## 7. UUU errors — Linux (Ubuntu 24.04) sudo /usr/local/bin/uuu -b emmc_all \ imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all \ imx-image-full-imx95evk.wic Output: uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Success 0 Failure 1 1:6-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all ... Notes: - lsusb briefly shows NXP USB device (1fc9:015d) in SDP mode - uuu sometimes prints "New USB Device Attached" then fails at SDPS: boot - Without sudo: permission denied (errno=13) - eMMC was not modified (flash did not complete) --- ## 8. UUU errors — Windows Host: Windows 10/11, PowerShell, uuu.exe 1.5.243 Working directory: C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95 ### Attempt — flash_all (expected correct boot image) PS C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95> & '..\uuu (2).exe' -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all imx-image-full-imx95evk.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Success 0 Failure 1 1:3-E3C50910 1/1 [HID(W): LIBUSB_ERROR_PIPE (-9)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all ... Summary of USB errors across hosts: | Host | Boot image | libusb error | |------|------------|--------------| | Ubuntu 24.04 | flash_all | LIBUSB_ERROR_NO_DEVICE (-4) | | Windows | flash_all | LIBUSB_ERROR_PIPE (-9) | All failures occur at the same step: SDPS: boot (before eMMC write progress). --- ## 9. What works today - SW7=1010 → boots factory eMMC Linux (6.12.34) normally - SSH over eth0 works - USB webcam (/dev/video13) detected - libneutron_delegate.so present (be8bf399) - CPU-side inference validated; NPU output incorrect on current BSP --- ## 10. Questions for NXP 1. For SDPS:boot failures with uuu 1.5.243 on IMX95LPD5EVK-19CM (A1), device 1fc9:015d, SW7=1001, J8 — what causes LIBUSB_ERROR_NO_DEVICE (-4) on Linux vs LIBUSB_ERROR_PIPE (-9) / LIBUSB_ERROR_IO (-1) on Windows? 2. Are there known uuu 1.5.243 + IMX95 A1 compatibility requirements (driver, WinUSB/Zadig on Windows, udev rules on Linux)? 3. Confirm imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all + imx-image-full-imx95evk.wic is the correct pair for IMX95LPD5EVK-19CM eMMC flash (not sd-ecc unless ECC RAM). 4. Any known Neutron delegate differences between be8bf399 (6.12.34) and 7399a58e (6.18.2) affecting YOLOv8 INT8 models? 5. Is there an alternative supported method to flash L6.18.2 to eMMC if UUU USB path fails on both Linux and Windows? --- ## 11. Logs available on request - Full uuu verbose log: uuu -v -b emmc_all ... (Linux and Windows) - Host lsusb / Device Manager / dmesg when board enters SDP mode - Serial console log (factory eMMC boot — working) - Board: uname -r, strings libneutron_delegate.so, NPU test results on 6.12.34 Thank you for guidance on completing the eMMC upgrade to L6.18.2-1.0.0 for Neutron NPU development. Best regards Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) The A1 silicon of the i.MX 95 is no longer supported from our latest BSPs, 6.12.34 seems to be last one supporting A1. There is no workaround, you can't make the latest BSP work on A1 silicon, you need to upgrade your EVK with a new daughter card. The A1 silicon card is blue, the B0 silicon card is green. I didn't test a UUU download onto an old EVK using the 6.18.2 .wic image, but I expect that it fails the same way as it fails on your side. I'll do this in the next days. You could do a test with an SD-Card, program the .wic image on your PC to an SD-Card and try to run it on your EVK with boot mode set to SD-Card. Regards, Bernhard. Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) Hello, Thanks for response. i have another query regrading same board. I am trying to run an M7 application on IMX95LPD5EVK-19 following AN14748, but I cannot flash flash.bin with UUU. The board is detected briefly, then SDPS boot fails immediately. Hardware: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) Boot switch (SW7[1:4]): 1001 (Serial Download) Target: eMMC Host: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 SDKs tried (MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 Both produce the same result. Command: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   Error: Success 0 Failure 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   Steps followed (per AN14748): Set SW7 = 1001 with board powered off Connect USB to host Run sudo uuu -b emmc flash.bin Power-cycle board Fails at SDPS boot every time Questions: Which MCUXpresso SDK version is validated for IMX95LPD5BB-19 REV A1 M7 flashing? Is build target imx95-a1-19x19-lpddr5-evk correct for this hardware? Any known UUU issues or extra steps beyond AN14748 for this board revision? Should I use -b emmc or -b sd first, and which USB port should be used?
記事全体を表示
S32N55: 高速ウェイクアップ ブート用の BLOB イメージを構築する方法。 こんにちは、チームの皆さん ご存知のとおり、S32N55 は Fast Wake-up Boot をサポートしています。 Full Wake-up Boot と同じ形式を使用して BLOB イメージをビルディングしようとしましたが、ブート プロセスが失敗しました。 Fast Wake-up Boot 用の BLOB イメージを正しく構築する方法を教えてください。 ご回答をお待ちしています。 よろしくお願いいたします。 唐生。 FSS_FW 優先度: 中 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん チームがこのCASEを引き受け、できるだけ早く回答を提供します。 よろしくお願いします、 ラドゥ Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @RaduBragaさん このチケットがクローズされていることに気づきました。進捗状況について何か最新情報はありますか?   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 私はこのCASEを引き継ぎ、できるだけ早く返答をいたします。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 直接お客様を支援される場合は、以下の書類をご提供ください: BSSM契約:あり/なし 顧客会社*: プロジェクト名*: カスタマーコンタクトポイント*(氏名およびメールアドレス): ソフトウェアおよびハードウェア情報: SWパッケージ情報*: ハードウェア*(ボード/チップセット/プラットフォーム) ソフトウェアバージョン*: *必須 このケースの開発チームとはまだ協力しています よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 このケースは特定の顧客やプロジェクトに縛られていません。しかし、FUTURE的に同様の質問に直面する可能性があると考えており、このリクエストを出したのです。   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 詳しい情報をありがとうございます。私はこの事件に取り組んでおり、できるだけ早く答えを提供いたします! よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん ブロブ画像を作ろうとした際に実際に踏んだ手順を教えていただけると助かります。そうすれば問題点を特定しやすくなると思います。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 以下に、テストの詳細な手順を示します。   1. AOSRAMメモリ領域内に小さなFSSイメージを構築しました(IVTヘッダーは予約済み)。このイメージにはmain.cのwhileループのみが含まれています。 2. FSSファームウェアイメージを作成する際、FRBしきい値レジスタを入力する必要がありますか?もしそうなら、どうやって埋めるか、あるいは特別なものを考える必要があります。 3. IVTツールでIVTブロブイメージを構築し、開始アドレスを0x24800000とする。 4. IVTブロブイメージをフラッシュメモリの0xD00000に書き込みます。 5. システムがスリープ状態に入る前に、IVTブロブイメージをAOSRAMにコピーし、FSS_WKUP0のWKPUモードを高速ウェイクアップモードとして構成します。 5. FSS_WAKUP0 を介してシステムイメージを起動します。 FSSは while(1) ループに到達できませんでした。ウェイクアップの際に高速ウェイクアップではなく、リセットイベントがトリガーされたようです。   サポートありがとうございます!   よろしくお願いいたします。 唐生。
記事全体を表示