Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
MPC574xP BCTRL こんにちは: 私のお客様はMPC5741Pを車載ESCのアプリケーションに使っています。 現在、エンドOEMからBCTRLピンの特性(電圧領域など)について問い合わせを受けている。 確認と確認を手伝ってもらえますか?ありがとう。 下は波形で、三角形で、OEMからMCU側からベースコントロール出力ピンのCap.デカップルを追加してほしいと依頼されました。 Re: MPC574xP BCTRL データシートでは異なるトランジスタを推奨しており、以下の通りです。 また、適切にバイパス/分離する必要がある。VDD_LV_CORに特に注意してください。
記事全体を表示
yolov11n、yolov8n、yolov5nuモデルでi.MX95 NPUを使用しても出力が出ません   [i.MX95 NPU]YOLOv5n/v8n/v11n Neutron変換モデルは動作しますが検出なし(出力ゼロ) 問題の説明 私は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の導入に関する作業手順書などがあれば、大変ありがたいです。   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 ご回答ありがとうございます。 私のハードウェアプラットフォームについて誤解があるのではないかと思います。私の問題はi.MX91とは関係ありません。 私は以下のプラットフォームを使っています: 基板:i.MX95 19x19 LPDDR5 EVK(IMX95LPD5EVK-19CM、A1リビジョン) ボードクイックスタートガイド: https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK: MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) あなたが共有したガイドはi.MX91向けのようですが、私の質問はi.MX95 Neutron NPUでのYOLO展開についてです。 オリジナルのINT8 TFLiteモデル(YOLOv5nu、YOLOv8n、YOLOv11n)はCortex-A55 CPU上で正しく動作し、有効な検出結果を生み出します。しかし、同じモデルをMCU_SDK_25.09.00+Linux_6.12.34_2.1.0に含まれるNeutron コンバータでまとめた後、推論はNPU上で実行時エラーなく正常に実行されるが、出力テンソルには有効な検出結果が含まれない。 調査を容易にするために、すでに元の投稿に以下のファイルを添付しています: * オリジナルのINT8量子化されたTFLiteモデル。 * YOLOv8nおよびYOLOv11n向けの中性子変換TFLiteモデル。 * 問題を再現するために使えるPython推論スクリプト。 これらは元の事前学習済みUltralyticsモデルをTFLiteに変換したものなので、標準のCOCOクラス名を提供されたスクリプトで直接使用できます。追加の修正なしでi.MX95プラットフォーム上で同じ動作を再現できるはずです。 添付ファイルを使って問題を再現していただけるとありがたいです。また、これがi.MX95の現行Neutron SDKの既知の制限か、あるいは問題なのか教えていただけると助かります。 ありがとう。 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは@vijayranaACL。 NXPサポートまでご連絡いただきありがとうございます。 このガイドを参照してください。 お客様が使用されているのはi.MX91 A1シリコンリビジョンであるため、A1は主に評価および開発目的を意図した初期のシリコンリビジョンであり、一部の機能が正しく動作しない可能性があります。 そのため、テストおよび検証作業には、i.MX91 B0シリコンリビジョンを使用することをお勧めします。このガイドはB0シリコン版を用いて作成・検証されたため、文書化された挙動と結果はその改訂版に基づいています。 可能であれば、どのシリコンリビジョンを使っているか、そして比較のためにB0デバイスにアクセスできるかを確認してください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 すみません、私の入力ミスでした。 私が言及していたのはi.MX95のことです。i.MX91にはNPUが搭載されていないからです。 モデル変換には以下のコマンドを試してみることをおすすめします: .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt Neutron SDKのドキュメントによると、コンバータはi.MX95のようなNeutron-Sターゲットに対してデターミニスティックではないことに注意が必要です。変換プロセスはマルチスレッド制約付きプログラミングソルバーに依存しているため、同じモデル上でコンバータを実行する場合、特にTCMメモリ割り当てや生成されたマイクロコードに関してわずかに異なる結果が生じることがあります。 複数の最適解が存在する可能性があるため、異なるソルバースレッドが各変換時に異なる有効な解に収束することがあります。これらの解は内部的に異なる場合がありますが、すべてコンバーターによって正しく最適化されています。ほとんどの場合、これらの違いは機能性や性能に大きな影響を与えることはありません。 挙動、性能、精度にばらつきが見られた場合は、モデルを複数回変換して結果を比較することをお勧めします。デターミニスティックな振る舞いを強制する方法は存在しますが、通常は変換時間が大幅に長くなり、厳密に必要でない限り推奨されません。 検査結果をお知らせください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 i.MX 95(i.MX 91ではない)に関する説明と、使用に関する推奨事項をありがとうございます。 --最適化レベル OOpt。 現在のセットアップであなたの提案されたコマンドに従おうとしましたが、Neutron-コンバーターとボードBSPを組み合わせたところ --optimization-level は利用できません 利用できません 。 現在の環境 コンポーネントバージョン ボード IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next) Neutron 代表乗船中 v1.0.0-be8bf399 ホストコンバータ eIQツールキット 1.17 → Neutron-converter 2.1.3+0Xaf140cf5 コンバーターBSPタグ MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 このコンバーターでは、 中性子コンバーター――help does not list ―最適化レベル。 実際に実行するコマンド Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 デバッグには、以下のツールも使用します。 Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 \ --詳細表示 当社のコンバーター(2.1.3)で利用可能なフラグ 主なオプション  - ヘルプ: - 入力、  - 出力、  - ターゲット --合一Neutronグラフ --入力値をuint8からint8に変換、 --出力をuint8からint8に変換 --ダンプ統計、 --ダンプグラフ、 --詳細表示 --入力テンソル間のインクルード、 --入力テンソル間の除外 --ターゲットを表示、 --カーネルの種類を表示 --最適化レベル 存在しません このビルドでは。 これまでの検査結果 モデルNPUの挙動 YOLOv8n Neutron (我々の変換) 呼び出しOKですが 検出数:0 YOLOv8n ヘッドレスバックボーン NPU出力 定数(約1.13) ヘッドレスCPUバックボーン+CPUヘッド 検出は正常です — パイプラインのロジックは正しい 質問 最適化レベルのOOpt は 2.1.3 よりも新しいNeutronコンバーターでしかサポートされていないのでしょうか? 推奨される変換コマンドは何ですか? LF6.12.34 / imx95 いつ OOpt 利用できませんか? Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 B0シリコンを搭載したi.MX95 EVKであなたのコードをテストしましたが、こちら側では問題なく正常に動作しているようです。 person_detect.pyアプリケーションを使うと、モデルは正常に読み込まれ、Neutronデリゲートは正しく初期化され、アプリケーションは予想通りの推論を実行します。テスト中、安定した物体検出と、約13~14 FPSの持続的なパフォーマンスを確認しました。ログはまた、Neutron delegateがアクティブであり、モデルがNPU加速で正しく動作していることも確認しています。 これらの結果に基づき、B0シリコンリビジョンへの移行を推奨します。A0およびA1シリコン版は主に評価およびベータテスト目的でリリースされており、B0ほどのソフトウェアサポートや検証レベルが整っていません。初期の改訂版以降、いくつかの機能追加や修正が行われており、それがお客様が経験されている動作の原因となっている可能性があります。 私のテストログの関連部分を以下に示します。 root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# 同じアプリケーションとモデルがB0シリコン上で正常に動作するため、問題はアプリケーション自体ではなくシリコンリビジョンに関連している可能性があるため、さらなるデバッグを続ける前にB0デバイスでテストを繰り返し行うことをお勧めします。 よろしくお願いします、 チャビラ
記事全体を表示
Clarification on Debian security repositories for NXP Debian Linux SDK on i.MX8MP Hello NXP team, We are using the NXP Debian Linux SDK on an i.MX8MP-based custom board. According to UG10155 Debian Linux SDK User Guide, our understanding is that the SDK is Debian-based: the RootFS mainly uses standard Debian .deb packages, while NXP / board-specific components and configurations are integrated by the SDK. We also referred to the NXP Community article “Debian 12 Installation Guide for iMX8MM, iMX8MP, iMX8MN and iMX93”. In that article, the apt configuration example includes Debian security and update repositories for Debian 12 / bookworm. On our current Debian 13 / trixie-based system, /etc/apt/sources.list only contains the following entry: deb http://deb.debian.org/debian trixie main contrib We would like to clarify the expected security update model for the NXP Debian Linux SDK. Could you please help confirm the following points? 1. For the NXP Debian Linux SDK based on Debian 13 / trixie, is the current APT source configuration expected, or is it recommended to also add the Debian security and update repositories? For example: deb http://deb.debian.org/debian trixie main contrib deb http://deb.debian.org/debian trixie-updates main contrib deb http://security.debian.org/ trixie-security main contrib 2. For NXP / BSP / board-specific components, such as the kernel, U-Boot, ATF, OP-TEE, DTB, peripheral firmware, and NXP-specific driver components, what is the recommended security update procedure? Does NXP provide security advisories, patches, or SDK updates for these components? We would like to confirm this so that we can provide accurate security maintenance guidance to our customer. Thank you. Linux Re: Clarification on Debian security repositories for NXP Debian Linux SDK on i.MX8MP Hi @Leo_dev  Currently, the SDK defaults to only including “trixie main contrib,” which is normal (for evaluation and guided installation), but this is not the final production configuration. If you need, you can use below sources. deb http://deb.debian.org/debian trixie main contrib deb http://deb.debian.org/debian trixie-updates main contrib deb http://security.debian.org/debian-security trixie-security main contrib For components provided by NXP, you can update to the latest version by modifying the source code tag in flexbuild individually. Best Regards, Zhiming
記事全体を表示
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.      
記事全体を表示
i.MX RT1010 フラッシュの問題 カスタムボードで@i.MX RT1010を使っていて、フラッシュの問題に直面しています。 すべての電源レールは安定しており、仕様を満たしています。 リセットピンは安定しています(電源投入後HIGH)。 デバッガーはターゲットを検出するが、フラッシュ書き込みは必ず失敗する。 既にハードウェアのショートやはんだ付け不良がないか確認済みです。 開発ボード Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123。 より良くサポートするために、次の情報を教えてもらえますか? -RT1010-EVKと同じ外部フラッシュ機器を使っていますか?もしなければ、カスタムボードに使われているフラッシュデバイスの部品番号を教えていただけますか? -どの画像をプログラムしようとしているのですか?SDKの例ですか、それともご自社のカスタムアプリケーションですか? -デバイスのプログラミングにはどのツールを使用していますか?例えばMCUxpresso IDEやSecure Provisioning Toolなどはどうでしょうか? -JTAGかSWDで繋がっていますか? もし他に役立ちそうな詳細があれば、遠慮なくお知らせください。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123 さん、 UARTインターフェースを通じてデバイスに接続できるか確認していただけますか?もしそうなら、Secure Provisioning Tool ユーザーガイド v26.03のセクション6.15.2「RT10xx/RT116x/RT117xデバイスの基板接続」に記載されている手順に従い、結果を教えていただけると助かります。これにより、問題がSWD接続に関連しているのか、それとも別のハードウェアの問題なのかを判断するのに役立ちます。 Secure Provisioning Toolから「Help → User Guide」から直接ユーザーガイドにアクセスできます。 さらに、ハードウェア開発ガイドの第5章「デバッグとプログラミング」の復習 MIMXRT1010 プロセッサをおすすめします。この章では、ハードウェア設計の検証や信頼性の高いデバッグ動作の確保に役立つデバッグコネクタ実装に関するいくつかの推奨事項やベストプラクティスを提供します。 電源投入時に測定したブートモードピンとブート構成ピンの状態はどうなっていますか?彼らは安定していますか? 最後に、パワーアップシーケンスのオシロスコープキャプチャを提供してもらえますか?これにより、電源投入タイミングと初期化シーケンスが正しく実行されていることを確認できます。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、ハビブさん。 ご返信ありがとうございます。 詳細は下記をご覧ください。 外部フラッシュ:カスタムボードにはAT25SF128A-SHB-T QSPI NORフラッシュを使用しています。EVKと同じです。 画像: evkmimxrt1010_igpio_input_interrupt SDKの例 をプログラムしようとしています 。 プログラミング ツール: SEGGER J-Link Commander V9.56およびSEGGER J-Flash Lite V9.56 。 デバッグインターフェース:JTAGで、RT1010-EVKと同じインターフェースを使用します。 参考のために画像も添付しました。 すべての電源シーケンスリセットラインは正常に動作しています。 Re: i.MX RT1011 Flashing Issue こんにちは、ハビビさん、 私が使用しているセキュアプロビジョニングツールの参考画像をいくつか添付しました。 JTAGとUARTの両方のインターフェースを使っていますが、下のエラーログに示されているように 「接続、電源、ISPモードへのリセットを確認」 というメッセージが出続けます。 この問題のトラブルシューティングの次のステップについてアドバイスをいただけますか? セキュアなプロビジョニングプロセスにおいて、従うべき特定の手順はありますか?また、これらの手順を進める前に、実施しておくべきハードウェアのチェックはありますか? サポートにあらかじめ感謝いたします。 Re: i.MX RT1011 Flashing Issue こんにちは、 @keerthisri123。 このThreadは公開されているので、よりプライベートなコミュニケーションチャネルで調査を続け、設計図を安全に確認できるようにサポート チケット を開いていただけませんか?これにより、問題のさらなる分析が可能になり、ハードウェア接続に関する潜在的な問題を排除することができます。 チケットを開く際は、この投稿を参照して私の名前をお知らせください。引き続きサポートいたします。 初期レビューを円滑に進めるため、基板の回路図一式を添付してください。特に以下の点にご注意ください。 -ブートモードピンとブート構成ピン。 外部フラッシュ接続。 -コアとデバッグインターフェース接続。 電源回路。 -クロック接続。 -電源投入シーケンス、および電源投入中のブートモードピンとブート構成ピンの状態をオシロスコープでキャプチャします。 BR ハビブ
記事全体を表示
关于NXP Debian Linux SDK在i.MX8MP上的Debian网络安全存储库的说明 您好,NXP团队, 我们正在基于 i.MX8MP 的定制板上使用 NXP Debian Linux SDK。 根据 UG10155 Debian Linux SDK 用户指南,我们理解该 SDK 基于 Debian:根文件系统主要使用标准的 Debian .deb 文件。代码包,软件包,而 NXP / 板-specific 元器件和配置则由 SDK 集成。 我们还参考了 NXP 社区文章“iMX8MM、iMX8MP、iMX8MN 和 iMX93 的 Debian 12 安装指南”。在那篇文章中,apt 配置示例包括 Debian 12 / bookworm 的 Debian 安全和更新存储库。 在我们当前基于 Debian 13 / trixie 的系统中,/etc/apt/sources.list 仅包含以下条目: deb http://deb.debian.org/debiantrixie 主要贡献 我们想澄清一下 NXP Debian Linux SDK 的预期网络安全更新模型。 请您帮忙确认以下几点? 1.对于基于 Debian 13 / trixie 的 NXP Debian Linux SDK,当前的 APT 源配置是否符合预期,还是建议同时添加 Debian 安全和更新存储库? 例如: deb http://deb.debian.org/debiantrixie 主要贡献 deb http://deb.debian.org/debiantrixie-updates 主要贡献 deb http://security.debian.org/trixie-网络安全 主要贡献 2. 对于 NXP / 电路板支持包 / 板级特定组件,例如内核、U-Boot、ATF、OP-TEE、DTB、外围固件和 NXP 特定驱动程序组件,推荐的安全更新程序是什么?NXP 是否为这些元器件提供网络安全公告、补丁或 SDK 更新? 我们希望确认这一点,以便能够为客户提供准确的**网络安全**维护指导。 谢谢! Linux Re: Clarification on Debian security repositories for NXP Debian Linux SDK on i.MX8MP 嗨@Leo_dev 目前,SDK 默认只包含“trixie main contrib”,这很正常(用于评估和引导安装),但这并不是最终的生产配置。如有需要,您可以使用以下资源。 deb http://deb.debian.org/debian trixie main contrib deb http://deb.debian.org/debian trixie-updates main contrib deb http://security.debian.org/debian-security trixie-security main contrib 对于 NXP 提供的元器件,您可以通过在 flexbuild 中单独修改源代码标签来更新到最新版本。 此致, 志明
記事全体を表示
S12XシリアルMCU、コードの開始アドレスを知る方法 今はCAN起動デモを手に入れました。S19ファイルを解析し、データとオフセットアドレスをS9S12G64に送信できます。MCUはマスターコンピュータが送るアドレスを指定するだけでフラッシュを書き込めます。アプリコードの開始アドレスを知る必要があります。アプリプロジェクトのprmファイルがありますが、開始アドレスを取得するにはどうすればよいでしょうか? Re: S12X serial MCU ,how to know the Code's START ADDRESS ここにアプリとブートコードがあります Re: S12X serial MCU ,how to know the Code's START ADDRESS こんにちは@李乐 参照のためにMAPファイルかS19ファイルを送ってもらえますか?ありがとう。 BR アリス
記事全体を表示
i.MX RT1010 刷机问题 我正在使用定制板上的 @ i.MX RT1010 ,遇到了刷机问题。 所有电源轨均稳定且符合规格。 RESET引脚稳定(上电后为高电平)。 调试器可以检测到目标设备,但烧录总是失败。 我已经检查过硬件是否存在短路和焊接问题。 开发板 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 , 为了更好地为您提供支持,您能否提供以下信息? -您使用的外置闪光灯设备与RT1010-EVK相同吗?如果没有,请问您能否提供您定制板上使用的闪存设备的零件编号? -您尝试对哪张图片进行编程?这是一个 SDK 示例还是您自己的自定义应用程序? -您使用哪种工具来对设备进行编程?例如 MCUxpresso IDE、安全配置工具等? -您是通过 JTAG 还是 SWD 连接? 如果您认为还有其他细节可能有所帮助,请随时告诉我。 BR 哈比卜 Re: i.MX RT1010 Flashing Issue 你好,哈比卜, 感谢您的反馈, 详情如下: 外部闪存:我的定制板上使用的是AT25SF128A-SHB-T QSPI 或非 闪存,与 EVK 相同。 图片:我正在尝试对evkmimxrt1010_igpio_input_interrupt SDK 示例进行编程。 编程工具: SEGGER J-Link Commander V9.56和SEGGER J-Flash Lite V9.56 。 调试接口: JTAG ,使用与 RT1010-EVK 相同的接口。 图片也附在后面供您参考 所有电源时序 RESET 线均正常工作 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 , 请问您是否能够通过 UART 接口连接到您的设备?如果是这样,请您按照安全配置工具用户指南 v26.03 中的 6.15.2 节“连接 RT10xx/RT116x/RT117x 设备的板”中描述的步骤进行操作,并告诉我您的结果?这将有助于确定问题是与SWD连接有关,还是可能存在其他硬件问题。 您可以通过导航至“帮助”→“用户指南”,直接从安全配置工具访问用户指南。 此外,我建议复习MIMXRT1010 处理器硬件开发指南的第 5 章“调试和编程”。本章提供了一些关于调试连接器实现的建议和最佳实践,可以帮助您验证硬件设计并确保可靠的调试操作。 上电时,启动模式引脚和启动配置引脚的状态如何?它们稳定吗? 最后,能否请您提供上电过程的示波器波形图?这将有助于验证上电时序和初始化顺序是否正确执行。 BR 哈比卜 Re: i.MX RT1011 Flashing Issue 嗨,哈比比, 我附上了一些参考图片,展示了我正在使用的安全配置工具。 我同时使用了 JTAG 和 UART 接口,但仍然收到“检查连接、电源并重置为 ISP 模式”的消息,如下面的错误日志所示。 请问您能否指导我下一步该如何排查这个问题? 在安全配置过程中,我应该遵循哪些具体步骤?另外,在执行这些步骤之前,是否需要完成任何硬件检查? 感谢您提前给予的支持。 Re: i.MX RT1011 Flashing Issue 你好@keerthisri123 , 由于本帖是公开的,能否请您提交一个支持工单,以便我们可以通过更私密的沟通渠道继续调查并安全地查看您的原理图?这将有助于进一步分析问题,并排除任何潜在的硬件连接问题。 提交工单时,请随时引用此帖并提及我的名字,以便我继续为您提供帮助。 为了便于进行初步审核,请提供完整的电路板原理图,尤其要注意以下方面: -启动模式引脚和启动配置引脚。 -外部闪存连接。 -核心和调试接口连接。 -电源电路。 -时钟连接。 -使用示波器捕获上电序列以及上电期间启动模式引脚和启动配置引脚的状态。 BR 哈比卜
記事全体を表示
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。 よろしくお願いいたします。 エドゥアルド。
記事全体を表示
S12X 串行 MCU,如何知道代码的起始地址 现在我有一个 Can 启动 Demo,它可以分析 S19 文件并将数据和偏移地址发送到 S9S12G64,MCU 只需要将数据写入主计算机发送的指定地址即可。我需要知道APP代码的起始地址,这里有一个app项目的prm文件,如何获取起始地址? Re: S12X serial MCU ,how to know the Code's START ADDRESS 你好@李乐 能否请您提供 MAP 文件或 S19 文件以供参考?谢谢。 BR 爱丽丝 Re: S12X serial MCU ,how to know the Code's START ADDRESS 以下是应用程序和启动代码
記事全体を表示
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.      
記事全体を表示
NAFE13388 水晶の仕様 RIOP RevB2では、NAFE13388 XTAL(X1、18.432 MHz)にどの水晶発振器仕様(ppm/負荷)を使用していますか? Re: NAFE13388 crystal spec こんにちは、 部品番号: ECS-184-12-33Q-JES-TR PPM:20 PPM 負荷: 12 pF これがお役に立てば幸いです。
記事全体を表示
我能否使用任意一个 GPIO 引脚作为中断输入信号,并使其在边沿检测模式下工作? 你好, 因为 6 个专用 IRQ(0~5) 引脚对我来说不够用,我需要其他 GPIO 引脚作为中断输入信号。所以,我有以下两个问题: 1. 是否可以将任意 GPIO 用作中断信号输入,并使其工作在边沿检测模式下? 2. 如果上述第 1 题的答案是肯定的,那么专用 IRQ 和 GPIO 之间有什么区别?或许响应优先级更高? 提前感谢! 顺祝商祺! 杰森 Re: Could I use any GPIO pin as interrupt input signal which worked at edge detection mode? 您好, 这个问题与LS1021A有关。欢迎任何回复! 顺祝商祺! 杰森 Re: Could I use any GPIO pin as interrupt input signal which worked at edge detection mode? 是的,只要引脚在您的电路板配置中实际被复用/用作 GPIO 输入,LS1021A GPIO 就可以用作中断输入,包括边沿检测模式。 GPIO 作为边沿中断输入 GPIO 块具有中断控制/状态/掩码寄存器:GPIER、GPIMR 和 GPICR;GPICR 配置事件检测,包括边沿触发行为,GPIO 中断逻辑向系统输出合并的 gpio_int 请求。对于每个 GPIO 端口线,EDn 位选择中断是在任何状态变化时产生还是在高到低转换时产生。因此,GPIO 中断输入是受支持的,但请注意,文档中记录的边沿选择与完全独立的上升/下降/双边沿选择器不同:引用的模式是“任何变化”或“高到低”。 专用的IRQ与GPIO中断 主要区别在于中断路径和粒度: 专用的 IRQ0–IRQ5 引脚是直接连接到中断控制器线路的外部 I/O 信号;它们的中断状态可在相应的 GIC-400 寄存器中找到,并且它们的极性可通过 SCFG_INTPCR 进行可编程。 GPIO 中断并非每个引脚的独立 GIC 输入。GPIO 模块检测引脚事件并将其存储在 GPIER 中,通过 GPIO 寄存器进行屏蔽/控制,然后驱动一个合并的 GPIO 中断请求。参考手册还指出,所有 GPIO 中断都经过逻辑或运算,作为 GPIO 中断源。 因此,实际的软件区别在于,专用 IRQ 可以在 GIC 级别作为其自身的中断源进行处理,而 GPIO 中断通常需要 ISR 进入 GPIO 块,读取 GPIER 以确定哪个引脚引起了该事件,然后清除/处理它。 对于延迟最敏感或优先级最高的外部中断,请使用专用 IRQ 引脚;当需要更多输入且可以容忍共享 GPIO 中断处理时,请使用 GPIO 中断。
記事全体を表示
我正在寻找 AFT05MS004NT 在 30-45 MHz 频率范围内的阻抗。 我正在寻找阻抗 AFT05MS004NT1,30-45 MHz Z负载和Z源 请各位帮帮我 Re: I am looking for the impedance of AFT05MS004NT AT FREQ 30-45 MHZ 你好, 遗憾的是,我们没有 AFT05MS004NT 在 30–45 MHz 频率范围内的阻抗数据。 获取阻抗数据需要专用的特性分析过程,该过程必须针对每个感兴趣的频率分别进行。这个过程很耗时,通常侧重于设备最初被设计并预期运行的频率范围。评估其他频率通常需要设计和建造特定的测试夹具和匹配网络。 因此,对于标准特性范围之外的工作条件(例如不同的频率、功率级或电源电压),阻抗数据并不总是可用。 由此给您带来的不便,我们深表歉意,并感谢您的理解。
記事全体を表示
在 i.MX95 NPU 上运行 yolov11n、yolov8n、yolov5nu 模型后未获得任何输出。   [i.MX95 NPU] YOLOv5n/v8n/v11n 中子转换模型运行但未返回任何探测结果(零输出) 问题描述 我正在使用 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 部署说明都将不胜感激。   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨,亚历杭德罗, 感谢您的回复。 我认为我的硬件平台可能存在一些误解。我的问题与 i.MX91 无关。 我正在使用以下平台: 主板:i.MX95 19x19 LPDDR5 EVK(IMX95LPD5EVK-19CM,A1 版本) 开发板快速入门指南: https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK:MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 内核:Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) 您分享的指南似乎是针对 i.MX91 的,而我的问题是关于在 i.MX95 Neutron NPU 上部署 YOLO。 原始的 INT8 TFLite 模型(YOLOv5nu、YOLOv8n 和 YOLOv11n)在 Cortex-A55 CPU 上运行正常,并产生有效的检测结果。然而,在使用 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 中包含的 Neutron 变流器编译相同的模型后,推理在 NPU 上成功执行,没有任何运行时错误,但输出张量不包含任何有效检测结果。 为了便于调查,我已经将以下文件附加到我的原帖中: * 原始 INT8 量化 TFLite 模型。 * YOLOv8n 和 YOLOv11n 的中子转换 TFLite 模型。 * 一个可用于重现该问题的 Python 推理脚本。 由于这些是原始的预训练 Ultralytics 模型转换为 TFLite,因此您可以直接使用提供的脚本中的标准 COCO 类名。它应该能让你在 i.MX95 平台上重现该行为,而无需任何额外的修改。 如果您能使用附件中的文件重现该问题,并告知我这是否是当前 Neutron SDK for i.MX95 的已知限制或问题,我将不胜感激。 谢谢。 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 你好@vijayranaACL , 感谢您联系恩智浦技术支持。 请参考本指南。 由于您使用的是 i.MX91 A1 芯片版本,因此某些特性或功能可能无法正常工作,因为 A1 是一个早期芯片版本,主要用于评估和开发目的。 因此,我们建议您在测试和验证活动中使用 i.MX91 B0 芯片版本。该指南是使用 B0 硅版本开发和验证的,因此记录的行为和结果均基于该版本。 如果可以,请确认您使用的是哪个版本的芯片,以及您是否可以获取 B0 设备进行比较。 此致, 亚历杭德罗·加西亚 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 你好@vijayranaACL , 我已在采用 B0 芯片的 i.MX95 EVK 上测试了您的代码,在我们这边运行正常,没有任何问题。 使用 person_detect.py 应用程序,模型加载成功,Neutron 委托初始化正确,应用程序按预期执行推理。在测试过程中,我观察到稳定的目标检测和持续约 13-14 FPS 的性能。日志还证实 Neutron 代理处于活动状态,并且模型在 NPU 加速下正在正常执行。 根据这些结果,我建议升级到 B0 硅片版本。A0 和 A1 硅版本主要是为了评估和 beta 测试目的而发布的,它们没有与 B0 相同级别的软件支持和验证。早期版本之后引入了一些功能和修复,这或许可以解释您看到的情况。 以下是我的测试日志的相关部分: root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# 由于相同的应用程序和模型在 B0 芯片上运行正常,我的建议是在继续进行进一步调试之前,使用 B0 设备重复测试,因为问题可能与芯片版本有关,而不是与应用程序本身有关。 此致, 查维拉 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨,亚历杭德罗, 感谢您澄清是 i.MX 95(而非 i.MX 91)的问题,并推荐使用 --优化级别 OOpt。 我们尝试在现有配置上执行您建议的命令,但是 --优化级别 不可用 在与我们的板级 BSP 配套的中子变流器中。 我们目前的环境 元器件版本 电路板 IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next ) 中子号代表已登船 v1.0.0-be8bf399 主机变流器 eIQ 工具包 1.17 → 中子变流器 2.1.3+0Xaf140cf5 变流器 电路板支持包 标签 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 在这个变流器上, 中子转换器 --help 做 不是 列表 --优化级别。 我们实际运行的命令 中子变流器 \ --输入yolov8n_full_integer_quant.tflite \ --输出yolov8n_neutron.tflite \ --target imx95 为了进行调试,我们还使用: 中子变流器 \ --输入yolov8n_full_integer_quant.tflite \ --输出yolov8n_neutron.tflite \ --target imx95 \ --详细 我们的变流器(2.1.3)中可用的标志 关键选项  - 帮助: - 输入,  - 输出,  - 目标 --合并中子图 --将输入的 uint8 转换为 int8, --convert-outputs-uint8-to-int8 --dump-statistics, --dump-graphs, --详细 --include-between-input-tensors, --排除输入张量之间的差异 --显示目标, --show-kernel-kinds --优化级别 不存在 在这个版本上。 目前为止的测试结果 模型 NPU 行为 YOLOv8n 中子(我们的转换) 调用没问题,但是 0 次检测 YOLOv8n 无头骨干网 NPU 输出 常数(~1.13) 无头CPU主干网+CPU头部 检测结果正常 ——管道逻辑正确 问题 是 --optimization-level OOpt 仅支持较新的中子变流器 2.1.3 ? 推荐的转换命令是什么? LF6.12.34 / imx95 什么时候 OOpt 不可用? Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨@vijayranaACL , 抱歉,这是我的笔误。 我指的是 i.MX95,因为 i.MX91 不包含 NPU。 我建议尝试使用以下命令转换模型: .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt 根据 Neutron SDK 文档,需要注意的是,对于 Neutron-S 靶(例如 i.MX95),变流器不是确定性的。转换过程依赖于多线程约束编程求解器,这意味着对同一模型执行变流器的不同操作可能会产生略有不同的结果,尤其是在 TCM 内存分配和生成的微代码方面。 由于可能存在多个最优解,因此在每次转换过程中,不同的求解器线程可能会收敛到不同的有效解。尽管这些解决方案内部可能有所不同,但变流器认为它们都是正确且经过优化的。在大多数情况下,这些差异不应显著影响功能或性能。 如果您观察到行为、性能或准确性方面的变化,我建议您多次转换模型并比较结果。虽然有一些方法可以强制执行确定性行为,但通常会大大增加转换时间,因此除非绝对必要,否则一般不建议使用。 请告知我您的测试结果。 此致, 亚历杭德罗·加西亚
記事全体を表示
MPC574xP BCTRL Hi: My customer is using MPC5741P for Auto ESC application. Currently, they were asked by the end OEM about BCTRL pin characteristics, such as voltage region.  Could you help check and confirm it? Thanks. Below is the waveform, it's triangle, and  OEM asked to add decouple Cap. on base control output pin from MCU side.  Re: MPC574xP BCTRL Datasheets recommend different transistor as you can see below: Also it needs to be properly bypassed/decoupled. Pay attention mainly to VDD_LV_COR:
記事全体を表示
AFT05MS004NTのインピーダンス(周波数30~45MHz)を探しています。 私はインピーダンスを探しています AFT05MS004NT1、30~45MHz用ZロードおよびZソース 皆さん、助けてください Re: I am looking for the impedance of AFT05MS004NT AT FREQ 30-45 MHZ こんにちは、 残念ながら、AFT05MS004NTの30~45MHzの周波数範囲におけるインピーダンスデータは入手できていません。 インピーダンスデータを取得するには、専用の特性評価プロセスが必要であり、対象となる周波数ごとに個別に実行しなければならない。このプロセスは時間がかかり、通常はデバイスが当初特性評価され、動作するように意図されていた周波数範囲に焦点を当てます。追加の周波数を評価するには、特定の試験用器具やマッチングネットワークの設計・構築が求められることが多いです。 このため、インピーダンスデータは、異なる周波数、電力レベル、電源電圧など、標準的な特性評価範囲外の動作条件では必ずしも入手できるとは限りません。 ご迷惑をおかけして申し訳ございません。ご理解いただけますようお願い申し上げます。
記事全体を表示
エッジ検出モードで動作したGPIOピンを割り込み入力信号として使うことはできますか? こんにちは、 専用のIRQ(0~5)ピンが6本だけでは不十分なので、他のGPIOピンを割り込み入力信号として使用する必要があります。そこで、以下に2つの質問があります。 1. エッジ検出モードで動作する割り込み信号入力として、任意のGPIOを使用可能か? 2. 上記1が「はい」の場合、専用IRQとGPIOの違いは何ですか?応答を優先すべきでしょうか? よろしくお願いいたします! よろしくお願いいたします! ジェイソン Re: Could I use any GPIO pin as interrupt input signal which worked at edge detection mode? はい、LS1021A GPIOは、ピンが実際にマルチパクシングされているか、基板上でGPIO入力として利用可能であれば、エッジ検出モードを含む割り込み入力として使用できます。 エッジ割り込み入力としてのGPIO GPIOブロックには割り込み制御/ステータス/マスクレジスタ(GPIER、GPIMR、GPICR)があります。GPICRはエッジトリガー動作を含むイベント検出を設定し、GPIO割り込みロジックはシステムに統合されたgpio_intリクエストを出力します。各GPIOポートラインについて、EDnビットは、割り込みが状態変化時に発生するか、ハイからローへの遷移時に発生するかを選択します。したがってGPIO割り込み入力はサポートされていますが、文書化されたエッジの選択は完全に独立した上昇/下降/両エッジセレクタとは異なります。挙げられているモードは「任意の変化」または「高から低」です。 専用IRQとGPIO割り込みの比較 主な違いは、割り込みパスと粒度です。 専用のIRQ0–IRQ5ピンは、割り込みコントローラ回線に直接接続された外部I/O信号です。割り込み状態は対応するGIC-400レジスタで確認でき、極性はSCFG_INTPCRを通じてプログラム可能です。 GPIO割り込みは、ピンごとに独立したGIC入力ではありません。GPIOモジュールはGPIER内のピンイベントを検出・保存し、GPIOレジスタを通じてマスキングや制御を適用し、統合されたGPIO割り込み要求を駆動します。参考マニュアルには、すべてのGPIO割り込みがGPIO割り込みソースに対してORでまとめられていると記載されています。 SO、実際のソフトウェア上の違いは、専用IRQはGICレベルで独立した割り込みソースとして扱えるのに対し、GPIO割り込みは通常、ISRがGPIOブロックに入り、どのピンがイベントを引き起こしたかを判別するためにGPIERを読み取り、その後クリアやサービスを行う必要がある点です。 最も遅延に敏感または個別に優先される外部割り込みには専用のIRQピンを使用し、より多くの入力が必要で、共有GPIO割り込み処理に耐えられる場合はGPIO割り込みを使いましょう。 Re: Could I use any GPIO pin as interrupt input signal which worked at edge detection mode? こんにちは、 この質問はLS1021Aに関するものです。どんなご意見でも歓迎いたします! よろしくお願いいたします! ジェイソン
記事全体を表示
NAFE13388 crystal spec Which crystal spec (ppm/load) does RIOP RevB2 use for the NAFE13388 XTAL (X1, 18.432 MHz)? Re: NAFE13388 crystal spec Hello, Part number: ECS-184-12-33Q-JES-TR PPM: 20 PPM Load: 12 pF Hope this helps.
記事全体を表示
NFC PN7160 Hello, I have custom board with NXP PN7160 nfc device. The goal is to have MIFARE plus sl3 working on linux. Currently we are using libnfc-nci and we are able to detect badges (tag arrival and departure). Is there a library to manage MIFARE plus provided by NXP ? If yes does this library also provide functions to write AES keys to the badges ? thanks Re: NFC PN7160 Hello @angelobticino Hope you are doing well. PN7160 Software supporting MIFARE devices is secured under NDA (Non-Disclosure Agreement), the information is not public and it is located under the PN7160 Secure Files. However, I must mention that available software only offers support for MIFARE DESFire devices. Functionality related to MIFARE Plus must be implemented by you based on MIFARE Plus EV2 documentation (relevant documentation is also secured under NDA and must be requested through MIFAE Plus EV2 Secure Files). If you are interested in those resources, you can try requesting an NDA directly from the NDA online form; after your request is processed, you should be contacted by the NXP NDA team. If you have any questions, please consult the Non-Disclosure Agreement FAQs. Once you have a valid NDA with NXP, or if you already have a valid one, you will need to request access this document through Secure Access Rights by following the instructions from this page: Secure Access Rights | NXP Semiconductors. Also, I would recommend checking the Secure Access Rights FAQs | NXP Semiconductors. Regards, Eduardo.
記事全体を表示