Multi Source Translation Content

讨论

MCUX 25.6.136，newlib-nano，& swprintf 未定义我在使用 MCUX 25.6.136 时遇到了对 swprintf 的未定义引用问题。& newlib-nano。我也试过newlib，结果一样。经过一番调查，我发现 newlib-nano/newlib 存在一个上游问题： https://sourceware.org/pipermail/newlib/2024/021012.html 我想知道 NXP 能否证实我的猜测，即捆绑的 newlib-nano 版本存在这个问题。如果情况确实如此，那么通过引入更新版本的 newlib-nano/newlib 来修复这个问题是否已提上日程？康纳

XIP FLASHリマップを有効にした状態でイメージスワップ後にMCUBootイメージをデバッグ/フラッシュする皆さん、なぜ特定の状況でフラッシュドライバーが故障するのか、何か理由があるのか教えてほしいです。私たちはカスタムボードをIMXRT1176に使っています。このMCUのボードはEmbedded Artistsのキャリアボードをベースにしています。私たちのプロジェクトでは、フラッシュメモリに0x30100000と0x30200000の2つのパーティションがあります。私たちはMCU-LinkとLinkserverを使ってバイナリをフラッシュしています。バイナリは-この場合確認された署名です。FLASHのリマップ機能を有効にしているので、スワップは行われません。我々は2つの状況を観察する。 1.フラッシュメモリにブートローダーがあり、パーティション1にイメージファイルがあれば、すべて正常に動作します。 2. OTAアップグレードを完了し、MCUbootが2つ目のパーティションから新しいイメージを起動すると、linkserverからエラーが出るため、FLASHパート1への書き込みができません。 ================================================= NC:フラッシュドライバーの起動 MIMXRT1170_SFDP_QSPI.cfx(すでに常駐中) NC:フラッシュドライバーを実行するためにVECTRESETを送信中 Nc: フラッシュバリアント「iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026年5月15日 18:32:39」検出(16MB = 256*64K 0x30000000) Pb: 1/1(0) 0x30100000でセクター16-31を1048576バイトで書き込み追伸:(0) 30100000 で:0バイト - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗最初のパーティションは erase-range コマンドで消去済みであることに注意してください。また、私たちのファームウェアがフラッシュドライバーで処理すると期待通りに動作することも確認できます。リンクサーバーを手動で操作しようとした場合にのみ失敗します。 =================================================== Q1。何か明確な理由はありますか?パーティション2を消すべきなのか、それとも両方の区画を消すべきなのでしょうか? Q2。もしスロット1のためにバイナリをビルドした場合、パーティション2のイメージで動作するコアに接続したとき、このバイナリは動作しますか?Flashのリマップは動作しますか? ご協力ありがとうございます。よろしくお願いします！ヤクブ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled ギャビンさん、こんにちは。ご返信ありがとうございます！あなたはこれらの概念を理解する上で本当に役立ちました。もし可能なら、もう一つだけ一緒に考えていただけませんか? これはOTAアップデート後に取得したパーティション情報です。 =========== 画像 0; 名前 APP; 状態永続的: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 1.1.1+0> 画像ペイロードのSHA256: C825709456C098E38090... log_addr 0x30100000 は 0x30200000 にリマップされますスロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256: EBFCCC0D3E970230E404... log_addr 0x30200000 は 0x30200000 に再マッピングされます *アクティブ* =============== 次に、このスクリプトを実行してスロット0をクリアします。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 あなたの説明によると、リマップオーバーレイが有効になっているため、スロット1が消去されると予想していました。しかし、そうではありません。電源リセット後に得られた結果は以下のとおりです。 ========= フラッシュREMAP_OVERLAYが有効です。画像 0; 名前 APP; 状態なし: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): 画像が見つかりませんでしたスロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256:EBFCCC0D3E970230E404... log_addr 0x30200000 0x30200000への再マップ *アクティブ*========= まだslot0に何も書き込めないのは予想外です。eraseコマンドはremapコマンドの論理マッピングをバイパスするが、loadコマンドはバイパスしないということはあり得るのでしょうか？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled こんにちは、 @jslota13245 さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ご提供いただいた情報に基づき、以下の理由を考慮すべきだと考えます。故障の原因は FlexSPIリマップは引き続き有効です OTAアップデート後。MCUbootがリマップでslot1(partition2)を起動すると、アプリケーションにremapを残します。LinkServerのフラッシュ .cfx ドライバはAHB論理アドレスを通じて処理されるため、リマップは書き込みTo 0x30100000 (partition1)を物理 0x30200000 (partition2)に静かにリダイレクトします。物理はすでに確認済み画像を保持しており、空白ではありません。NORフラッシュは上書きできません。以前の erase-range 0x30100000 実際、同じ理由でパーティション2も消去しました。独自のファームウェアは、プログラムによって動作します。 FlexSPI IPコマンドモードでは、明示的な物理オフセットを使用することで、リマップをバイパスします。注: VECTRESET / デバッガーアタッチ再マッピングは明確ではない。PORまたは明示的なレジスタ書き込みのみがそれを可能にする。 Q1: どのパーティションを消去すべきですか? 重要なのは、パーティションを消去するだけでなく、まずリマップを無効にすることです。推奨： LinkServerでプログラミングを行う前に、リマップレジスタをクリアしてください。次に、両方のパーティション（slot0とslot1）を消去します。direct-XIPは最高バージョンを選択するため、slot1に古くなった画像が残るとMCUbootが再度選び、再マッピングを有効化するため、問題が再発します。 Q2: Partition2イメージを実行するコアに接続した場合、slot1バイナリは動作しますか? 画像にはリンクが必要ですプライマリスロット ( 0x30100000 ) 用に一度だけ実行します。同じバイナリはリマップによりどちらのスロットからでも実行されます。スロット1 用に別途ビルドする必要はありません。デバッグ用にアタッチすると、リマップは論理アドレスの整合性を保つため、コードの読み取りやブレークポイントは問題なく動作します。しかし、同じリマップはフラッシュを書く際に物理ターゲットを変えるため、LinkServerでslot0をプログラムする前にリマップを無効にする必要があります。よろしくお願いします、ギャビン

Warning in the .mex file In the (autogenerated) .mex file for a project, each peripheral reads something like this: 1.0.0 Notice the verbiage in the "description" attribute. For other peripheral this varies, but it is almost always something like a warning or an error message. The project compiles and runs fine. Also related, if I try to add a new software component from the 'Peripherals view', all the currently unselected peripherals are marked with yellow exclamations, please see the attached screen shot. If I hover the mouse over them, I get the same message shown in the "description" attribute. Yet I am able to add them without any issues. What are those warnings about? Re: Warning in the .mex file Hi @durga_choudhury This warning does not affect your project. It is only an indication that the corresponding driver has not been added or configured in the project. Therefore, no functional impact on your current implementation is expected. BR, VaneB

PN5190B1最初のRFフィールドONで反応しなくなります皆さんこんにちは、もうアイデアが尽きてしまったので助けていただけると嬉しいです... PN5190B1HN/C121E(ホスト:CC1352 MCU over SPI)を搭載したカスタムボードを持っています。新生産ロット(約100台)では、約75%の故障率が示されています。RFフィールドが初めてオンになった瞬間にSPIで応答しなくなり、VENリセット後にのみ回復します。前のロットのユニット(プロトタイプ5個)は同じデザインとBOMで正常に動作します。測定結果から、アンテナ/マッチング、送信機のショート、静的電源、SYS3Vの電圧低下、チップのファームウェア、シリコンロットの問題は除外しました。我々は、確認済みの根本原因、考えられるシリコンの不具合、または見落としている可能性のあるEEPROM/電源構成を探しています。ハードウェア NFCフロントエンド：PN5190B1HN/C121E — GetVersionレポートによると、HW=0x52、ROM=0x02、FW=0x0201です。 TX電源＝内部TX_LDO。VUP_TX（ピン6）= 3.3V（LDO入力）。VDDPA（ピン9）＝TX_LDO出力（GNDのみにデカップリング）。VBAT / VBATPWR = 3.3 V。内部DC-DCコンバータは使用されていません（BOOST_LXインダクタは取り付けられていません）。メインレールSYS3V = TPS62840降圧コンバータ（最大0.7A）からの3.3V。 27.12 MHz水晶発振子（村田製作所製 XRCGB27M120F3M00R0）。 DPCは無効になっています。ULPCD（超低消費電力カード検出）を使用。VDDPAを最小値に設定（TX_LDO_VDDPA_HIGH/LOW、EE 0x06/0x07 = 0x00）。差動アンテナTX1/TX2、EMCフィルタ（L = 160 nH）+整合回路。測定された共振周波数は約12.56MHz（最終的な金属環境なし）（良品と不良品で同一）。症状（詳細な特徴）フィールドONの前にフルSPIが動作します：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROMの読み書きはすべてSUCCESS（ステータス0x0000）を返します。最初のFieldOn(RF_ON)では、ホストがフィールドオンイベントを待つためにタイムアウトします。その直後、すべてのSPIレジスタの読み取りがタイムアウトします（CLIF_STATUS、SYSTEM_CONFIG、GetDieIdの読み取りはすべてHAL IOタイムアウトを返します）。VENリセットを行うまで、このチップはSPIに対して全く反応しません。 VENリセット後、チップは再び正常になります（GetVersion OK）。その後、FieldOnが再びチップを破損させ、無限リトライループが発生します。 RFフィールドは放射されません(NFCテストLEDは点灯しません)。基板は約20mAの電流を消費し、低電力状態に戻ることはありません。良品と不良品は、ファームウェア（0x0201）、DIEIDロット、EEPROM構成、アンテナ（VNA）、およびDC抵抗において同一である。唯一の違いは、FieldOnでは不良ユニットが破損してしまう点です。ホストMCUはハング中も生き続けます(I²Cキーパッドエキスパンダーが応答し続けます)。つまり、故障するのは基板全体ではなくPN5190側です。正常ユニットと不良ユニットの電流消費量は約2.7秒までは同一ですが、約2.7秒で正常ユニットは処理を完了して低電力に低下し、不良ユニットは約20mAのままになります。除外された項目（それぞれ直感ではなく、測定に基づいて）仮説除外された経緯アンテナ／マッチング／チューニング miniVNAを4つの良品ユニットと4つの不良品ユニットで測定したところ、両者は区別がつかなかった。共振周波数は良品12.565MHz、不良品12.593MHz、RL ≈ −9dB、|Z| ≈ 24.7Ω、SWR ≈ 2.08（いずれも同じ値）。 TX短絡/過電流直流抵抗 TX1–TX2 ≈ 1.2 kΩ、TX1–GND ≈ TX2–GND ≈ 1.15 kΩ、良品と不良品で同一静電気による電源漏れ／デカップリング電流消費量は、約2.7秒までは正常と異常で同じである。 SYS3V電圧低下 3.3Vで安定して測定。3.3Vレールすべてに47μFのバルクコンデンサを追加→変化なし、依然として故障。チップFW ユニットを最新のPN5190ファームウェアにアップデートしましたが、依然として失敗し、同じ動作を示します。（未処理の良品と不良品の両方で、ファームウェアコード0x0201が報告される。）シリコンロット DIEID 正常 00000000 0DD0945E 5B38BDDC 892C0810 対不良 00000000 0DD095A6 6938BDDC 892C0E64 — 同じプレフィックス/ロット構造 TXドライバ振幅 FieldOn前のCLIF_SS_TX1/2_RMCFG CW振幅の減少 → 変更なし TX_LDO過電流保護 TX_LDO_CONFIGビット11（0xAE → 0xA6）で無効化しましたが、変化はありませんでした。 TX_LDO出力コンデンサ VDDPA出力コンデンサ（4.7 µF + 100 pF）を取り外した → 変化なし EEPROM構成（良品と不良品で同一） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DCオフ、VUP = VBATPWR、ULPCD有効) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (デフォルト) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小値、約 1.5 V) DPCが無効になっています質問これは報告された「最初の起動時/最初のRFフィールドオン時にPN5190チップ破損」と一致します。根本原因と最終的な解決策を確認できますか?(注:最新のPN5190ファームウェアをフラッシュしても解決しませんでした — 同じ失敗です。) このロット／日付コードに対応するシリコンに関する訂正情報はありますか？完全なDIEIDとチップの刻印の写真も提供できます。当社のトポロジー（内部TX_LDO、VUP_TX = 3.3 V、VDDPA = LDO出力、DC-DCオフ、DPCオフ、ULPCD、VDDPA最小1.5 V）において、この構成は有効でしょうか？VDDPAを最低限の電圧で動作させることは問題でしょうか？また、比較対象となる正しいEEPROM電源構成（PNEV5190Bとの比較）は何でしょうか？電源投入順序に関する要件（VENとサプライランプのどちらを優先するかなど）があり、それが満たされない場合にこのような問題が発生するのでしょうか？注:前の(動作中の)ロットと比べて、VENはI²Cエクスパンダ出力から直接MCU GPIOに移し、VENプルアップはDNPなので、ホスト起動時にVENは浮動します。ブラウンアウト、過電流、FW、シリコン、アンテナがすべて測定で除外されている中で、VENリセットまでチップがSPIに応答しなくなるRF_ON経路の他に何があるのでしょうか? よろしくお願いいたします。イグナシオ Re: PN5190B1 becomes unresponsive on first RF field ON お世話になります。 RF Fiel ONコマンドがICをハングさせる既知の問題は公表されていません。ファームウェアの更新とEEPROMの内容をクローンした後、すべての影響を受けたPN5190デバイスで問題が解決したのか、教えていただけますか?この情報は、問題の範囲をよりよく理解するのに役立つだろう。一部の端末で問題が継続する場合、正常に動作する端末と不具合のある端末との間でA/B比較テストを実施する機会はありましたか？このような検査は、根本原因がIC自体に関連しているのか、それともシステムの他の要素に関連しているのかを判断するのに役立ちます。ロット追跡についてですが、代理店に製造ロットや影響を受けた部品の製造履歴について追加情報を提供できるか確認していただけますか? Re: PN5190B1 becomes unresponsive on first RF field ON 不可解な点は、正常に動作するユニットと故障するユニットが、同じファームウェアバージョン（v2.01）、同じシリコンリビジョン（B1）、同じハードウェア、同じアンテナチューニング、そしてクローン作成後には同じEEPROMの内容を持っていることだ。しかし、うまくいくものもあれば、ほとんどはうまくいかない。 PN5190のファームウェアをv2.0Dにアップグレードすることで、不具合のあるユニットの問題が解決します。その理由と、v2.01に既知の問題があるかどうかを知りたいです。 1. 症状: 故障したユニットについて：起動と初期化は正常に完了します。最初のRFフィールドオン時には、チップは意味のある電流を引きず、RFフィールドを発生させません(NFC電源のLEDテストカードで確認済みで点灯しません)、SPIでは完全に反応しなくなります。ホストがIO_TIMEOUTを報告しました。ソフトリセットも失敗します（SPI応答が必要です）。チップを復旧させるには、ハードウェアリセットまたは電源の再投入のみが必要です。その後は次のRFフィールドオンまで正常に動作しますが、そこでまたフリーズします。完全に再現可能。電源電圧（3.3V）は終始安定しており、電圧低下は発生しません。ボードの寿命で初めての電源アップ時に、一度きりの~600 mA(北欧PPK2で測定した0.62A)のイベントが観測されますが、その後のパワーアップでは二度と発生しません。故障したユニットのNFCコックピットからのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。情報:RfFieldControlService:RFオン警告:代表:PIN_IRQが高くなるのを待っていた。タイムアウトしました。エラー:RfFieldControlService:フィールドオン中にエラー240、IO_TIMEOUTが発生しました。正常に動作しているユニット（ファームウェア、設定は同じ）からのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。情報:RfFieldControlService:RFオン情報:RfFieldControlService:RF Off(RF オフ) ATQA 04 00 / SAK 0x08 / UID 04 8D12 33 2. テストセットアップ自社のホストファームウェアを除外するため、NXPのナレッジベース記事「外部PN5190を評価ボードPNEV5190BPに接続する方法」(R5/R7設置、R6開)に従い、本番ボードをUSB↔SPIブリッジとして使うPNEV5190BPに直接接続しました。R20入賞;VBAT/VBAT_PWR/VUPジャンパーは撤去されました。SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND、外部ボードに配線)。 NFC Cockpit v9.0.0 PNEV5190BP with MCU FW NNC_uC_VCOM_04.00.00 外部基板はNordic PPK2から3.3Vで給電される（電流測定が可能）。この故障はNXPホストとNXPソフトウェアの両方で再現されているため、ホストファームウェアが原因ではありません。 3．除外した項目（測定値付き）：仮説どのようにして除外されたのか供給崩壊／停電 3.3Vレールは全体を通して安定して測定されました送信機の短絡良品と不良品の直流抵抗値（TX1-TX2間、TX1-GND間、TX2-GND間）は同一（数kΩ） PAデカップリングにおけるリーク現場投入の瞬間までは、電流消費量は同じで、良い場合も悪い場合もある。アンテナの同調ずれ／マッチング VNA測定、良品4台＋不良品4台 — 下記参照 ICへの物理的損傷チップはハードウェアリセットで復旧するが、その後再び再現可能な形で故障する。ホストファームウェア NFC Cockpit + PNEV5190BPを使用して再現 PN5190ファームウェアバージョン良品と不良品の両方がv2.01、Hw B1にありますユーザーEEPROMコンテンツ正常なユニットのEEPROM全体を不良ユニットにクローンしたが、それでも失敗する。差：約29kHz（0.2％）、測定ノイズの範囲内。8つの掲示板で確認済み。アンテナは区別がつかない。 4. EEPROMの比較 - 1バイト良いユニットと悪いユニットの両方のユーザーEEPROMを完全にFW v2.01でダンプし、それらをファレンジしました。 648個のパラメータのうち、正確に1つだけ異なる。地域: DPC_SETTINGS パラメータ: DPC_CONFIG オフセット: 0x76 良品ユニット: 0x77 不良ユニット: 0x76 それ以外の部分はすべてバイト単位で同一です。これは答えのように思えた。特にRN00003の注意書きを考慮すると尚更だ。「対称」アンテナに接続されたIC(例:カスタマー開発ボードアンテナ)では、DPCを無効化せずRFフィールドを有効化しないでください。長期間にわたる過電流による送信機ドライバーの損傷が起こる可能性があります。当社のアンテナは対称型(差動TX1/TX2)で、最初の電源を入れた時の一度きりの~600 mAの現象は過電流状態と一致しています。しかし、バイトをコピーしてもユニットは修復されませんテスト結果不良ユニットにDPC_CONFIG = 0x77を書き込み（v2.01）、読み出し結果を確認し、電源を再投入する。それでも失敗する正常ユニットの完全なEEPROMダンプを不良ユニットにロードし（v2.01）、電源を再投入するそれでも失敗する良好なユニット、未改造、v2.01 完璧に動作しますつまり、DPC_CONFIG合格・不合格と関連していますが、原因ではありません。本当の違いが何であれ、それはユーザーのEEPROM領域には含まれていません。 5. 解決策：ファームウェアをV2.0Dに安全にアップグレードする PN5190Firmware_2.0D.esfwu （LEDLフォルダ、B0/B1用レガシーダウンロード）を使用してセキュアファームウェアアップグレードを実行すると、不具合のあるユニットが正常に動作するようになります。アイドル時：約33mA RFフィールドオン:~240 mA持続、安定、LED点灯 Layer3 をアクティブにすると、ATQA 04 00、SAK 0x08、UID 04 8D 12 33 が返されます。自社製品ファームウェアで動作を確認しましたこれまでに2ユニットがこの方法で回収されており、どちらも完全に機能しています。副作用：PwrConfigが上書きされ、過熱を引き起こす。アップグレード後、EEPROMオフセット0x0000 （ PwrConfig ）は0x21から0xE4に変更されます。0xE4の場合： PwrConfig 0xE4 PwrConfig 0x21 (復元済み) アイドル電流約290mA 約33mA ダイ温度（ PMU_TEMP_REG@0x5B ） 100℃ 40 °C アイドル時は290 mAでRFフィールドなし、内部温度センサーは100°C(最大Tjは125°C)を読み取ります。アップグレード後には毎回PwrConfigを0x21に復元します。 0xE4は、v2.0DにおけるPwrConfigのデフォルト値として意図されているのでしょうか？これは他のユーザーにとっても問題になりそうです。アップグレードによって変更された16個のEEPROMパラメータパラメータオフセット以前のバージョン（v2.01） (v2.0D) 後 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 極性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 デジタルTBシグナルインデックス 0xCE9 0x00 0x9B デジタルTB信号ビット 0xCEA 0x00 0x04 AnalogTBSignal 0xCEB 0x00 0x78 良いユニットの完全なEEPROMを不良ユニットにクローンしても直らないため、この16バイトだけでは解決できず、ファームウェアコード自体に何かが関与しているはずです。 6. ダイID 全てのユニットは、受領時の状態のままハードウェアB1、ファームウェアv2.01です。不良品 #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 不良品 #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 不良品 #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良品 #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 質問 FW v2.01で、RF Field ONがフィールドもSPI応答もないままICがハングしてしまう既知の問題はありますか?DPC_CONFIGレジスタはv02.03で初めて導入された（RN00003による）こと、そしてv02.07→v02.08とv02.08→v02.09の両方にDPC制御の修正が含まれていることに注意してください。ファームウェア、シリコンリビジョン、ハードウェア、EEPROMがすべて同じであるにもかかわらず、なぜ約25%のユニットは正常に動作し、約75%は動作しないのでしょうか？ユーザーEEPROMの範囲外(工場出荷時のトリムや内部状態)で、同じロットのユニット間で異なるものはありますか? 上記のダイIDは異なる生産ロットやウェハーバッチに特定できますか? v2.0Dにアップグレードした後、PwrConfig = 0xE4という値は意図された値ですか？その結果、当社の設計ではアイドル消費量~290 mA、ダイ温度100°Cとなります。 PN5190デバイスは特定のファームウェアバージョンを事前にプログラムした状態で注文できますか?ツール自体がバージョン2.01が旧バージョンであることを警告しているにもかかわらず、バージョン2.01で出荷したため、生産バッチ全体が無駄になってしまいました。残りの80~0ユニットの未使用ユニットに対して、一度きりの600 mAイベントを完全に回避するために、最初の電源アップ前にv2.0Dにアップグレードすることが推奨される緩和策でしょうか? アドバイスをいただければ幸いです。

启用 XIP FLASH 重映射后，在镜像交换后对 MCUBoot 镜像进行调试/刷写。各位亲爱的朋友们，我想请教一下，为什么我们的U盘会在某种特定情况下出现故障？我们使用定制的电路板，搭载 IMXRT1176，我们的电路板基于 Embedded Artists 的该 MCU 载板。我们的项目中，闪存中有两个分区，分别为 0x30100000 和 0x30200000。我们使用 MCU-Link 和 Linkserver 来烧录二进制文件。在这种情况下，二进制文件会使用 --confirmed 进行签名。我们启用了 FLASH 重映射功能，因此不会执行交换操作。我们观察到两种情况： 1.如果闪存中有引导加载程序，并且分区 1 中有镜像，则一切都按预期工作。 2. OTA 升级完成后，MCUboot 从第二个分区启动新镜像，此时我们将无法再写入 FLASH 分区 1，因为链路服务器会报错： ================================================= Nc：正在打开闪存驱动程序 MIMXRT1170_SFDP_QSPI.cfx（已驻留） Nc：发送 VECTRESET 以运行闪存驱动程序 Nc：检测到 Flash 变体“iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026 年 5 月 15 日 18:32:39”（16MB = 256*64K，地址为 0x30000000） Pb：1/1 (0) 正在写入地址 0x30100000 的扇区 16-31，共 1048576 字节 PS：（0）位于 30100000：0 字节 - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败请注意，我已经使用 erase-range 命令擦除了第一个分区。我还可以确认，当我们的固件通过闪存驱动程序执行此操作时，它能按预期工作。只有当我尝试手动使用链接服务器时才会失败。 =================================================== 问题一：这样做有什么明显的原因吗？我们应该总是擦除分区 2 还是两个分区都擦除？ Q2. 如果我们为 slot1 构建了一个二进制文件，那么当我们将其连接到运行在分区 2 中的镜像的核心时，该二进制文件是否能正常工作？Flash 重映射能否使其正常工作？提前感谢您的帮助！此致！雅库布 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好 Gavin，非常感谢你的回复！你真的帮我理解了这些概念。如果可以的话，能否请您再帮我解决一件事？这是我通过OTA更新获取到的分区信息： =========== 图片 0；名称 APP；状态永久：插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：C825709456C098E38090... log_addr 0x30100000 重映射为 0x30200000 插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *积极的* =============== 然后我运行这个脚本来清除 slot0。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 根据你所说，我原本以为会删除 slot1，因为重新映射叠加层已启用。然而，事实并非如此。断电重启后出现的情况是： ========= Flash REMAP_OVERLAY 已激活。图片 0；名称 APP；状态无：插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)：插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *活跃*========= 我仍然无法向 slot0 写入任何内容，这出乎我的意料。是否有可能擦除操作绕过了重映射的逻辑映射，而加载操作则没有？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好@jslota13245 ，感谢您对 NXP MIMXRT 系列产品的关注！根据您提供的信息，我认为应该考虑以下原因。故障是由以下原因造成的： FlexSPI 重映射仍然启用 OTA 之后。当 MCUboot 通过重映射启动 slot1（分区 2）时，它会将重映射保留到应用程序中。LinkServer 的 .cfx 闪存驱动程序通过 AHB 逻辑地址进行编程，因此重映射会静默地将您的写入操作重定向到 0x30100000 （分区1）到物理 0x30200000 （分区 2）——其中已包含已确认的图像，并且不为空。NOR闪存无法覆盖它。你之前的 erase-range 0x30100000 实际上，出于同样的原因，我也删除了分区2。你自己的固件之所以能工作，是因为它通过以下方式进行编程： FlexSPI IP 命令模式，具有明确的物理偏移量，绕过重映射。注意：VECTRESET / 调试器附加重映射并不明确——只有 POR 或显式寄存器写入才能实现。问题1：要删除哪个分区？关键在于先禁用分区重映射，而不仅仅是删除分区。受到推崇的：使用 LinkServer 进行编程之前，请清除重映射寄存器；然后擦除两个分区（slot0 和 slot1）。由于 direct-XIP 会选择最高版本，因此插槽 1 中遗留的过时映像会导致 MCUboot 再次选择它并重新启用重映射，从而导致问题再次出现； Q2：当把 slot1 二进制文件附加到运行 partition2 镜像的核心上时，它能正常工作吗？图片应该链接一次用于主槽（ 0x30100000 ）；同一个二进制文件通过重映射从任一槽运行——无需单独构建槽1的**版本**。当您附加到调试位置时，重映射会保持逻辑地址一致，因此代码读取/断点可以正常工作。然而，同样的重映射操作在写入闪存时会改变物理目标，所以你在用 LinkServer 对 slot0 进行编程之前，必须先禁用重映射。此致，加文

Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Dear Everyone, I would like to ask for any possible reason why does our flash driver fail in one specific situation. We use custom board with IMXRT1176, our board is based on Embedded Artists carrier board for that MCU. In our project there are two partitions in flash, 0x30100000 and 0x30200000. We use MCU-Link and Linkserver to flash binaries. Binaries are signed with --confirmed in this case. We have a FLASH remap functionality enabled so no swap is performed. We observe two situations: 1. If there is a bootloader in flash and an image in partition 1, everything works as expected. 2. Once we complete the OTA upgrade and MCUboot boots new image from a second partition, we can no longer write to FLASH partiton 1 as we get an error from linkserver: ================================================= Nc: Opening flash driver MIMXRT1170_SFDP_QSPI.cfx (already resident) Nc: Sending VECTRESET to run flash driver Nc: Flash variant 'iMXRT1170_SFDP_FlexSPI1_A_QSPI May 15 2026 18:32:39' detected (16MB = 256*64K at 0x30000000) Pb: 1 of 1 ( 0) Writing sectors 16-31 at 0x30100000 with 1048576 bytes Ps: ( 0) at 30100000: 0 bytes - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Note that I have erased the first partition with erase-range. I also can confirm that when our firmware does it with flash driver it works as expected. It fails only when i try to do it with the linkserver manually =================================================== Q1. Is there any obvious reason for it? Should we always erase partition 2 or both paritions? Q2. If we have binary built for slot1, does this binary work when we attach to the core which runs with image in partition 2? Does Flash remap make it work? Thanks in advance for any help, Best Regards! Jakub Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hello Gavin, thank you very much for your response! You really helped me to understand these concepts. If it's possible, could you please help me figure out one more thing? This is partition info i get after OTA: =========== Image 0; name APP; state Permanent: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: C825709456C098E38090... log_addr 0x30100000 remaps to 0x30200000 Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE* =============== Then I run this script to clear slot0 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 According to what you said, i expected to erase slot1 because remap overlay is active. However that's not the case. What i got after power reset is: ========= Flash REMAP_OVERLAY active. Image 0; name APP; state None: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE*========= I still can't write anything to slot0 which is unexpected. Is it possible that erase bypasses the logical mapping of remap but load doesn't? Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hi @jslota13245 , Thanks for your interest in NXP MIMXRT series! Based on the information you provided, I believe the following reasons should be considered. The failure is caused by the FlexSPI remap still being enabled after OTA. When MCUboot boots slot1 (partition2) via remap, it leaves remap on into the application. LinkServer's .cfx flash driver programs through the AHB logical address, so the remap silently redirects your write to 0x30100000 (partition1) to physical 0x30200000 (partition2) — which already holds the confirmed image and is not blank. NOR flash cannot overwrite it. Your earlier erase-range 0x30100000 actually erased partition2 for the same reason. Your own firmware works because it programs via FlexSPI IP command mode with explicit physical offsets, bypassing the remap. Note: VECTRESET / debugger attach do not clear the remap — only a POR or an explicit register write does. Q1: Which partition to erase? The key is to disable remap first, not just erasing partitions. Recommended: Before programming with LinkServer, clear the remap registers; Then erase both partitions (slot0 and slot1). Because direct-XIP selects the highest version, a stale image left in slot1 will make MCUboot pick it again and re-enable remap, so the problem returns; Q2: Will a slot1 binary work when attached to a core running the partition2 image? The image should be linked once for the primary slot ( 0x30100000 ); the same binary runs from either slot via remap — no separate slot1 build is needed. When you attach for debug, remap keeps logical addresses consistent, so code reads/breakpoints work fine. However, the same remap changes the physical target when writing flash, so you must disable remap before programming slot0 with LinkServer. Best regards, Gavin

PN5190B1 becomes unresponsive on first RF field ON hi all, hope you can help me due we are out of ideas... We have a custom board with a PN5190B1HN/C121E (host: CC1352 MCU over SPI). A new production lot of ~100 units shows a ~75% failure rate: the device stops responding on SPI the moment the RF field is switched on for the first time, and only recovers after a VEN reset. Units from the previous lot (prototypes 5 pcs), same design and BOM, work correctly. We have ruled out antenna/matching, TX short, static supply, SYS3V brownout, chip FW and silicon lot with measurements. We are looking for the confirmed root cause, a possible silicon erratum, or an EEPROM/power configuration we may be missing. Hardware NFC frontend: PN5190B1HN/C121E — GetVersion reports HW=0x52, ROM=0x02, FW=0x0201. TX supply = internal TX_LDO. VUP_TX (pin 6) = 3.3 V (LDO input). VDDPA (pin 9) = TX_LDO output (decoupled to GND only). VBAT / VBATPWR = 3.3 V. Internal DC-DC not used (no BOOST_LX inductor fitted). Main rail SYS3V = 3.3 V from a TPS62840 buck (0.7 A max). 27.12 MHz crystal (Murata XRCGB27M120F3M00R0). DPC disabled. ULPCD (ultra-low-power card detection) used. VDDPA set to minimum (TX_LDO_VDDPA_HIGH/LOW, EE 0x06/0x07 = 0x00). Differential antenna TX1/TX2, EMC filter (L = 160 nH) + matching. Measured resonance ≈ 12.56 MHz (with no final metallic enviroment)(identical on good and bad units). Symptom (precise characterization) Full SPI works before field ON: SWITCH_MODE_NORMAL, GetVersion, GetDieId, EEPROM read/write all return SUCCESS (status 0x0000). On the first FieldOn (RF_ON) the host times out waiting for the field-on event. Immediately after, every SPI register read times out (reading CLIF_STATUS, SYSTEM_CONFIG, GetDieId all return a HAL IO timeout). The chip is completely unresponsive on SPI until a VEN reset. After a VEN reset the chip is healthy again (GetVersion OK), then FieldOn corrupts it again → endless retry loop. No RF field is radiated (NFC test LEDs do not light). Board draws ~20 mA and never returns to low power. Good vs bad units are identical in FW (0x0201), DIEID lot, EEPROM config, antenna (VNA) and DC resistances. The only difference is that bad units get corrupted on FieldOn. The host MCU stays alive during the hang (the I²C keypad expander keeps responding), so it is specifically the PN5190 that dies, not the whole board. Good vs bad current draw is identical up to ~2.7 s; at ~2.7 s the good unit completes and drops to low power, the bad unit stays stuck at ~20 mA. Ruled out (each with a measurement, not intuition) Hypothesis How it was excluded Antenna / matching / tuning miniVNA on 4 good + 4 bad units → indistinguishable: resonance good 12.565 MHz / bad 12.593 MHz, RL ≈ −9 dB, |Z| ≈ 24.7 Ω, SWR ≈ 2.08 on both TX short / overcurrent DC resistance TX1–TX2 ≈ 1.2 kΩ, TX1–GND ≈ TX2–GND ≈ 1.15 kΩ, identical good vs bad Static supply leak / decoupling Current draw identical good vs bad until ~2.7 s SYS3V brownout Measured stable at 3.3 V; added 47 µF bulk on all 3.3 V rails → no change, still fails Chip FW Updated a unit to the latest PN5190 firmware → still fails, same behaviour. (Untouched good and bad units both report FW 0x0201.) Silicon lot DIEID good 00000000 0DD0945E 5B38BDDC 892C0810 vs bad 00000000 0DD095A6 6938BDDC 892C0E64 — same prefix/lot structure TX driver amplitude Reduced CLIF_SS_TX1/2_RMCFG CW amplitude before FieldOn → no change TX_LDO overcurrent protection Disabled it via TX_LDO_CONFIG bit 11 (0xAE → 0xA6) → no change TX_LDO output capacitor Removed VDDPA output caps (4.7 µF + 100 pF) → no change EEPROM configuration (identical on good and bad units) DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC off, VUP = VBATPWR, ULPCD enabled) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (default) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (minimum, ≈ 1.5 V) DPC disabled Questions This matches the reported "PN5190 chip corruption during the first start / first RF field ON." Can you confirm the root cause and the definitive fix? (Note: flashing a unit with the latest PN5190 firmware did not resolve it — same failure.) Is there a silicon erratum for this lot / date code? We can provide the full DIEID and a photo of the chip marking. For our topology (internal TX_LDO, VUP_TX = 3.3 V, VDDPA = LDO output, DC-DC off, DPC off, ULPCD, VDDPA at the minimum 1.5 V): is this configuration valid? Is running VDDPA at the minimum a problem, and what is the correct EEPROM power configuration we should compare against (vs the PNEV5190B)? Is there a power-up sequencing requirement (VEN vs supply ramp) that would cause this if violated? Note: vs the previous (working) lot we moved VEN from an I²C expander output to a direct MCU GPIO, and the VEN pull-up is DNP, so VEN floats during host boot. With brownout, overcurrent, FW, silicon and antenna all excluded by measurement, what else in the RF_ON path can make the chip stop answering SPI until a VEN reset? Thanks in advance , Ignacio Re: PN5190B1 becomes unresponsive on first RF field ON Hello sir, There are no published known issues that can cause the RF Fiel ON command to hang the IC. Could you please clarify whether the issue was resolved on all affected PN5190 devices after updating the firmware and cloning the EEPROM contents? This information would help us better understand the scope of the problem. If the issue persists on some units, have you had the opportunity to perform an A/B comparison test between a working and a failing device? Such a test could help determine whether the root cause is related to the IC itself or to another element of the system. Regarding the lot tracking, could you please check with your distributor whether they can provide additional information about the production lot and manufacturing history of the affected components? Re: PN5190B1 becomes unresponsive on first RF field ON The puzzling part: working and failing units have the same firmware version (v2.01), the same silicon revision (B1), the same hardware, the same antenna tuning, and — after cloning — the same EEPROM content. Yet some work and most do not. Upgrading the PN5190 firmware to v2.0D fixes the failing units. We would like to understand why, and whether there is a known issue in v2.01. 1. Sympton: On a failing unit: Boot and initialization proceed normally. At the first RF Field ON, the chip draws no meaningful current, generates no RF field (verified with NFC-powered LED test cards — they do not light up), and stops responding on SPI entirely. The host reports IO_TIMEOUT. Soft Reset also fails (it needs an SPI response). Only a hardware reset / power cycle recovers the chip. It then works normally until the next RF Field ON, where it hangs again. Fully reproducible. Supply rail (3.3 V) stays stable throughout — no brownout. On the very first power-up in the life of a board, we observe a one-time ~600 mA event (0.62 A measured with a Nordic PPK2) that never occurs again on subsequent power-ups. Log from the NFC Cockpit on a failing unit: INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106 INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully. INFO:RfFieldControlService:RF On WARN:ABalDelegate:Waited for PIN_IRQ to go High. Timed out. ERROR:RfFieldControlService:Error 240,IO_TIMEOUT while during field on. Log from a working unit, same firmware, same setup: INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106 INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully. INFO:RfFieldControlService:RF On INFO:RfFieldControlService:RF Off ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33 2. TEST SETUP To rule out our own host firmware, we connected the production boards directly to a PNEV5190BP used as a USB↔SPI bridge, following the NXP Knowledge Base article “How to connect external PN5190 to PNEV5190BP Evaluation Board” (R5/R7 placed, R6 open; R20 placed; VBAT/VBAT_PWR/VUP jumpers removed; SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS, NFC_IRQ, NFC_VEN, GND wired to the external board). NFC Cockpit v9.0.0 PNEV5190BP with uC FW NNC_uC_VCOM_04.00.00 External board powered from a Nordic PPK2 at 3.3 V (allows current measurement) The failure reproduces identically with the NXP host and NXP software, so it is not caused by our host firmware. 3. What we ruled out (with measurements): Hypothesis How it was ruled out Supply collapse / brownout 3.3 V rail measured stable throughout Short circuit on TX DC resistance TX1-TX2, TX1-GND, TX2-GND identical on good and bad units (several kΩ) Leakage on PA decoupling Identical current consumption good vs bad until the field-on moment Antenna detuning / matching VNA measurement, 4 good + 4 bad units — see below Physical damage to the IC The chip recovers with a hardware reset and fails again reproducibly Our host firmware Reproduced with NFC Cockpit + PNEV5190BP PN5190 firmware version Both good and bad units are on v2.01, Hw B1 User EEPROM content Cloned the complete EEPROM of a good unit into a bad unit → still fails Difference: ~29 kHz (0.2%), within measurement noise. Confirmed on 8 boards. Antennas are indistinguishable. 4. THE EEPROM COMPARISION - one single byte We dumped the complete user EEPROM of a good unit and a bad unit, both on FW v2.01, and diffed them. Out of 648 parameters, exactly one differs: Region: DPC_SETTINGS Param: DPC_CONFIG Offset: 0x76 GOOD unit: 0x77 BAD unit: 0x76 Everything else is byte-identical. This looked like the answer, especially given the precautionary note in RN00003: Do not disable the DPC and activate the RF field for ICs connected to antennas matched “Symmetric” (for example, customer development board antenna). Possible damage of the transmitter drivers due to overcurrent over a long period might occur. Our antenna is symmetric (differential TX1/TX2), and the one-time ~600 mA event on first power-up is consistent with an overcurrent condition. However, copying the byte does NOT fix the unit Test Result Write DPC_CONFIG = 0x77 to a bad unit (v2.01), verify readback, power cycle Still fails Load the complete EEPROM dump of a good unit into a bad unit (v2.01), power cycle Still fails Good unit, unmodified, v2.01 Works perfectly So DPC_CONFIG correlates with pass/fail but is not the cause. Whatever the real difference is, it is not in the user EEPROM area. 5. what does fix it: secure firmware upgrade to V2.0D Performing a Secure Firmware Upgrade with PN5190Firmware_2.0D.esfwu (LEDL folder, legacy download for B0/B1) makes the failing units work: Idle: ~33 mA RF Field ON: ~240 mA sustained, stable, LEDs light up Activate Layer3 returns ATQA 04 00, SAK 0x08, UID 04 8D 12 33 Verified working afterwards with our own product firmware Two units recovered this way so far, both fully functional. Side effect: PwrConfig is overwritten and causes overheating After the upgrade, EEPROM offset 0x0000 (PwrConfig) changes from 0x21 to 0xE4. With 0xE4: PwrConfig 0xE4 PwrConfig 0x21 (restored) Idle current ~290 mA ~33 mA Die temperature (PMU_TEMP_REG@0x5B) 100 °C 40 °C 290 mA at idle with no RF field, and the internal temperature sensor reading 100 °C (Tj max is 125 °C). We restore PwrConfig to 0x21 after every upgrade. Is 0xE4 the intended default for PwrConfig in v2.0D? This looks like it could be a problem for other users too. The 16 EEPROM parameters changed by the upgrade Parameter Offset Before (v2.01) After (v2.0D) PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 polarity 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 DigitalTBSignalIndex 0xCE9 0x00 0x9B DigitalTBSignalBit 0xCEA 0x00 0x04 AnalogTBSignal 0xCEB 0x00 0x78 Since cloning a good unit’s complete EEPROM into a bad unit does not fix it, the fix cannot be in these 16 bytes alone — something in the firmware code itself must be involved. 6. Die IDs All units are Hw B1, FW v2.01 as received: BAD #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 BAD #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 BAD #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 GOOD #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. Questions Is there a known issue in FW v2.01 that can cause RF Field ON to hang the IC with no field generated and no SPI response? We note that DPC_CONFIG as a register was only introduced in v02.03 (per RN00003), and that v02.07→v02.08 and v02.08→v02.09 both contain DPC regulation fixes. Why do ~25% of units work and ~75% fail with identical firmware, silicon revision, hardware and EEPROM? Is there anything outside the user EEPROM area (factory trims, internal state) that could differ between units of the same lot? Can the Die IDs above be traced to different production lots or wafer batches? Is PwrConfig = 0xE4 the intended value after upgrading to v2.0D? It results in ~290 mA idle consumption and 100 °C die temperature on our design. Can PN5190 devices be ordered with a specific firmware version pre-programmed? Shipping with v2.01 while the tool itself warns it is obsolete has cost us a full production batch. Is upgrading to v2.0D before first power-up the recommended mitigation for the remaining ~80 unused units, to avoid the one-time 600 mA event entirely? Any guidance appreciated.

PN5190B1 在首次开启射频场时无响应大家好，希望你们能帮帮我，我们已经黔驴技穷了…… 我们有一块定制板，上面有PN5190B1HN/C121E（主机：CC1352 MCU，通过SPI接口）。新生产的约 100 台设备出现约 75% 的故障率：设备在首次开启射频场时停止对 SPI 做出响应，只有在 VEN RESET 后才能恢复。上一批产品（原型 5 件），设计和物料清单相同，运行正常。我们通过测量排除了天线/匹配问题、发射机短路、静态电源问题、SYS3V 电压骤降、芯片固件和硅批次问题。我们正在寻找已确认的根本原因、可能的芯片缺陷，或者我们可能遗漏的 EEPROM/电源配置。硬件 NFC 前端：PN5190B1HN/C121E — GetVersion 报告 HW=0x52，ROM=0x02，FW=0x0201。 TX 供电 = 内部 TX_LDO。VUP_TX（引脚 6）= 3.3 V（LDO 输入）。VDDPA（引脚 9）= TX_LDO 输出（仅与 GND 解耦）。VBAT / VBATPWR = 3.3 V。未使用内部 DC-DC（未安装 BOOST_LX 电感器）。主电源轨 SYS3V = 3.3 V，由 TPS62840 降压器供电（最大 0.7 A）。 27.12 MHz 晶体（Murata XRCGB27M120F3M00R0）。 DPC已禁用。采用超低功耗卡检测（ULPCD）。VDDPA 设置为最小值（TX_LDO_VDDPA_HIGH/LOW，EE 0x06/0x07 = 0x00）。差分天线 TX1/TX2，EMC 滤波器（L = 160 nH）+ 匹配。测得的谐振≈12.56 MHz（无最终金属环境）（好单元和坏单元相同）。症状（精确描述）在字段 ON 之前，完整的 SPI 功能正常：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROM 读/写操作全部返回成功（状态 0x0000）。第一次触发 FieldOn (RF_ON) 事件时，主机等待场开启事件超时。随后，所有 SPI 寄存器读取操作均超时（读取 CLIF_STATUS、SYSTEM_CONFIG、GetDieId 均返回 HAL IO 超时）。在 VEN RESET 之前，芯片在 SPI 接口上完全没有响应。 VEN 重置后芯片恢复正常（GetVersion OK），然后 FieldOn 又会将其损坏 → 无限重试循环。不会辐射射频场（NFC 测试 LED 灯不亮）。电路板消耗约 20 mA 电流，且不会回到低功耗状态。好的单元和坏的单元在固件 (0x0201)、DIEID 批次、EEPROM 配置、天线 (VNA) 和直流电阻方面是相同的。唯一的区别是，在 FieldOn 上，损坏的单位会被损坏。主机 MCU 在死机期间保持运行（I²C 键盘扩展器持续响应），因此是 PN5190 损坏，而不是整个电路板损坏。好单元和坏单元的电流消耗在约 2.7 秒内相同；在约 2.7 秒时，好单元完成工作并降至低功率，坏单元则保持在约 20 mA。已排除（每一项都经过测量，而非凭直觉）假设：它是如何被排除的天线/匹配/调谐使用 4 台正常设备和 4 台故障设备进行 miniVNA 测试 → 结果无法区分：谐振频率正常设备为 12.565 MHz / 故障设备为 12.593 MHz，RL ≈ −9 dB，|Z| ≈ 24.7 Ω，两者的驻波比 (SWR) 均 ≈ 2.08。 TX短路/过流直流电阻 TX1–TX2 ≈ 1.2 kΩ，TX1–GND ≈ TX2–GND ≈ 1.15 kΩ，相同质量的器件与劣质器件相同。静态供水泄漏/解耦电流消耗在约 2.7 秒之前，无论好坏，都相同。 SYS3V 电压骤降经测试，在 3.3V 电压下稳定；在所有 3.3V 电源轨上添加了 47µF 电容 → 没有变化，仍然失败芯片固件将设备更新到最新的 PN5190 固件 → 仍然失败，情况相同。（未经改动的正常设备和故障设备都报告固件版本为 0x0201。）硅片 DIEID 良好 00000000 0DD0945E 5B38BDDC 892C0810 与不良 00000000 0DD095A6 6938BDDC 892C0E64 — 前缀/批号结构相同 TX驱动器幅度场开启前 CLIF_SS_TX1/2_RMCFG CW 幅度降低 → 无变化 TX_LDO 过流保护通过 TX_LDO_CONFIG 位 11 禁用（0xAE → 0xA6）→ 无变化 TX_LDO 输出电容移除 VDDPA 输出电容（4.7 µF + 100 pF）→ 无变化 EEPROM配置（正常单元和故障单元相同） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC 关闭，VUP = VBATPWR，ULPCD 启用) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (默认值) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小值，≈ 1.5 V) DPC 已禁用问题这与报告的“首次启动/首次开启射频场时PN5190芯片损坏”的情况相符。您能否确认根本原因和最终解决方案？（注：使用最新的PN5190固件刷新设备并未解决问题——故障依旧。）该批次/日期代码是否有硅油勘误表？我们可以提供完整的芯片ID和芯片标记照片。对于我们的拓扑结构（内部 TX_低压差线性稳压器(LDO)，VUP_TX = 3.3 V，VDDPA = 低压差线性稳压器(LDO) 输出，DC-DC 关闭，DPC 关闭，ULPCD，VDDPA 最低为 1.5 V）：此配置是否有效？以最低 VDDPA 运行是否有问题？我们应该与哪种正确的 EEPROM 电源配置进行比较（与 PNEV5190B 相比）？是否存在上电时序要求（VEN 与电源斜坡），如果违反该要求会导致这种情况？注意：与之前的（正常工作的）批次相比，我们将 VEN 从 I²C 扩展器输出移到了直接的 MCU GPIO，并且 VEN 上拉电阻为 DNP，因此 VEN 在主机启动期间处于浮空状态。排除欠压、过流、固件、硅和天线等因素后，RF_ON 路径中还有什么因素会导致芯片停止响应 SPI 信号，直到 VEN RESET？提前感谢！伊格纳西奥 Re: PN5190B1 becomes unresponsive on first RF field ON 令人费解的是：正常工作的单元和出现故障的单元具有相同的固件版本（v2.01）、相同的硅版本（B1）、相同的硬件、相同的天线调谐，并且在克隆后具有相同的 EEPROM 内容。然而，有些有效，大多数无效。将 PN5190 固件升级到 v2.0D 可以修复故障单元。我们想了解原因，以及 v2.01 中是否存在已知问题。 1. 症状：对于一台故障设备：启动和初始化过程正常进行。在第一个射频场开启时，芯片不会消耗任何有意义的电流，也不会产生射频场（已用 NFC 供电的 LED 测试卡验证——它们不会亮起），并且完全停止对 SPI 做出响应。主机报告 IO_TIMEOUT 超时。软复位也失败了（它需要 SPI 响应）。只有硬件重置/断电重启才能恢复芯片。之后它会正常工作，直到下一次射频场开启时，它又会再次卡住。完全可复现。供电轨（3.3V）始终保持稳定——没有电压骤降。在电路板的第一次上电时，我们观察到一次性的 ~600 mA 事件（使用 Nordic PPK2 测量为 0.62 A），此后在后续上电时再也没有发生过。故障设备上的 NFC Cockpit 日志：信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。信息：射频场控制服务：射频开启警告：ABalDelegate：等待 PIN_IRQ 变为高电平。超时。错误：RfFieldControlService：字段开启期间发生错误 240，IO_TIMEOUT。来自一台正常工作的设备（固件版本相同，配置相同）的日志：信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。信息：射频场控制服务：射频开启信息：射频场控制服务：射频关闭 ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33 2. 测试设置为了排除我们自己的主机固件，我们按照 NXP 知识库文章“如何将外部 PN5190 连接到 PNEV5190BP 评估板”中的说明，将生产板直接连接到用作 USB↔SPI 桥接器的 PNEV5190BP（R5/R7 已放置，R6 开路；R20 已放置；VBAT/VBAT_PWR/VUP 跳线已移除；SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND 已连接到外部板）。 NFC Cockpit v9.0.0 PNEV5190BP，微控制器固件版本为 NNC_uC_VCOM_04.00.00 外部电路板由 Nordic PPK2 供电，电压为 3.3V（可进行电流测量）使用 NXP 主机和 NXP 软件也会出现完全相同的故障，因此这不是由我们的主机固件引起的。 3. 我们排除的因素（通过测量）：假设它是如何被排除的供应崩溃/断电 3.3V 电源轨测量结果始终稳定 TX短路直流电阻 TX1-TX2、TX1-GND、TX2-GND 在正常单元和故障单元上相同（几千欧姆） PA解耦泄漏在场启动之前，电流消耗在好坏两方面都相同天线失谐/匹配 VNA测量，4个合格单元+4个不合格单元——见下文集成电路受到物理损坏芯片可通过硬件RESET恢复，但随后又会重复出现故障。我们的主机固件使用 NFC Cockpit + PNEV5190BP 进行复现 PN5190固件版本好的和坏的单元都运行在 v2.01 版本，硬件 B1 上。用户EEPROM内容将正常单元的完整 EEPROM 克隆到故障单元中 → 仍然失败差异：~29 kHz (0.2%)，在测量噪声范围内。已在 8 个电路板上确认。天线无法区分。 4. EEPROM 比较 - 单个字节我们分别从一台运行固件版本为 v2.01 的正常设备和一台故障设备中提取了完整的用户 EEPROM，并比较了它们的差异。 648 个参数中，恰好有一个不同：区域：DPC_SETTINGS 参数：DPC_CONFIG 偏移量：0x76 良好单元：0x77 错误单元：0x76 其他所有内容都字节完全相同。这看起来像是答案，特别是考虑到 RN00003 中的预防措施说明：不要禁用 DPC，并为连接到匹配“对称”天线的 IC 激活 RF 场（例如，客户开发板天线）。长时间过电流可能会导致发射器驱动器损坏。我们的天线是对称的（差分 TX1/TX2），首次上电时出现的一次 ~600 mA 事件与过电流情况一致。然而，复制字节并不能修复该单元。测试结果向故障单元（v2.01）写入 DPC_CONFIG = 0x77，验证读取结果，然后断电重启仍然失败将正常单元的完整 EEPROM 转储加载到故障单元中（v2.01），然后断电重启仍然失败良好单元，未修改，版本 2.01 完美运行因此，DPC_CONFIG 与通过/失败相关，但并非导致通过/失败的原因。无论真正的区别是什么，都不在用户 EEPROM 区域。 5. 解决方法：将固件安全升级到 V2.0D 版本使用PN5190Firmware_2.0D.esfwu （LEDL 文件夹，B0/B1 的旧版下载）执行安全固件升级，可使故障设备恢复正常工作：空闲状态：约 33 mA 射频场开启：持续稳定电流约 240 mA，LED 指示灯亮起激活Layer3返回ATQA 04 00，SAK 0x08，UID 04 8D 12 33 经验证，使用我们自己的产品固件后可以正常工作。目前已通过这种方式回收了两台设备，两台设备均功能完好。副作用：PwrConfig 被覆盖，导致过热。升级后，EEPROM 偏移量0x0000 ( PwrConfig ) 从0x21变为0xE4 。使用0xE4 ： PwrConfig 0xE4 PwrConfig 0x21（已恢复）空载电流约290毫安约33毫安芯片温度（ PMU_TEMP_REG@0x5B ） 100℃ 40°C 空闲时电流为 290 mA，无 RF场，内部温度传感器读数为 100 °C（Tj max 为 125 °C）。每次升级后，我们将PwrConfig恢复为0x21 。 0xE4是v2.0D 版本中 PwrConfig 的预期默认值吗？这看起来也可能是其他用户会遇到的问题。升级更改了 16 个 EEPROM 参数。参数偏移量之前（v2.01）（v2.0D）之后 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 极性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 数字TB信号指数 0xCE9 0x00 0x9B 数字TB信号比特 0xCEA 0x00 0x04 模拟TB信号 0xCEB 0x00 0x78 由于将正常单元的完整 EEPROM 克隆到故障单元中并不能解决问题，因此修复方法不可能仅仅依靠这 16 个字节——固件代码本身肯定存在一些问题。 6. 模具 ID 所有设备均为Hw B1，FW v2.01版本：错误代码 #1：00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 错误代码 #2：00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 错误代码 #3：00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良好 #1：00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 问题 FW v2.01 中是否存在已知问题，会导致 RF 场开启时 IC 卡死，既没有产生场也没有 SPI 响应？我们注意到，DPC_CONFIG 寄存器仅在 v02.03 版本中引入（根据 RN00003），并且 v02.07→v02.08 和 v02.08→v02.09 都包含 DPC 法规修复。为什么固件、芯片版本、硬件和 EEPROM 完全相同的情况下，约 25% 的设备可以正常工作，而约 75% 的设备却无法正常工作？除了用户 EEPROM 区域（出厂设置、内部状态）之外，同一批次的单元之间还有什么可能存在差异吗？上述芯片 ID 能否追溯到不同的生产批次或晶圆批次？升级到 v2.0D 后，PwrConfig = 0xE4 是否为预期值？我们的设计实现了约 290 mA 的空闲功耗和 100 °C 的芯片温度。 PN5190 设备可以订购预装特定固件版本的吗？尽管工具本身已发出版本 2.01 的警告，但我们仍然使用该版本进行发货，导致我们损失了一整批产品。对于剩余的约 80 个未使用单元，建议在首次通电前升级到 v2.0D，以完全避免一次性 600 mA 事件的发生。非常感谢您的指导。 Re: PN5190B1 becomes unresponsive on first RF field ON 您好，先生，目前尚未发现任何已知的问题会导致 RF Fiel ON 命令使 IC 卡死。更新固件并克隆 EEPROM 内容后，能否请您确认所有受影响的 PN5190 设备的问题是否都已解决？这些信息将有助于我们更好地了解问题的范围。如果某些设备上仍然存在该问题，您是否有机会对正常工作的设备和出现故障的设备进行 A/B 对比测试？这样的测试可以帮助确定根本原因是集成电路本身还是系统的其他元件。关于批次追踪，请您向代理商核实他们是否能提供有关受影响元器件的生产批次和制造历史的更多信息？

SDAファームウェアに関する質問 FRDM-A-S32K358の開発ボードを購入し、Open SDAを担当するMK26チップのファームウェアを変更するためにJTAGポートを確認しました。もし誤ってJ13にファームウェアをインストールしてしまった場合、Open SDAのファームウェアを入手する必要があります。この場合、サポートチケットを通じてファームウェアを入手できますか? Re: Open SDA Firmware Question こんにちは、 @wj_kwak MK26 OpenSDAデバイスがJ13経由で上書きされた場合、正常に動作するOpenSDAブートローダーを前提としているため、標準のOpenSDAアップデート手順は適用できなくなる可能性があります。OpenSDAのリカバリファームウェアは、通常、単体のプログラミングイメージとしては配布されていません。 OpenSDAのファームウェアとブートローダーは、NXPが開発したソフトウェアではなくPEmicro技術です。PEmicroはOpenSDAのファームウェアアップデート、ブートローダー更新アプリケーション、関連サポートを提供しています。したがって、MK26がJTAG/SWDで消去または再プログラムされ、OpenSDAブートローダーが機能しなくなった場合、回復案内やファームウェアの入手は主にPEmicroが担当となります。 https://www.pemicro.com/support/index.cfm よろしくお願いいたします。ルーカス

IMX95 Aquila ISP の使用状況こんにちは、私はAquila IMX95評価キット2を2つのov5640センサ(https://www.toradex.com/cart)搭載で購入しました。センサのドライバは持っています。基板は正しくフラッシュされ、ISPモジュールもアクティブになっています。 root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 カメラはlibcameraに表示されています。 root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) MIPが正常に動作しているかどうかを確認するために、GStreamerパイプラインを起動したところ、両方のカメラで安定した30fpsのストリームを取得することができました。v4l2-ctlを使ってスナップショットを撮ることにも成功しました。今、AquilaのISPをカメラでテストしてみたいと思っています。 https://www.nxp.com/docs/en/user-guide/UG10215.pdfに従って環境変数を追加しました。 root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' しかし、そうするとlibcameraにカメラが検出されなくなり、なぜかはわかりません: root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# お返事ありがとうございます！敬具 Re: IMX95 Aquila ISP usage ログを見たところ、問題はMIPIインターフェースやOV5640ドライバ自体には関係ないと思います。事実：両方のOV5640カメラはlibcameraによって検出されます GStreamer は30fpsでストリーミング可能です V4L2-CTLは画像を撮影できますセンサードライバー、I2C通信、 CSI-2 links、メディアトポロジーがすべて正常に動作していることを示します。重要な点は、NXP Neo ISPパイプラインがRAWのBayerセンサー入力を想定していることです。 OV5640は独自の内部画像処理パイプラインを持つSoCイメージセンサーであり、NXP BSPでは通常、RAWバイヤーセンサーとしてではなくYUV出力モード(例:YUV422)で使用されます。このような構成では、カメラは標準のV4L2/libcameraパイプラインを通じて使用できますが、Neo ISPパイプラインの要件には合致しません。これは以下の理由を説明するだろう。 `cam -l` はデフォルトで両方の OV5640 カメラを表示します設定後 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' カメラは検出されなくなりましたカメラはシステム内に存在しますが、NEOパイプラインハンドラーは互換性のあるカメラトポロジーを見つけられず、そのためlibcameraにはカメラが0台も露出します。実際のセンサー出力フォーマットを確認するために、以下の出力を教えていただけますか: 「バッシュ」 media-ctl -p V4L2-ctl --list-formats-ext 特に、センサーが以下のようなRAWバイヤーフォーマットを露出しているかどうかに関心があります: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 YUVフォーマット(例:YUYV/UYVY)のみが利用可能な場合、カメラはRAWモードで動作せず、Neo ISPパイプラインで処理できません。 OV5640ハードウェアはRAWバイヤー出力に対応していますが、BSPカメラドライバーではRAWサポートは一般的に有効ではなく、NXP Neo ISPスタックもセンサー固有のチューニングデータに依存しています。RAW出力が有効であっても、専用のOV5640チューニングプロファイルがないため、ISPの適切な動作(AE/AWB/画像品質チューニング)が妨げられる可能性があります。もしNeo ISPフレームワーク自体を評価するのが目的なら、NXP ISPスタックで動作することが知られているセンサを使う方が簡単かもしれません。一般的な候補としては、以下のようなものがあります。 OS08A20 OX03C10 OX05B1S AR0521 AR1335（追加の調整作業が必要になる場合があります）上記のコマンドの出力を教えてもらえますか?これにより、現在のOV5640の設定がRAWベイヤーフォーマットをシステムに公開しているかどうかを確認できます。よろしくお願いします、 Re: IMX95 Aquila ISP usage ご返信ありがとうございます。追加の確認を行いました。おっしゃる通り、OV5640は最初は UYVYモードで動作していましたが、手動で1つのセンサーを RAWのBayer(SRGGB8)に切り替えました。 media-ctl -p は現在次のように表示します: root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] （比較のため、2台目のOV5640はUYVYモードのままです） SO : OV5640 -> SRGGB8 CSI -> SRGGB8 フォーマッター -> SRGGB8 クロスバー -> SRGGB8 => RAWバイエルはセンサ、CSI、フォーマタを通じて正常に伝播されています。 neoispカーネルモジュールがロードされました。 root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 実行中のデバイスツリーにISPノードが存在します。 /sys/firmware/devicetree/base/soc/isp@4ae00000 => しかし、CSI/Formatter/ISIパイプラインを公開しているメディアデバイス(/dev/media0)は1台だけです。メディアグラフにはneoispのエンティティは現れません。メディアのグラフにneoispの存在は見当たりませんし、これが予想されるものなのかも分かりません。 => cam -l (libcamera) を実行しても、利用可能なカメラは返されません。現時点ではRAWのBayerパスは機能しているようですが、Neo ISPがどこでアクティブなパイプラインの一部になるのかは特定できません。ストリームが実際にNeo ISPによって処理されているか、単にCSI -> Formatter -> ISI経路をたどるのではなく、どうやって確認できますか? また、 https://www.nxp.com/docs/en/user-guide/UG10215.pdf も参照してください。この構成に関する推奨ガイドはまだありますか？それとも、i.MX95 上で OV5640 + Neo ISP を使用するためのより具体的な参考資料はありますか？敬具 Re: IMX95 Aquila ISP usage 現時点で私が疑っているのは、以下のいずれかが起こっているということです。 OV5640はRAWベイヤーモードではなく、YUVモードで動作している可能性が高い。カメラのDTオーバーレイは、ISP対応バージョンではありません。 Neo IPA/キャリブレーションコンポーネントがルートファイルシステムに存在しません。 Neoパイプラインで見られるメディアトポロジーは、期待されるi.MX95のISPグラフと一致しません。 media-ctl -pの出力は通常、どちらが実際の問題かを特定します。

S9KEAZN16AM WDOGタイミングに関する補足説明：128バスクロックと観測された80µsおよび2.5msの遅延についてこんにちは、私はS9KEAZN16AMを扱っており、WDOGの初期化タイミングについていくつか確認したい点があります。設定 MCU:S9KEAZN16AM バスクロック: 16.777216 MHz WDOGクロックソース：1kHz LPOCLK リセットタイプ:ソフトウェアリセット(SYSRESETREQ) KEA64リファレンスマニュアルによると、ウォッチドッグの解除シーケンスの後: 「アンロックシーケンスを完了した後、ユーザーは128のバスクロック内でウォッチドッグを再構成しなければなりません;そうでなければ、監視役はMCUのリセットを強制します。」バスクロック周波数は16.777216MHzです。 128バスクロック ≈ 7.63マイクロ秒補足事項現在の実装では、安定した動作のために以下の遅延が必要となります。ソフトウェアリセット(); SysTick_DelayUs(2500); DisableInterrupts(); WDOG_Init(&Wdog_cfg); SysTick_DelayUs(80); EnableInterrupts(); 我々は2つの問題点を指摘する。 Software_Reset() の後の 2.5 ms の遅延を削除または短縮すると、ウォッチドッグカウンタが正しく起動/実行されない場合があります。 WDOG_Init() の後の 80 µs の遅延を削除すると、ウォッチドッグの設定が常に正しく適用されるとは限りません。質問 128バスクロックの要件は、ロック解除後の設定ウィンドウのみに適用されるのでしょうか、それともその後も追加の内部同期が行われるのでしょうか？ 1 kHzのLPOクロックの使用によって追加の同期遅延が生じることはありますか? ソフトウェアリセット後の起動タイミングの要件で、約2.5msの遅延が必要になる理由は何かありますか? 固定遅延の代わりに、推奨されるステータスビットやポーリングメカニズムはありますか？混乱の主な原因は、観測された遅延（ 80 µs と 2.5 ms ）が、文書化された128 バスクロックの要件（約 7.6 µs）から示唆されるタイミングよりもかなり大きいことである。何かご助言いただければ大変ありがたいです。よろしくお願いします。

Random occurences of timeouts while reading variables Hello, I have been working on a battery test rig set up by my predecessors on the project. The test rig uses an nxp S32K144EVB board connected via usb to a computer. The code is built from a simulink file and monitoring of the test is made via FreeMASTER 3.2. The project has been working on a laptop for a few months and it has been necessary to configure a new laptop as a replacement. However, even while installing the same FreeMASTER version, the same drivers and using the same project files, all variable reads as "?" due to timeout errors after a seemingly random duration. Any help would be greatly appreciated. Logged errors after 12 minutes of runtime with no issues :

IMX95 Aquila ISP usage Hello, I bought an Aquila IMX95 Evaluation Kit 2 with two ov5640 sensors (https://www.toradex.com/cart). I have the drivers for the sensors. The board is flashed correctly, with the isp module active : root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 The cameras are showing in libcamera : root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) Just to check if the mipis are fine, I started a gstreamer pipeline and managed to get a stable 30fps stream on both cameras. I also managed to take snapshots with v4l2-ctl. Now, I'd like to test the Aquila's ISP with my cameras to see what it can do. Following the https://www.nxp.com/docs/en/user-guide/UG10215.pdf I added the environment variable : root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' But, doing so, the camera is not detected anymore by libcamera and I don't know why : root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# Thank you for your reply ! Cordially, Re: IMX95 Aquila ISP usage After looking at your logs, I believe the issue is not related to the MIPI interfaces or the OV5640 driver itself. The fact that: both OV5640 cameras are detected by libcamera GStreamer can stream at 30 fps v4l2-ctl can capture images indicates that the sensor drivers, I2C communication, CSI-2 links and media topology are all working correctly. The key point is that the NXP Neo ISP pipeline expects a RAW Bayer sensor input. OV5640 is a SoC image sensor with its own internal image processing pipeline, and in the NXP BSP it is typically used in YUV output mode (for example YUV422) rather than as a RAW Bayer sensor. In such a configuration, the camera can be used through the standard V4L2/libcamera pipeline, but it does not match the requirements of the Neo ISP pipeline. This would explain why: `cam -l` shows both OV5640 cameras by default after setting export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' no cameras are detected anymore The cameras are still present in the system, but the NEO pipeline handler cannot find a compatible camera topology and therefore exposes zero cameras to libcamera. To verify the actual sensor output format, could you please provide the outputs of: ```bash media-ctl -p v4l2-ctl --list-formats-ext We are particularly interested in whether the sensor exposes any RAW Bayer formats such as: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 If only YUV formats (for example YUYV/UYVY) are available, then the camera is not operating in RAW mode and cannot be processed by the Neo ISP pipeline. Although the OV5640 hardware is capable of RAW Bayer output, RAW support is not commonly enabled in BSP camera drivers, and the NXP Neo ISP stack also relies on sensor-specific tuning data. Even if RAW output can be enabled, the absence of a dedicated OV5640 tuning profile may prevent proper ISP operation (AE/AWB/image quality tuning). If your goal is to evaluate the Neo ISP framework itself, it may be easier to use a sensor that is known to work with the NXP ISP stack. Common candidates include: OS08A20 OX03C10 OX05B1S AR0521 AR1335 (may require additional tuning work) Could you share the output of the commands above? That will allow us to confirm whether the current OV5640 configuration is exposing RAW Bayer formats to the system. Best regards, Re: IMX95 Aquila ISP usage Thanks for the reply. I did some additional checks: You were right and the OV5640 was initially running in UYVY mode, but I manually switched one sensor to RAW Bayer (SRGGB8). media-ctl -p now shows: root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] (The second OV5640 remains in UYVY mode for comparison) So : OV5640 -> SRGGB8 CSI -> SRGGB8 Formatter -> SRGGB8 Crossbar -> SRGGB8 => RAW Bayer is successfully propagated through the sensor, CSI and formatter. The neoisp kernel module is loaded: root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 An ISP node is present in the running device tree: /sys/firmware/devicetree/base/soc/isp@4ae00000 => However, I only see a single media device (/dev/media0) exposing the CSI/Formatter/ISI pipeline. No neoisp entity appears in the media graph. I do not see any neoisp entity in the media graph, and I do not know whether this is expected. => cam -l (libcamera) still returns no available cameras. At this point the RAW Bayer path appears functional, but I cannot identify where the Neo ISP becomes part of the active pipeline. How can I verify that the stream is actually processed by the Neo ISP rather than simply following the CSI -> Formatter -> ISI path? Also, is https://www.nxp.com/docs/en/user-guide/UG10215.pdf still the recommended guide for this setup, or is there a more specific reference for OV5640 + Neo ISP on i.MX95? Cordially, Re: IMX95 Aquila ISP usage My current suspicion is that one of the following is happening: OV5640 is running in YUV mode rather than RAW Bayer mode (most likely). The camera DT overlay is not the ISP-enabled variant. The Neo IPA/calibration components are missing from the root filesystem. The media topology seen by the Neo pipeline does not match the expected i.MX95 ISP graph. The media-ctl -p output will usually pinpoint which of these is the actual issue.

打开 SDA 固件问题我购买了 FRDM-A-S32K358 开发板，并检查了 JTAG 端口，以便更改负责 Open SDA 的 MK26 芯片上的固件。如果我误将固件安装到了 J13 上，我将需要获取 Open SDA 固件。在这种情况下，我可以通过提交支持工单来申请获取固件吗？ Re: Open SDA Firmware Question 嗨@wj_kwak 如果 MK26 OpenSDA 设备已通过 J13 覆盖，则标准的 OpenSDA 更新程序可能不再适用，因为它依赖于一个正常工作的 OpenSDA 引导加载程序。OpenSDA 恢复固件通常不以独立编程镜像的形式分发。 OpenSDA 固件和引导加载程序采用的是 PEmicro 技术，而不是 NXP 开发的软件。PEmicro 为 OpenSDA 提供固件更新、引导加载程序更新应用程序及相关支持。因此，如果 MK26 已通过 JTAG/SWD 擦除或重新编程，并且 OpenSDA 引导加载程序不再有效，则 PEmicro 将是恢复指导和固件可用性的主要联系人。 https://www.pemicro.com/support/index.cfm 此致， Lukas

Open SDA Firmware Question I purchased the FRDM-A-S32K358 development board and checked the JTAG port for changing the firmware on the MK26 chip responsible for Open SDA. If I accidentally install the firmware on J13, I will need to obtain the Open SDA firmware. In this case, can I obtain the firmware by requesting it via a support ticket? Re: Open SDA Firmware Question Hi @wj_kwak If the MK26 OpenSDA device has been overwritten via J13, the standard OpenSDA update procedure may no longer be applicable, since it relies on a functioning OpenSDA bootloader. The OpenSDA recovery firmware is not generally distributed as a standalone programming image. The OpenSDA firmware and bootloader are PEmicro technology rather than NXP-developed software. PEmicro provides the firmware updates, bootloader update applications, and related support for OpenSDA. Therefore, if the MK26 has been erased or reprogrammed via JTAG/SWD and the OpenSDA bootloader is no longer functional, PEmicro would be the primary contact for recovery guidance and firmware availability. https://www.pemicro.com/support/index.cfm Regards, Lukas

读取变量时随机出现超时您好，我一直在使用前人在这个项目中搭建的电池测试装置。测试装置使用 nxp S32K144EVB 板，通过 USB 连接到计算机。该代码由 simulink 文件构建，测试监控通过 FreeMASTER 3.2 进行。该项目已在一台笔记本电脑上运行了几个月，现在需要配置一台新的笔记本电脑作为替代品。然而，即使安装相同版本的 FreeMASTER、相同的驱动程序并使用相同的项目文件，所有变量仍然显示为“?”由于在看似随机的时间段后出现超时错误。若能得到任何帮助，我将不胜感激。运行 12 分钟后未发现任何问题，已记录错误：

S32DS arm V1.3 激活码失败您好，我的S32DS Arm V1.3软件激活码已过期。您能帮我延长一下时间吗？我最初的激活码是：FF3F-27C7-FFAB-837F Re: S32DS arm V1.3 activation code failed 你好，现在已经延长了。顺祝商祺！ Peter 回复： S32DS arm V1.3 activation code failed 0D3F-EFEF-B771-DA51我的激活ID是新的，对同版本的软件进行激活，在线激活和离线激活都失败了，失败界面在下面的附件中，希望帮我一起解决一下谢谢

IMX95 Aquila ISP 使用情况你好，我购买了一套 Aquila IMX95 评估套件 2，包含两个 ov5640 传感器（ https://www.toradex.com/cart ）。我有传感器的驱动程序。主板固件已正确刷写，ISP模块已激活： root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 摄像头显示在 libcamera 中： root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) 为了检查 mipis 是否正常，我启动了一个 gstreamer 流水线，并成功地在两个摄像头上都获得了稳定的 30fps 流。我还成功地使用 v4l2-ctl 拍摄了快照。现在，我想用我的摄像头测试一下 Aquila 的 ISP，看看它的表现如何。请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf我添加了环境变量： root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 但是这样做之后，libcamera 就检测不到摄像头了，我不知道为什么： root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# 感谢你的回复！此致敬礼， Re: IMX95 Aquila ISP usage 查看您的日志后，我认为该问题与 MIPI 接口或 OV5640 驱动程序本身无关。事实是： libcamera 检测到了两台 OV5640 摄像头。 GStreamer 可以以 30 fps 的帧率进行流媒体传输。 v4l2-ctl 可以捕获图像这表明传感器驱动程序、I2C 通信、 CSI-2 链接和媒体拓扑结构均运行正常。关键在于 NXP Neo ISP 流水线需要原始的拜耳传感器输入。 OV5640 是一款 SoC 图像传感器，具有自己的内部图像处理流程，在 NXP 电路板支持包中，它通常以 YUV 输出模式（例如 YUV422）使用，而不是作为 RAW Bayer 传感器使用。在这种配置下，可以通过标准的 V4L2/libcamera 流水线使用摄像头，但它不符合 Neo ISP 流水线的要求。这就能解释为什么了： `cam -l` 默认会显示两台 OV5640 摄像头。设置后 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 已检测不到任何摄像头摄像头仍然存在于系统中，但 NEO 流水线处理程序找不到兼容的摄像头拓扑结构，因此没有向 libcamera 公开任何摄像头。为了验证传感器的实际输出格式，请提供以下输出： ```bash media-ctl -p v4l2-ctl --list-formats-ext 我们特别感兴趣的是，该传感器是否支持任何 RAW Bayer 格式，例如： SBGGR8 SBGGR10 SRGGB10 RG10 BA10 如果只有 YUV 格式（例如 YUYV/UYVY）可用，则表示相机未在 RAW 模式下运行，无法通过 Neo ISP 处理流程进行处理。虽然 OV5640 硬件能够输出 RAW Bayer 格式图像，但 BSP 相机驱动程序通常不会启用 RAW 支持，NXP Neo ISP 堆栈也依赖于传感器特定的调整数据。即使启用了 RAW 输出，由于缺少专用的 OV5640 调谐配置文件，可能会阻止 ISP 的正常操作（AE/AWB/图像质量调谐）。如果您的目标是评估 Neo ISP 框架本身，那么使用已知可与 NXP ISP 协议栈配合使用的传感器可能会更容易。常见候选人包括： OS08A20 OX03C10 OX05B1S AR0521 AR1335（可能需要额外调校）能否分享一下上述命令的输出结果？这将使我们能够确认当前的 OV5640 配置是否向系统暴露了 RAW Bayer 格式。此致， Re: IMX95 Aquila ISP usage 谢谢回复。我做了一些额外的检查：您是对的，OV5640 最初运行在UYVY 模式下，但我手动将一个传感器切换到了RAW Bayer (SRGGB8) 。 media-ctl -p 现在显示： root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] （第二个OV5640仍保持UYVY模式，用于对比）所以： OV5640 -> SRGGB8 CSI -> SRGGB8 格式化程序 -> SRGGB8 横杆 -> SRGGB8 => RAW Bayer 成功通过传感器、CSI 和格式化器进行传输。 neoisp内核模块已加载： root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 运行中的设备树中存在 ISP 节点： /sys/firmware/devicetree/base/soc/isp@4ae00000 => 但是，我只看到一个媒体设备（/dev/media0）暴露了 CSI/Formatter/ISI 管道。媒体图中没有出现新独立党派实体。我在媒体图中没有看到任何 neoisp 实体，我不知道这是否正常。 => cam -l (libcamera) 仍然返回没有可用的摄像头。目前看来，RAW Bayer 路径似乎可以正常工作，但我无法确定 Neo ISP 在哪个环节成为活动流程的一部分。如何验证该流是否确实由 Neo ISP 处理，而不是仅仅遵循 CSI -> 格式化程序 -> ISI 路径？另外，请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf对于这种配置，目前还是推荐的指南吗？或者有没有针对 i.MX95 上 OV5640 + Neo ISP 的更具体的参考资料？此致敬礼， Re: IMX95 Aquila ISP usage 我目前怀疑以下情况之一正在发生： OV5640 很可能运行在 YUV 模式而不是 RAW Bayer 模式。摄像头 DT 叠加层不是 ISP 启用版本。根文件系统中缺少 Neo IPA/校准组件。 Neo 管道看到的媒体拓扑结构与预期的 i.MX95 ISP 图不匹配。 media-ctl -p 的输出通常会指出哪个才是真正的问题所在。

S9KEAZN16AM WDOG 时序说明：128 个总线时钟与观察到的 80 微秒和 2.5 毫秒延迟对比你好，我正在与S9KEAZN16AM合作，想了解一下 WDOG 初始化时间的相关问题。配置 MCU：S9KEAZN16AM 总线时钟：16.777216 MHz WDOG 时钟源：1 kHz LPOCLK 重置类型：软件重置（SYSRESETREQ）根据KEA64参考手册，在看门狗解锁序列之后： “解锁序列完成后，用户必须在 128 个总线时钟周期内重新配置看门狗；否则，看门狗将强制 RESET MCU。” 总线时钟频率为 16.777216 MHz： 128 个总线时钟周期 ≈ 7.63 微秒说明为了确保可靠运行，我们目前的实施方案需要以下延迟：软件重置(); SysTick_DelayUs(2500); 禁用中断(); WDOG_Init(&Wdog_cfg); SysTick_DelayUs(80); 启用中断(); 我们发现两个问题：如果移除或减少Software_Reset() 之后的 2.5 毫秒延迟，看门狗计数器并不总是能正确启动/运行。如果移除WDOG_Init() 之后的 80 µs 延迟，看门狗配置将无法始终正确应用。问题 128 总线时钟要求是否仅限于解锁后的配置窗口，还是之后还会进行额外的内部同步？使用1 kHz LPO 时钟是否会引入额外的同步延迟？ RESET后是否存在已知的启动时间要求，可以解释为何需要约 2.5 毫秒？是否有推荐的状态位或轮询机制可以替代固定延迟？主要令人困惑的是，观察到的延迟（ 80 µs 和 2.5 ms ）明显大于记录在案的128 总线时钟（~7.6 µs）要求所隐含的时序。任何指导都将不胜感激。谢谢！

Multi Source Translation Content

Multi Source Translation Content

讨论

2398443_zh-CN

2398374_ja-JP

2398450_en-US

2398215_ja-JP

2398374_zh-CN

2398374_en-US

2398215_en-US

2398215_zh-CN

2398037_zh-CN

2398022_ja-JP

2398147_ja-JP

2398030_ja-JP

2398395_en-US

2398147_en-US

2398022_zh-CN

2398022_en-US

2398395_zh-CN

2398136_zh-CN

2398147_zh-CN

2398030_zh-CN