LPC55S69でUSB HS PLLがロックしない 私はLPCシリーズのマイクロコントローラを用いた初めてのUSB対応製品に取り組んでおり、PHYを直接扱うのはこれが初めてです。これはカスタム基板上で、USB1高速USB接続を使用しています。 現在、dev_cdc_vcom_bm SDKの例を自分のデバイスで動かそうとしています(LPCXpresso55S69の開発ボードでテストした後です)。私のカスタム基板の明らかな違いは、16MHzの水晶発振子ではなく、20MHzの水晶発振子が搭載されている点です。 最初の問題として、PLL_SICレジスタがPLL_LOCKを0と表示しているため、PLLがロックされていないことが分かりました。USBクロック、USB PLL電源、およびUSB PLL有効化が有効になっています。クロック分周器は、20MHzクロックの場合、24で分周するように設定されています（値4）。PLL_PREDIV = 0。USB1_3V3は3.299Vと安定しているので、入力電圧は問題なさそうです。 もう一つの潜在的な問題点は、20MHzの水晶発振器ではなく、20MHzの発振器を使用していることです。別のThreadでそれが問題だと見かけましたが、それはKinetisの部品で、同じIPかどうかはわかりません。たとえそうだとしても、それが論点ずらしだったとしても驚かないだろう。 添付はデバイスの回路図ですが、今回の場合はそれが問題になるはずです。 PLLをロックさせるために、次にどこを調べれば良いか、何か考えはありますか？ LPC55xx Re: USB HS PLL not Locking on LPC55S69 こんにちは、 @martinjaymckee さん。 回路図を見ると、LPC55S69のXTAL32M_PピンはECS-2520MVLC-200-CN発振器の出力から駆動されていますが、XTAL32M_Nは接続されていません。 LPC55S69上のUSB HS PLLは、システム発振器ブロックから基準信号を取得します。SDKの例は通常、結晶がXTAL32M_PとXTAL32M_Nに接続されていることを前提としています。 水晶発振器の代わりに外部クロック源を使用する場合は、発振器ブロックの設定を異なるものにする必要があります。 Harry_Zhang_0-1783589097499.png BR ハリー Re: USB HS PLL not Locking on LPC55S69 なるほど、それはもっともだ。XO32Mはバッファバイパスを使用するように設定済みです。メインクロックPLLが正しい発振器入力を使用していることを確認しました。 USB PLLを動作させるために、XO32Mクロックブロックで他に設定を変更する必要はありますか？

IMX219 (RPi Cam v2) はプローブしますが、標準の imx93-11x11-frdm-imx219 を使用した FRDM-IMX93 上でストリーミングしません 環境 - ボード:FRDM-IMX93(i.MX93 11x11) - BSP:Yocto Scarthgap、linux-imx-6.6.36-2.1.0(カーネルコミット 20d9F5efABDD), MACHINE=imx93frdm, DISTRO=fsl-imx-xwayland - センサ:Raspberry Pi カメラモジュールv2(Sony IMX219)、P6 MIPI-CSIコネクタに搭載 - デバイスツリー:純正のarch/arm64/boot/dts/freescale/imx93-11x11-frdm-imx219.dtso 概要 BSPはこのボード用にIMX219デバイスツリーオーバーレイとセンサを同梱しています 電源が入り、I2Cで正しく検出されます(チップIDは0x10読み0x0219)。しかし、 V4L2キャプチャパイプラインはフレームを一切出力しません。たどってみると、どうやら 下流のステージングカメラドライバーには3つの独立した問題があります。本線 ソニーのIMX219ドライバーは現代のV4L2サブ開発モデルに従っていますが、NXPのステージングは CSI/ISIスタックは依然として古いov5640スタイルモデルを前提としています。 問題1 — メディアグラフの分解(「センサーレジスタが失敗」)。 drivers/staging/media/imx/imx8-media-dev.c: mxc_md_create_links()呼び出し media_entity_call(センサ、link_setupなど)。メインラインのIMX219ドライバーは対応していません 実装.link_setup、したがって、呼び出しは-ENOIOCTLCMD (-515)を返し、次のように扱われます 致命的だ。センサー>CSIリンクは一度も作成されず、メディア機器全体が解体されます: mx8-img-md: 登録センサーサブデバイス: imx219 2-0010 (1) mx8-img-md: created link [mxc_isi.0]=> [mxc_isi.0.capture] mx8-img-md: リンク [mxc-mipi-csi2.0] を作成しました=> [mxc_isi.0] mx8-img-md: subdev_notifier_complete エラー終了 mxc-md 42800000.bus:camera:センサーレジスタが故障しました MXC-MD:42800000のプローブ。バス:カメラエラー -515 で失敗しました (ov5640 は ov5640.c のおかげで動作します)（何もしない.link_setupを提供します。） 問題2 — streamonが中止(「サブ開発者に失敗s_power呼べ!」) ドライバ/ステージング/プレスリリース、製品ニュース/IMX/IMX8-ISI-cap.C: mxc_isi_cap_streamon() が呼び出します v4l2_subdev_call(src_sd, core, s_power, 1) は、失敗を致命的として扱います。imx219は ランタイム PM であり、非推奨の .s_power を実装していません。そうするとコールが戻ってきます -ENOIOCTLCMDとストリーミング中止: mxc_isi.0:サブデバイスs_powerの呼び出しに失敗しました！ (ov5640 は ov5640.c のおかげで動作します).s_power を提供します。 問題3 — CSIがYUV422にハードコードされているが、RAW10を解析できない(リンクはあるがフレームは0) ドライバ/staging/media/imx/dwc-mipi-csi2.c は実質的に YUV422 専用です: - dwc_csi2h_formats[]はSBGGRのバイヤーコードのみを記載しており、SRGGBは含まれていません(IMX219はSRGGB10です)。 したがってfind_csi2h_format()は失敗し、フォーマットは静かにYUYVに戻ります。 - dwc_mipi_csi2_set_fmt() は CSI2H-> フォーマットを保存しないため、disp_mix_gasket_config() デフォルトのYUYVコードが表示されます。 - dwc_mipi_csi2_param_init() ハードコード ipi_cfg->data_type = DT_YUV422_8。 CSI は誤ったデータタイプを報告し、すべてのフレームがキャプチャされるにもかかわらず、フレームはキャプチャされません。 リンクが有効で、VIDIOC_STREAMONが0を返します。 mxc-mipi-csi2.0: フォーマット: 0x2008 <- YUYV; 期待値: 0x300f (SRGGB10) 私たちが成功した理由（ご検証のため） (a) imx8-media-dev / imx8-isi-cap に欠落したオプション操作を処理した後 (-ENOIOCTLCMD、link_setup / s_power)非致死的であり、(b)教えること dwc-mipi-csi2 について SRGGB8/10/12(交渉されたフォーマットを保存し、IPIを設定する) data_typeから)パイプラインは正しく表示されます:- MXC-mipi-csi2.0:フォーマット: 0x300f imx219 -> mxc-mipi-csi2.0 -> mxc_isi.0-> /dev/video0 約27fps、ライブフレームをキャプチャ。 修正(a)はセンサーに依存しず、このスタック上の現代的なメインラインセンサーにも役立ちます。 修正(b)はCSIにRAWバイヤーサポートを追加します。 副次的な注意点 — モジュールのロードオーダー 新規起動時にも、imx8_media_dev が実行されることによりグラフの登録に失敗します。 imx219モジュールがロードされる前に非同期通知器がロードされます。ビデオノードが登録され、 その後、登録が解除された。マニュアル「modprobe -r imx8_media_dev imx219; modprobe imx219;」 「modprobe imx8_media_dev」を実行すると、それが再構築されます。ソフト依存関係/ロード順序のヒントがあれば、 既成概念にとらわれずに仕事をする。 質問 1.IMX219 はこの BSP の FRDM-IMX93 で公式にサポート/検証されたカメラですか、 意図された/検証済みのパスは、AP1302 ISPモジュールですか？出荷されたimx219.dtso bare-IMX219は動作するはずだと示唆している。 2. 上記の3つの動作は、修正を受け入れるバグとみなされますか、それとも 推奨される構成や、動作確認済みの構成で、私たちが見落としているものはありますか？ 3.もしお役に立てるようでしたら、パッチをクリーンなコミットとして共有させていただきます。 ありがとう！ FRDM-i.MX93 #IMX219 RPI-CAM-MIPI Yocto Project Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 こんにちは、 ご連絡ありがとうございます。ソフトウェアチームに確認し、後のBSPで修正があるか再度確認します。できるだけ早く更新します。 よろしくお願いいたします。 アルド。 Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 こんにちは、 残念ながら、i.MX93 FRDM BSPは、後になってこの問題を調査していた際に、当社のBSPで正式にサポートされるまでサポートされていませんでした。そのため、このイメージは、同じBSPのベータ版である可能性があります。 FRDMボードは6.12.34から2.1.0までサポートしていますそして後のリリースについては、あなたの発見に感謝しますし、ボードに含まれるデフォルト画像を使って検証する方にとって役立つはずです。ソフトウェアチームで追跡します。 よろしくお願いいたします。 アルド。

S32K328:CM7_0 CM7_2 DTCMバックドアへのアクセスが不正確なバスフォールトを引き起こす NXPチームの皆様、こんにちは。   当社では、RTD 7.xを搭載したS32K328を使用しています。   ソフトウェアのセットアップ： - CM7_0はブートローダーを実行します。 - CM7_1は第二のアプリケーションで使用されます。 - CM7_2はアプリケーションコードの実行を目的としていません。 - TCMバックドア/AHBS経路を通じてCM7_2 DTCMをシステムメモリとして使用できるかどうかCM7_0評価しています。   リファレンス・マニュアルの文脈: 「メモリマップ」章では、ITCM/DTCMは他のマスター、特にCortex-M7コアやeDMAから32ビットAHBSインターフェースからアクセス可能であると述べられています。 「TCMをシステムメモリとして」のセクションでは、有効化されたコアは無効化または待機中のコアのTCMを以下以下で使用可能とされています: 1. ターゲットコアTCMコントローラクロックの有効化: MC_ME PRTN2_COFB2_CLKEN[REQ64] for Cortex-M7_2 2. ターゲットコアCPUWAITの設定: DCM_GPR DCMRWF4[CM7_2_CPUWAIT] 3. ターゲットコアクロック/アクセスパスの有効化: MC_ME PRTN0_CORE4_PCONF[CCE]   私たちが試したこと： 1. DCM_GPR DCMRWF4[CM7_2_CPUWAIT]を設定します。 2. MC_ME PRTN2_COFB2_CLKEN[REQ64]を設定します。 3. MC_ME PRTN2_PUPD[PCUD]を設定します。 4. MC_ME CTL_KEYシーケンスを適用しました。 5. PRTN2_PUPD[PCUD]がクリアされるまで待機しました。 6. PRTN2_COFB2_STATを読み取り、bit0/BLOCK64がアクティブであることを確認した。 7. MC_ME PRTN0_CORE4_PCONF[CCE]を設定します。 8. MC_ME PRTN0_CORE4_PUPD[CCUPD]を設定します。 9. MC_ME CTL_KEYシーケンスを適用しました。 10. PRTN0_CORE4_STAT[CCS]が1になるまで待機しました。 11. 実験のため、MPUを一時的に無効にした。 12. CM7_2 DTCMバックドアアドレスへの32ビット書き込みを1回試行しました。   観測結果： - PRTN2_COFB2_STATはTCMコントローラのクロック要求がアクティブであることを示します。 - PRTN0_CORE4_STAT[CCS] が 1 になります。 - CM7_2 DTCMバックドア領域への最初の32ビット書き込みにより、不正確なバスフォルトが発生し、ハードフォルトにエスカレートします。   質問: 1.S32K328の場合、CM7_0からアクセス可能な正しいCM7_2 DTCMバックドア/システムアドレス範囲は何ですか？ 2. CM7_2 CM7_0 CM7_2がCPU待機中にいる間、DTCMバックドアアクセスはサポートされていますか? 3.MC_MEとDCM_GPRの設定以外に、CM7_0がCM7_2のDTCMバックドアに書き込めるようにするには、XRDCの設定が必要ですか？ 4. テストのためにMPUを一時的に無効にした場合でも、MPU領域は必要ですか？ 5. TCMバックドアパスを使用する前に、MSCM/MCM/XBIC/ENEDCの設定が必要ですか？ 6.PRTN2_COFB2_STAT[BLOCK64]はTCMコントローラークロックが有効であることCM7_2確認するための正しいステータスビットでしょうか? 7. PRTN0_CORE4_STAT[CCS]は、クロック/アクセスパスが有効であることCM7_2確認するための正しいステータスビットでしょうか? 8. バックドアアクセスによるDTCM ECC初期化の場合、CM7_0からの32ビット書き込みで十分でしょうか? 9. 最初のバックドア書き込みによって不正確なバスフォルトが発生した場合、その障害がXRDC、インターコネクト、またはマッピングされていないアドレスのいずれに起因するものかを特定するために、どのフォルト/XRDCレジスタをチェックする必要がありますか？   現在の目標： 私たちは最小限の煙試験のみを検証したいのです。 - CM7_2 DTCMバックドアへの32ビット書き込み1回、 - それから読み返します、 - 生産用途を検討する前に。   よろしくお願いします。 Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault こんにちは、 @krishna_Bugudi さん、 1. S32K3xx_memory_map.xlsx を参照してください。DTCM_2 バックドア (アドレス 0x21800000) 2. はい 3. なし 4. なし 5. なし 6. はい、RMのセクション3.4「TCMをシステムメモリとして」を参照してください。 7. はい 8. はい、RMの表102を参照してください。メモリECC初期化の概要 9. XRDCが無効になっていると書かれていましたね。したがって、XRDCによって報告されることはない。 住所はどこに書きますか？ よろしくお願いいたします。 ダニエル Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault こんにちは、ダニエルさん。   ご確認いただきありがとうございます。   テストを更新してRM/NXPの手順に完全に準拠するようにしましたが、依然としてストアのハングアップが発生しています。   確認済みの住所： 私たちは以下の宛先に手紙を書いています。   0x21800000   これはS32K3xx_memory_map.xlsxと一致します。   DTCM_2 バックドア: - 開始アドレス: 0x21800000 - 終了アドレス: 0x2181FFFF - S32K328実装サイズ：128KB   メモリマップには、PRAM2_TCM_XBICがS32K328の以下の場所に存在することも示されています。 0x40408000 - 0x4040BFFF   そしてそれを次のように説明しています。 「クロスバー整合性チェッカー（PRAM2およびTCMバックドアAHBスプリッター）」   一方、0x40400000 の TCM_XBIC は S32K328 用に予約済みとしてマークされています。   最新のテストシーケンス：   1. MC_ME PRTN2_COFB2_CLKEN[REQ64]を設定します。 2. MC_ME PRTN2_PUPD[PCUD]を設定します。 3. MC_ME CTL_KEYシーケンスを適用します。 4. PRTN2_PUPD[PCUD]がクリアされるまで待ちます。 5. PRTN2_COFB2_STATを読み込む。   観察結果： PRTN2_COFB2_STAT = 0x00000039   6. DCM_GPR DCMRWF4[CM7_2_CPUWAIT]を設定します。 読み上げ確認： DCMRWF4 = 0x00080000   7. MC_ME PRTN0_CORE4_ADDR を安全なループアドレスに設定します。 読み返し: PRTN0_CORE4_ADDR = 0x00402408   8. MC_ME PRTN0_CORE4_PCONF[CCE]を設定します。 9. MC_ME PRTN0_CORE4_PUPD[CCUPD]を設定します。 10. MC_ME CTL_KEYシーケンスを適用します。 11. PRTN0_CORE4_STAT[CCS]が1になるまで待ちます。   観察結果： PRTN0_CORE4_STAT = 0x00000001   12. MPU CM7_0一時的に無効化して隔離する。 無効化前のMPU_CTRL = 0x00000003   13. 32ビット書き込みを1回試行します。   *(volatile uint32_t *)0x21800000 = 0u;   最新のパンくずリスト：   [CORE2_DTCM_SMOKE] S4B: WORD0 書き込み開始アドレス=0x21800000   店舗の次のパンくずリストに到達していません。   [CORE2_DTCM_SMOKE] S4B1: DSBの前にWORD0ストアが発行されました   そのため、ストア自体が次の指示に到達する前に停止したり完了しないように見えます。今回の最新のテストでは、DSB（深層破壊領域）には到達していません。   質問： あなたが確認した内容： - 0x21800000 は正しい DTCM_2 バックドア アドレスです。 - CM7_2がCPUWAIT中である間はCM7_0アクセスがサポートされます。 - XRDC/MPU/MSCM/MCM/XBIC/ENEDC の追加設定は不要です。 - PRTN2_COFB2_STAT[BLOCK64] は正しいステータスビットです。 - PRTN0_CORE4_STAT[CCS] は正しいステータスビットです。 - 32ビット書き込みはDTCM ECC初期化に有効です。   最初の32ビットストアが完成前に0x21800000止まる原因は何でしょうか?   S32K328のPRAM2_TCM_XBIC（アドレス0x40408000）でTCMバックドアAHBスプリッタエラーを検査すべきでしょうか？   もしそうなら、以下の場所を教えていただけますか: 1.PRAM2_TCM_XBIC ステータス/エラーレジスタを読み取ります。 2. DTCM_2バックドアトランザクションの失敗時に想定されるエラー表示。 3. アクセスを再試行する前にエラークリアシーケンスが必要かどうか。 4. ストアが完了しなかった場合にキャプチャする必要のあるその他の MC_ME/DCM/MSCM/XBIC/fault レジスタ。   よろしくお願いいたします。 クリシュナ Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault こんにちは、クリシュナさん。 Copilot は次のように述べています。「テストしたところ、プロジェクトでデフォルトの MPU が有効になっている場合 (system.c で設定) にのみこのエラーを再現できました。」S32DS RTDプロジェクトによって生成されました。プロジェクトでMPUが無効化されているかどうかを確認するためにMPUレジスタをダンプすることはできますか? よろしくお願いいたします。 ダニエル

MCUXpresso SDK 支持 Ezurio Sona NX611 你好， MCUXpresso SDK FreeRTOS 是否支持 Ezurio Sona NX611 无线网卡？因为它使用的是NXP IW611无线电芯片，所以我认为应该可以支持，对吗？ Re: Ezurio Sona NX611 support in MCUXpresso SDK 你好， 希望你一切都好。我建议您直接查看我们任何 SDK 示例的配置以及支持的模块。 例如，在 iMX RT1170 的 wifi_cli 中，您可以找到以下模块：   Ricardo_Zamora_1-1782508762868.png 如果您正在寻找其他模块，则需要自行添加特定支持，并以 IW61x 的可用启用功能为基础。 顺祝商祺！ 里卡多 Re: Ezurio Sona NX611 support in MCUXpresso SDK 谢谢。如何添加对该模块的特定支持？我看到 mcuxsdk/components/wifi_bt_module/ /tx_pwr_limits 中每个模块都有特定的设置。此外， mcuxsdk/中间件/wifi_nxp/incl/目录下还有多个校准数据头文件，例如wifi_cal_data_override.h ，其内容如下：“客户可以覆盖 ext_cal_data[] 中的数据以设置特定的天线校准数据”。 如何为新模块正确设置这些参数（功率限制和校准数据）？ 是否有关于如何添加对新无线模块支持的完整手册？我的芯片是基于 IW611 的，所以我想我可以参考 NXP IW611-MURATA-2DL-M2，但我怎么知道我是否需要更改任何值呢？ Re: Ezurio Sona NX611 support in MCUXpresso SDK 谢谢你， @Ricardo_Zamora 。 我选择了 NXP-IW611-MURATA-2DL-M2 卡，因为 Ezurio Sona NX611 使用的是相同的芯片 (IW611)，我认为它应该可以工作。但是，当 SDK 代码尝试将固件下载到无线网卡时，出现以下错误： 09/07/2026 13:04:32.589 [RX] - [FW Download] Start to download firmware from 0x60143230: 727 09/07/2026 13:04:38.560 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_init failed. status code -1 [wlcm] Error: wifi init/reinit failed. status code -1 [!] WPL_Init: Failed, error: 1 我知道 Sona NX611 不在支持的模块列表中，但我认为它应该仍然可以工作，因为它与某个支持的板共享无线芯片型号 IW611。 Re: Ezurio Sona NX611 support in MCUXpresso SDK 你好， 我建议选择 Ezurio，他们能提供针对该模块的特定支持。不同模块合作伙伴的具体实施方案可能有所不同。 此致， 里卡多

ADC向けモジュール選択アプリケーション MXPボードを中心にアプリケーションを開発し始めたいのですが、使える特定の計算モジュールを選ぶのに苦労しています。種類が多すぎて少し圧倒されていて、どの製品が本当に自分の必要を満たしてくれるのか分かりません。 私の理解では、ADCを提供するSoCは複数存在する。より高い計算能力と、少なくとも4つのADCチャネルが必要です。どの特定の開発ボードを使い、どのモジュールやボードを使ってこのアプリケーションを作ればよいのでしょうか?購入可能な基板の選定を手伝ってくれるサプライヤーはありますか? Re: Module selection for ADC application MPUは十分な処理能力を確保するためだと思いますし、消費電力やコストをあまり心配しないからです。私たちはProfinetを利用できることにも関心があります。そして、1チャネルあたり100ksps以上のADCチャネルが少なくとも4つあるはずです。私の理解では、i.MX 9 MPUが適合する可能性があると思います。 私が考えている代替案としては、別々のADCモジュールとイーサネットモジュールを持つRaspberry Pi Picoを買うことです。しかし、NXPのシステムなら私のニーズをすべて満たしてくれるはずだと私は考えています。しかし、特定のチップで妥協しても製品の種類が非常に多様で、私にとって最も重要な機能である適切なADCが手に入るかどうかはしばしば不透明です。 Re: Module selection for ADC application こんにちは、 何を探しているのですか? これはMCUですか?MPUですか? プロジェクトについてさらに詳しい情報を提供していただければ、その点でお手伝いできます。 また、ウェブページ内に商品検索機能もあります https://www.nxp.com/design/design-center/development-boards-and-designs:EVDEBRDSSYS?collection=devBoardsDesigns&start=0&max=12&language=en&query=typeTax%3E%3Et633_t763 敬具/サルドス、 アルド。 Re: Module selection for ADC application こんにちは、 はい、どのi.MX9ファミリーでも使えるはずです。グラフィックやその他のペリフェラルによって、どちらがあなたの用途に合うかによります。 そのため、i.MX91、i.MX93、i.MX95はFRDMボードを搭載し、ADCの仕様も同じです: • 8チャネルで構成されており、そのうち4チャネルはパッケージ内のピンに接続されています。 • 1MS/sの動作周波数をサポートします • 複数の開始変換モード(通常、注入) ノーマルモードではワンショットおよびスキャン(連続)変換に対応しています インジェクターモードはワンショット変換のみに対応しています • 任意のADCチャネルで16のトリガーチャネルを使用可能にするTRGMUXのサポート i.MX93 https://www.nxp.com/products/i.MX93 i.MX93 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 i.MX91 https://www.nxp.com/products/i.MX91 i.MX91 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91 i.MX95 https://www.nxp.com/products/i.MX95 i.MX95 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX95 また、それぞれのEVKも確認してみると良いでしょう。RPIについて言及されているので、FRDMボードがあなたにとって興味深いものになると思います。 よろしくお願いいたします。 アルド。

LPC55S69上的USB HS PLL无法锁定 我正在开发我的第一个采用 LPC 系列微控制器的 USB 产品，这也是我第一次直接操作 PHY。这是在定制电路板上，使用 USB1 高速 USB 连接。 我目前正在尝试让 dev_cdc_vcom_bm SDK 示例在我的设备上运行（在 LPCXpresso55S69 开发板上测试之后）。我的定制电路板最明显的区别在于它安装的是 20MHz 晶振而不是 16MHz 晶振。 我找到的第一个问题是 PLL_SIC 寄存器显示 PLL_LOCK 为 0，因此 PLL 没有锁定。USB时钟、USB PLL电源和USB PLL使能已启用。时钟分频器设置为 24 分频（值 4），用于 20MHz 时钟。PLL_PREDIV = 0。USB1_3V3 读取到稳定的 3.299v，因此输入电压似乎正常。 另一个潜在的问题是，我使用的是 20MHz 振荡器，而不是 20MHz 晶体振荡器。我看到另一个帖子也遇到了同样的问题，但那是 Kinetis 的一个部件，我不确定是不是同一个 IP。即便如此，如果这只是个转移视线的伎俩，我也不会感到惊讶。 附件是该设备的原理图，不过这应该不是问题所在。 关于如何使PLL锁定，您有什么下一步的考虑方向吗？ LPC55xx Re: USB HS PLL not Locking on LPC55S69 嗨@martinjaymckee 从你的原理图来看，LPC55S69 XTAL32M_P 引脚由 ECS-2520MVLC-200-CN 振荡器输出驱动，而 XTAL32M_N 引脚则未连接。 LPC55S69 上的 USB HS PLL 的参考信号来自系统振荡器模块。SDK 示例通常假设 XTAL32M_P 和 XTAL32M_N 之间连接有晶体。 当使用外部时钟源而不是晶体时，振荡器模块的配置方式应该有所不同。 Harry_Zhang_0-1783589097499.png BR 哈里 Re: USB HS PLL not Locking on LPC55S69 好吧，这很合理。我已经将 XO32M 配置为使用缓冲区旁路。我已经确认主时钟PLL使用的是正确的振荡器输入。 我还需要更改 XO32M 时钟模块的其他配置才能使 USB PLL 工作吗？

32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) I am currently trying to configure a 32-bit parallel Shifter to receive data from an external device with one of the pins (FLEX_D4/DATA_VALID) being used as a signal to Shift in the data.  The progress I have made has allowed me to read in the 32-bit data when DATA_VALID has triggered and move the data into an eDMA Ping-Pong buffer. I am currently testing through Printf statements of reading the buffer data to a console and if the Shifter has any errors (usually indicating Overrun according to the datasheet) they will print to the console as well.  I believe my main issue is with the TimerConfig as it is triggering the Shifter to read too many times on one rising edge of DATA_VALID but I have not found a configuration that allows me to read only once while actually moving the correct data.  Console Output:  Reading Buffer A: 0x3fffefff Shifter Error Code: 0x8 Shifter Status: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMA Error: 0x0 TCD BITER: 0x2 CSR: 0x12 CH_MUX: 0x40 Reading Buffer B: 0x3fffefff Shifter Error Code: 0x8 Shifter Status: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMA Error: 0x0 TCD BITER: 0x2 CSR: 0x12 My FLEX_IO setup is attached. Thank you. Clock|Timers Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Development Board MCXN Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Update: I was able to deduce that "kFLEXIO_TimerDisableOnTriggerFallingEdge" was keeping my CPU in the callback. I believe I want to disable after a Timer Compare but with this option SHIFTBUF only reports a value of 0x0 but with no SHIFTERR flag.  Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Hi  @Flexin_On_The_IO  Thank you for your post! Could you please share the current behavior you see in your register?  Which test data are you trying to receive and what you currently get?  Could you please share which MCXN are you using?  Is it a custom board? if not, please specify the board you are using Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Hi @carlos_o thank you for the reply! I was able to get the Timer reading on DATA_VALID edge like I wanted but did not update the thread. My current code is attached. The problem I am facing now is getting the FlexIO to keep up with other devices. In my current setup I am basically sampling DATA_VALID and at higher speeds, the Shifter can get Overrun. My thinking is that my design requires a shared clock between the MCX & host device that would be sending the 32-bit data. I can use a pin within the 32-bit data bus to be this signal so I do not need to breakup the FlexIO pins. Any input on this idea would be welcome! To answer your previous questions: 1. The registers are populating as intended at lower speeds. On every DATA_VALID falling edge, the SHIFTBUF stores data from the 32 Pins and the EDMA transfers to my Ping-Pong buffer via a Scatter-Gather method. 2. I am simulating input through an Analog Discovery 2, since that only has 16 data pins I am just writing the upper values of the 32-bits, simulating a clock on the DATA_VALID pin, and tying the unused pins down. Test data is matching correctly at low speeds. 3. I am using the FRDM-MCXN947 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Hi @Flexin_On_The_IO  Apologize the late reply,  Could you please specify the speeds you are trying to achieve?  You could review AN14284: Timing Parameter Tuning for FlexIO Emulated Interface, this app note could have some helpful information to your goal.    Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Hello again, @carlos_o  The bare minimum speed I am trying to reach is 18.5MHz. I can confirm the Shifter does keep up at around 6.25MHz but I was having issues at higher speeds due to my hardware limitations :P.  Below is my Analog Discovery 2 waveform where I am just providing the MCLK signal, a binary counter for the data (12-bit only due to low pin count on AD2), and manually controlling the DATA_VALID signal.  Flexin_On_The_IO_0-1783689475176.png When I get to higher frequencies (20 MHz) I realize the AD2 cannot actually provide a decent square wave and may be causing my FRDM to trigger undesired Shifts due bad signal integrity.  Flexin_On_The_IO_1-1783690391552.png I was looking at the file you sent me and I think it may be a solution to an issue I want to take care of. If DATA_VALID rises/falls at the same time as MCLK I believe it misses the a Shift of data since the clock was not able to fully decrement. My main question is do the Shifters usually require a delayed clock/Timer in order to complete their full shift cycle even after the Trigger from the other device has gone low? My current setup requires the DATA_VALID to remain high between MCLK edges to not miss the data.

S32K328：CM7_0 访问 CM7_2 DTCM 后门导致总线故障不精确 您好，NXP团队，   我们正在使用 S32K328 和 RTD 7.x。   软件设置: - CM7_0 运行引导加载程序。 - CM7_1 被第二个应用程序使用。 - CM7_2 不用于执行应用程序代码。 - 我们正在评估 CM7_0 是否可以通过 TCM 后门/AHBS 路径使用 CM7_2 DTCM 作为系统内存。   参考手册内容： “内存映射”章节指出，其他主设备（包括其他 Cortex-M7 内核和 eDMA）可以通过 32 位 AHBS 接口访问 ITCM/DTCM。 “TCM 作为系统内存”部分指出，已启用的核心可以在以下情况下使用已禁用/等待的核心的 TCM： 1. 启用目标核心 TCM 控制器时钟： MC_ME PRTN2_COFB2_CLKEN[REQ64] 适用于 Cortex-M7_2 2. 设置目标核心 CPUWAIT： DCM_GPR DCMRWF4[CM7_2_CPUWAIT] 3. 启用目标内核时钟/访问路径： MC_ME PRTN0_CORE4_PCONF[CCE]   我们尝试了： 1. 设置 DCM_GPR DCMRWF4[CM7_2_CPUWAIT]。 2. 设置 MC_ME PRTN2_COFB2_CLKEN[REQ64]。 3. 设置 MC_ME PRTN2_PUPD[PCUD]。 4. 应用 MC_ME CTL_KEY 序列。 5. 等待 PRTN2_PUPD[PCUD] 清除。 6. 读取 PRTN2_COFB2_STAT 并观察到 bit0/BLOCK64 处于活动状态。 7. 设置 MC_ME PRTN0_CORE4_PCONF[CCE]。 8. 设置 MC_ME PRTN0_CORE4_PUPD[CCUPD]。 9. 应用 MC_ME CTL_KEY 序列。 10. 等待 PRTN0_CORE4_STAT[CCS] 变为 1。 11. 为进行实验，暂时禁用了 MPU。 12. 尝试向 CM7_2 DTCM 后门地址进行一次 32 位写入。   观察到的结果： - PRTN2_COFB2_STAT 表示 TCM 控制器时钟请求处于活动状态。 - PRTN0_CORE4_STAT[CCS] 变为 1。 - 首次向 CM7_2 DTCM 后门区域写入 32 位数据会导致不精确的 BusFault 升级为 HardFault。   问题： 1.对于 S32K328，从 CM7_0 可访问的正确 CM7_2 DTCM 后门/系统地址范围是什么？ 2. 当 CM7_2 处于 CPUWAIT 状态时，是否支持从 CM7_0 访问 CM7_2 DTCM 后门？ 3.除了 MC_ME 和 DCM_GPR 设置之外，是否还需要任何 XRDC 配置才能允许 CM7_0 写入 CM7_2 DTCM 后门？ 4. 即使在测试中暂时禁用 MPU，是否也需要任何 MPU 区域？ 5. 使用 TCM 后门路径之前是否需要进行任何 MSCM/MCM/XBIC/ENEDC 设置？ 6.PRTN2_COFB2_STAT[BLOCK64] 是否是确认 CM7_2 TCM 控制器时钟是否活动的正确状态位？ 7. PRTN0_CORE4_STAT[CCS] 是否是确认 CM7_2 时钟/访问路径是否处于活动的正确状态位？ 8. 对于通过后门访问进行 DTCM ECC 初始化，从 CM7_0 写入 32 位是否足够？ 9. 如果第一次后门写入导致不精确的总线故障，应该检查哪些故障/XRDC 寄存器来确定故障是由于 XRDC、互连还是未映射地址引起的？   当前目标： 我们只想验证一个最基本的冒烟测试： - 对 CM7_2 DTCM 后门进行一次 32 位写入， 然后回读， 在考虑任何生产用途之前。   谢谢！ Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault 你好@krishna_Bugudi ， 1. 请参阅 S32K3xx_memory_map.xlsx 文件，DTCM_2 后门位于 0x21800000 2. 是 3. 无 4. 无 5. 无 6. 是的，请参阅 RM 第 3.4 节 TCM，即系统内存。 7. 是 8. 是的，请参阅 RM，表 102。内存 ECC 初始化摘要 9. 您提到XRDC已被禁用。因此，XRDC 不会报告此问题。 你要写什么地址？ 此致， 丹尼尔 Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault 你好，丹尼尔，   谢谢你的确认。   我们已更新测试，使其完全按照 RM/NXP 的顺序执行，但仍然看到商店挂起。   已确认地址： 我们写信给：   0x21800000   这与 S32K3xx_memory_map.xlsx 匹配：   DTCM_2 后门： 起始地址：0x21800000 - 结束地址：0x2181FFFF - S32K328 实现大小：128 KB   内存映射表还显示 PRAM2_TCM_XBIC 位于 S32K328 的以下位置： 0x40408000 - 0x4040BFFF   并将其描述为： “横杆完整性检查器（PRAM2 和 TCM 后门 AHB 分线器）”   TCM_XBIC 位于 0x40400000，标记为 S32K328 保留。   最新测试序列：   1. 设置 MC_ME PRTN2_COFB2_CLKEN[REQ64]。 2. 设置 MC_ME PRTN2_PUPD[PCUD]。 3. 应用 MC_ME CTL_KEY 序列。 4. 等待 PRTN2_PUPD[PCUD] 清除。 5. 读取 PRTN2_COFB2_STAT。   观察到： PRTN2_COFB2_STAT = 0x00000039   6. 设置 DCM_GPR DCMRWF4[CM7_2_CPUWAIT]。 回读确认： DCMRWF4 = 0x00080000   7. 将 MC_ME PRTN0_CORE4_ADDR 设置为安全循环地址。 回读： PRTN0_CORE4_ADDR = 0x00402408   8. 设置 MC_ME PRTN0_CORE4_PCONF[CCE]。 9. 设置 MC_ME PRTN0_CORE4_PUPD[CCUPD]。 10. 应用 MC_ME CTL_KEY 序列。 11. 等待 PRTN0_CORE4_STAT[CCS] 变为 1。   观察到： PRTN0_CORE4_STAT = 0x00000001   12. 暂时禁用 CM7_0 MPU 进行隔离。 禁用前的 MPU_CTRL = 0x00000003   13. 尝试一次 32 位写入操作：   *(volatile uint32_t *)0x21800000 = 0u;   最新面包屑日志：   [CORE2_DTCM_SMOKE] S4B：WORD0 写入开始地址=0x21800000   商店之后的下一个面包屑导航：   [CORE2_DTCM_SMOKE] S4B1：WORD0 存储于 DSB 之前   因此，商店本身似乎在执行到以下指令之前就停滞不前或未能完成。在最新的测试中，DSB 并未达到。   问题： 既然你已经确认了这一点： - 0x21800000 是正确的 DTCM_2 后门地址， - 当 CM7_2 处于 CPUWAIT 状态时，支持对 CM7_0 的访问， - 无需额外的 XRDC/MPU/MSCM/MCM/XBIC/ENEDC 设置， - PRTN2_COFB2_STAT[BLOCK64] 是正确的状态位， - PRTN0_CORE4_STAT[CCS] 是正确的状态位， - 32 位写入对 DTCM ECC 初始化有效，   什么原因会导致第一次 32 位存储到 0x21800000 的操作在完成前停滞？   我们是否应该检查 S32K328 上 0x40408000 处的 PRAM2_TCM_XBIC 是否存在 TCM 后门 AHB 分路器错误？   如果可以，请您提供以下信息： 1.要读取的 PRAM2_TCM_XBIC 状态/错误寄存器。 2. DTCM_2 后门交易失败的预期错误指示。 3. 在重试访问之前是否需要任何错误清除序列。 4. 当存储操作未完成时，应捕获的任何其他 MC_ME/DCM/MSCM/XBIC/故障寄存器。   此致， 克里希那 Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault 你好，克里希纳， Copilot 说：我已经测试过了，只有当项目中启用默认 MPU（在 system.c 中配置）时才会出现此错误。由 S32DS RTD 项目生成）。能否导出 MPU 寄存器，以验证您的项目中是否禁用了 MPU？ 此致， 丹尼尔

i.MX8MPLUS uSDHC HS400モード（ストロボ機能強化） HS400の強化ストロボを有効にするための推奨手順はありますか？MIX_CTRLレジスタのEN_HS400_MODEを設定するだけで十分でしょうか、それともSTROBE_DLL_CTRLレジスタに追加の変更が必要でしょうか？ よろしくお願いいたします。 ステファン Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe こんにちは、 @Stefan_CIT HS400ESでは、eMMC側とホスト側の両方で同時に設定を行う必要があります。EN_HS400_MODEを設定するだけでは、ホスト側の設定の一部に過ぎず、HS400拡張ストロボ機能を有効にするには不十分です。 Linux BSPを使っている場合、ドライバーは自動的にDLLとチューニングの設定を完成させます。 よろしくお願いします、 志明 Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe こんにちは@Zhiming_Liu ご返信ありがとうございます。 私たちは #I.MX8MPLUSとINTEGRITY OSを使い、uSDHC-ドライバは自分たちで管理しています。そこで、Linuxドライバからプロセスを移行してみます よろしくお願いいたします。 ステファン Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe ストローブDLLと強化ストロボモードへの切り替えについては、参考マニュアルにより良いドキュメントがあります。 https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf i.MX9プロセッサは同じuSDHC-IPを持っているようです。 よろしくお願いいたします。 ステファン

无法在 Zephyr 的单个 FlexSPI 上配置两个或非闪存 您好， 我正在使用基于 i.mx RT1050 板的板。有两个 NOR 闪光灯连接到 flexspi 的两组闪光灯。我还使用库 1 来启动 XIP。当我只使用一个闪光灯时，它工作正常。但当我添加第二个闪光灯时，我遇到了一个问题，似乎 LUT 的空间不足。我的两个闪光灯是 w25q128 和 w25q64，分别连接到 flexspi 端口 A1 和 B1。   这是我在叠加文件中的配置。   / { chosen { zephyr,flash-controller = &w25q128jv; zephyr,flash = &w25q128jv; zephyr,code-partition = &slot0_partition; }; };   &flexspi { status = "okay"; rx-clock-source = <1>; pinctrl-0 = <&pinmux_flexspi1>; pinctrl-names = "default"; reg = <0x402a8000 0x4000>, <0x60000000 DT_SIZE_M(64)>; /delete-node/ is25wp064@0; w25q128jv: w25q128jv@0 { compatible = "nxp,imx-flexspi-nor"; size = ; reg = <0>; spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 70 18]; erase-block-size = ; write-block-size = <16>; enter-4byte-addr = <0>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; boot_partition: partition@0 { label = "mcuboot"; reg = <0x00000000 DT_SIZE_K(256)>; }; /* Adjusted slot sizes for 16MB total */ slot0_partition: partition@20000 { label = "image-0"; reg = <0x00040000 (DT_SIZE_M(3) + DT_SIZE_K(512))>; }; slot1_partition: partition@320000 { label = "image-1"; reg = <0x00320000 DT_SIZE_M(3)>; }; storage_partition: partition@620000 { label = "storage"; reg = <0x00620000 (DT_SIZE_M(1) - DT_SIZE_K(768))>; }; }; }; w25q64jv: w25q64jv@2 { compatible = "nxp,imx-flexspi-nor"; size = ; /* 8MB (64Mbit) flash */ reg = <2>; /* FlexSPI B */ spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 40 17]; /* Winbond W25Q64JV JEDEC ID */ erase-block-size = ; write-block-size = <16>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; data_partition: partition@0 { label = "data-storage"; reg = <0x00000000 DT_SIZE_M(8)>; }; }; }; };   而 pinmux 是   &pinctrl { pinmux_flexspi1: pinmux_flexspi1 { group_a { pinmux = <&iomuxc_gpio_sd_b1_06_flexspi_a_ss0_b>, <&iomuxc_gpio_sd_b1_07_flexspi_a_sclk>, <&iomuxc_gpio_sd_b1_08_flexspi_a_data0>, <&iomuxc_gpio_sd_b1_09_flexspi_a_data1>, <&iomuxc_gpio_sd_b1_10_flexspi_a_data2>, <&iomuxc_gpio_sd_b1_11_flexspi_a_data3>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; group_b { pinmux = <&iomuxc_gpio_sd_b1_03_flexspi_b_data0>, <&iomuxc_gpio_sd_b1_02_flexspi_b_data1>, <&iomuxc_gpio_sd_b1_01_flexspi_b_data2>, <&iomuxc_gpio_sd_b1_00_flexspi_b_data3>, <&iomuxc_gpio_sd_b1_04_flexspi_b_sclk>, <&iomuxc_gpio_sd_b1_05_flexspi_b_ss0_b>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; };     在启动过程中，程序会被打入这个 while 循环、   if (flash_flexspi_nor_probe(data)) { if (memc_flexspi_is_running_xip(&data->controller)) { /* We can't continue from here- the LUT stored in * the FlexSPI will be invalid so we cannot XIP. * Instead, spin here */ while (1) { /* Spin */ } } LOG_ERR("SFDP probe failed"); return -EIO; }     当我逐步调试它时，在我看来，每个闪存设备在 LUT 中都消耗了 40-48 个空间。因此，如果有两个闪光灯，就会超过 64 个 LUT 的最大值。   我是不是做错了什么？怎样才能让它发挥作用 i.MX RT105x Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr 我知道您是独立使用两支闪光灯，而不是并联模式。您可以为用于 XIP 的闪存保留 LUT，并使用 IP 命令访问其他闪存。另一种方法是循环使用两个闪存的 LUT，因为两个闪存的区别在于大小，同时禁用第二个闪存的 SFDP。 BR, Omar Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr 您好， 我也遇到了同样的问题。 请问您是如何解决这个问题的？我只需要将数据存储到第二个闪存中。如何仅对第二个闪存禁用 XIP？ 谢谢！ 顺祝商祺！ 阿德里安·克莱里斯

IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Hello, We are looking for an explanation for a non-working DDR4 timing set. In short, the timings generated by the DDR Tool passed calibration and stress tests, but led to sporadic Linux kernel crashes during boot, with an "undefined instruction" error. Setup (raw facts): - The SoC is an i.MX8M Mini Solo (single Cortex-A53), DDR4 (Winbond W664GG6RB-06) at 1200 MHz (DDR4-2400) in 1:2 DFI (DDR PHY Interface) frequency-ratio mode, with a single x16 4 Gb device (512 MB, no ECC). - The BSP is NXP L4.14.98_2.0.0 (Linux 4.14.98, U-Boot 2018.03); the DDR config was generated with MSCALE DDR Tool v3.31 (Windows version) and PHY training firmware v201709. The same firmware is used in Yocto to build the U-Boot image. - We are qualifying one common timing set for three interchangeable 4 Gb x16 DDR4 parts (Alliance AS4C256M16D4, ISSI IS43QR16256B, Winbond W664GG6RB-06), all operated at 1200 MHz. - To meet the slowest part's (Winbond) tRCD/tRP/tAA (~14.16 ns at the 2400 bin) we set CL=17 (17-17-17), which the Tool encodes as MR0 = 0x0864 with the matching CL-derived registers (e.g. DFITMG0 = 0x038C8207, DRAMTMG2 = 0x0609050D). - The DRAM runs static at the 2400 setpoint (DVFS/busfreq disabled in the device tree), so there is no frequency scaling by Linux at runtime. Observations: - The 17-17-17 config passes the DDR Tool stress test (~24 h) and U-Boot mtest (~1 h) with no errors. - Under Linux (on boots that reach the shell prompt) it also passes stressapptest + fio (crc32c-verified), continuously and even at Tj = 84 °C, for over an hour with zero data errors. - Nevertheless, Linux sporadically crashes during boot with "Internal error: undefined instruction" (corrupted kernel .text), ~1.1 s into the kernel, on roughly 5–7 % of cold boots (measured with an automated cold power-cycle loop). - The failure is die-independent: the CL=17 image crashes the same way on a second of these parts (ISSI), while the CL=16 image boots Linux reliably on that same ISSI part. - Both even-CL configs boot Linux reliably: 16-16-16 (our long-standing production timing) and a newly built 18-18-18 (no kernel crashes observed) — only the odd-CL 17-17-17 fails. - Only the CL-derived registers differ between the failing and working configs (MR0 CAS bits, DFITMG0 dfi_t_rddata_en, DRAMTMG2 read latency / rd2wr, DFITMG2 rdcslat, ODTCFG rd_odt_delay). Hypothesis: We suspect odd CAS latency at the 1:2 DFI ratio is the root cause: the read-data return latency is CL/2 in DFI clocks — a non-integer 8.5 for CL=17 versus integer 8.0 / 9.0 for CL=16 / 18. Since the read FIFO (written by DQS, read by the controller clock, Reference Manual §9.3.2.2.2) handles the steady state and steady stress passes, we suspect the marginality surfaces at read burst-to-burst transitions, where odd CL's half-DFI-clock offset would hit a first/last-beat edge case the RM does not document. Questions: Is odd CAS latency (e.g. CL=17) supported on the i.MX8M Mini DDR4 PHY in 1:2 DFI mode, or are there known constraints/errata for odd CL? In particular — can the DDR Tool produce an odd-CL configuration that passes its own stress test yet is marginal under real boot traffic, and is there a recommended way to constrain read burst-to-burst timing for odd CL? Attached: kernel crash console dump, the CL=17 .ds script for the DDR Tool, and the produced ddr4_timing.c. Any advice will be appreciated. Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Sorry, somehow attachments didn't attach. Here are they. Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Hello,  Please try again by modifying from CL=17 to CL=18, run ddr test and test your linux again, I recommend you to upgrade to a newer release.  Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Please check the timing parameter for the parts below for  CAS Latency   tRCD(ns)  tRP(ns) Alliance AS4C256M16D4     DDR4-2400                                             17      14.16   14.16 ISSI IS43QR16256B                   2400Mbps                                            16-16-16 (-083R) Winbond W664GG6RB-06  DDR4-2400                                            17-17-17 The 3 parameter for IS43QR16256B is different. So you may need dedicated setting for 3 parts instead using one setting for all 3 part. It seems the issue only happened at cold boots, right?

s32k144 - Device is secured Hi Team, I am working with the S32K114 (AN12323) project. Initially, I flashed the Gateway project with CSEC disabled, and the programming was successful. After that, I attempted to flash the CAN example application, but I encountered the following error: "Device is secure, erase to unsecure." To resolve the issue, I also tried using the "Emergency Kinetis Device Recovery" option, but it did not work. Could you please suggest how to recover the device or remove the secure state so that I can flash the CAN example? Re: s32k144 - Device is secured Hi @Senlent , In which scenarios would the reset signal period be approximately 118 µs, and what factors could cause it to increase to around 475 µs in my case?     Thnaks. Re: s32k144 - Device is secured Hi@Pranathi06 If the reset signal period is not ~118µs, but greater than 200µs, such as 500µs or even longer, the MCU will not be able to be decrypted and recovered via the SWD/JTAG debug interface using the mass erase command. Re: s32k144 - Device is secured Hi @Senlent  I measured the RESET_b pin waveform using an oscilloscope. The RESET_b signal is continuously toggling. Pulse repetition appears to be roughly 400–500 µs (cursor shows Δt ≈ 475 µs). Peak level is around 5 V, which suggests you may be probing an external reset circuit rather than directly measuring a 3.3 V MCU pin, or there is a pull-up to 5 V on RESET. The reset activity is continuous and regular.   Thanks         Re: s32k144 - Device is secured Hi@Pranathi06 The "S32K144_FOTA_GATEWAY" command doesn't involve any CSEc or flash security related operations, so I'm unsure what you've done to the MCU. You could measure the waveform of the RESET pin and tell me its reset cycle. The reset cycle can be used to determine if the chip can recover to normal operation. Re: s32k144 - Device is secured Hi @Senlent , Yes, successfully flashed "S32K144_FOTA_Gateway", when I tried to flash Can_example project that time "Device is secured" after that I cannot be able to flash any software. Thanks Re: s32k144 - Device is secured Hi@Pranathi06 Is your problem occurring when downloading the "S32K144_FOTA_Gateway" program, or have you already successfully flashed "S32K144_FOTA_Gateway"? Re: s32k144 - Device is secured Hi @Senlent      I flashed AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State to erase the keys. After that, I flashed only the GATEWAY_PROJECT; I did not flash the Memory_Partition project. Thanks.   Re: s32k144 - Device is secured Hi@Pranathi06 "Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state" I don't understand your meaning. The AN12323SW doesn't have a "Resetting flash to state" program. From what you're saying, you've modified "S32K144_FOTA_Gateway"? You just need to check if your program has enabled the CSEc module and assigned a key, and whether you've considered restoring the CSEc module to its factory state within the application. If not, then this situation is unrecoverable. Re: s32k144 - Device is secured Hi @Senlent  I didn't flash Memory_partition project.  Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state"  Is there any solution for recover? Thanks. Re: s32k144 - Device is secured Hi@Pranathi06 This issue is unrelated to whether "CSEC" is enabled in "S32K144_FOTA_Gateway" because when testing AN12323SW, your first step should be to download and run "S32K144_Memory_Partition" to perform partitioning, which already enables CSEC by default and assigns a key. Senlent_0-1783587478752.png AN12130: Senlent_1-1783587519720.png This is why the MCU is locked; since the solution doesn't provide a reset CSEC operation, it cannot be recovered. Next time, remember to modify "S32K144_Memory_Partition" to partition only, without enabling CSEC or the key. Re: s32k144 - Device is secured Hi@Pranathi06 This is based on experience, and your situation is quite similar: the CSEc hardware encryption module was enabled, preventing mass erase of the CSEc encryption key, which caused the problem. Although the chip has deadlocked, and the MCU can no longer download programs or debug, as long as the chip's power supply is normal, you can still use a J-LINK debugger to connect to the CoreSight DAP debug access interface of the S32K1xx series MCU ARM Cortex M4F/M0+ via the SWD/JTAG debug interface to read the MDM-AP status register. Therefore, you can determine the root cause of the chip deadlock based on the read MDM-AP status register value. If you need me to help you pinpoint the cause of the deadlock, you can try using J-LINK to read the MDM-AP status register.

MC34GD3000 VPWRが24 Vの場合のゲートドライブ出力電圧レベル こんにちは、NXPコミュニティの皆さん、 このMC34GD3000を使って24V、26Wのモーターを駆動する予定です。 多くの参考回路や例では、MC34GD3000のVPWR電源はモーター電源と同じ電源電圧に接続されているように見えます。私の用途では、モーターの電源電圧は24Vなので、MC34GD3000のVPWRも24Vになります。 MC34GD3000のゲート駆動出力電圧レベルについて確認させてください。 データシートの絶対最大定格表には、次のような値が記載されていました。 - PX_HS_G～PX_HS_S：3.0V～16.5V - PX_LS_G～PX_LS_S：3.0V～16.5V - PX_BOOTからPX_HS_Sまで：3.0V～16.5V 私の質問は次のとおりです。 VPWRが24Vの場合、MC34GD3000の実際のPWMゲートドライブ出力電圧レベルはどのくらいですか? VPWRが24Vであるためゲートドライブ出力は24Vになるのでしょうか、それとも各MOSFETソースノードに対してゲートドライブ出力は最大約16.5Vに制限されるのでしょうか? 例えば、ローサイドMOSFETの場合、PX_LS_GからPX_LS_Sへの駆動は24Vではなく約15Vまで駆動されるということを理解しておくべきでしょうか? ハイサイドMOSFETについては、PX_HS_Gは位相ノードより上に駆動されるものの、ゲート・ソース間電圧PX_HS_GからPX_HS_Sまでは依然として約15Vに制限される、と理解してよろしいでしょうか？ ご確認いただければ幸いです。 よろしくお願いします。 BLDCドライバー Re: MC34GD3000 gate drive output voltage level when VPWR is 24 V こんにちは、 はい、あなたの理解は正しいです。VPWRが24Vモーター電源に接続されていても、MC34GD3000はMOSFETゲートをソース端子に対して24Vに駆動しません。このデバイスは、約15Vに安定化された内部ゲート駆動電源（VLS）を生成します。 ErikaC_1-1783696364130.png ErikaC_0-1783696304074.png そのため、 ローサイドMOSFETの場合、PX_LS_GはPX_LS_Sより約15V高い電圧で駆動されます。 ハイサイドMOSFETでは、PX_HS_Gは位相ノードの上をブートストラップ回路を通じて駆動されますが、ゲート対ソース電圧PX_HS_G−PX_HS_Sは約15Vのままです。 ErikaC_2-1783696431300.png データシートに示されている制限(PX_HS_GからPX_HS_S、PX_LS_GからPX_LS_S)は、実効的なゲート対ソースドライブ電圧を表し、ゲートドライブが24V VPWR電源と等しくないことを示しています。 お役に立てば幸いです！

Cannot configure two NOR flashes on single FlexSpi in Zephyr Hi, I am working with a board based on i.mx RT1050 board. There are two NOR flashes connected to two banks of the flexspi. I am also using the bank 1 for XIP booting. It works fine when I only use one flash. But when I add the second flash, I run into a problem that seems like there is insufficient space for LUT. My two flashes are w25q128 and w25q64 connected to flexspi Port A1 and B1 respectively.   This is my configuration in the overlay file.   / { chosen { zephyr,flash-controller = &w25q128jv; zephyr,flash = &w25q128jv; zephyr,code-partition = &slot0_partition; }; };   &flexspi { status = "okay"; rx-clock-source = <1>; pinctrl-0 = <&pinmux_flexspi1>; pinctrl-names = "default"; reg = <0x402a8000 0x4000>, <0x60000000 DT_SIZE_M(64)>; /delete-node/ is25wp064@0; w25q128jv: w25q128jv@0 { compatible = "nxp,imx-flexspi-nor"; size = ; reg = <0>; spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 70 18]; erase-block-size = ; write-block-size = <16>; enter-4byte-addr = <0>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; boot_partition: partition@0 { label = "mcuboot"; reg = <0x00000000 DT_SIZE_K(256)>; }; /* Adjusted slot sizes for 16MB total */ slot0_partition: partition@20000 { label = "image-0"; reg = <0x00040000 (DT_SIZE_M(3) + DT_SIZE_K(512))>; }; slot1_partition: partition@320000 { label = "image-1"; reg = <0x00320000 DT_SIZE_M(3)>; }; storage_partition: partition@620000 { label = "storage"; reg = <0x00620000 (DT_SIZE_M(1) - DT_SIZE_K(768))>; }; }; }; w25q64jv: w25q64jv@2 { compatible = "nxp,imx-flexspi-nor"; size = ; /* 8MB (64Mbit) flash */ reg = <2>; /* FlexSPI B */ spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 40 17]; /* Winbond W25Q64JV JEDEC ID */ erase-block-size = ; write-block-size = <16>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; data_partition: partition@0 { label = "data-storage"; reg = <0x00000000 DT_SIZE_M(8)>; }; }; }; };   And the pinmux is,   &pinctrl { pinmux_flexspi1: pinmux_flexspi1 { group_a { pinmux = <&iomuxc_gpio_sd_b1_06_flexspi_a_ss0_b>, <&iomuxc_gpio_sd_b1_07_flexspi_a_sclk>, <&iomuxc_gpio_sd_b1_08_flexspi_a_data0>, <&iomuxc_gpio_sd_b1_09_flexspi_a_data1>, <&iomuxc_gpio_sd_b1_10_flexspi_a_data2>, <&iomuxc_gpio_sd_b1_11_flexspi_a_data3>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; group_b { pinmux = <&iomuxc_gpio_sd_b1_03_flexspi_b_data0>, <&iomuxc_gpio_sd_b1_02_flexspi_b_data1>, <&iomuxc_gpio_sd_b1_01_flexspi_b_data2>, <&iomuxc_gpio_sd_b1_00_flexspi_b_data3>, <&iomuxc_gpio_sd_b1_04_flexspi_b_sclk>, <&iomuxc_gpio_sd_b1_05_flexspi_b_ss0_b>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; };     During bootup the program gets struck in this while loop,   if (flash_flexspi_nor_probe(data)) { if (memc_flexspi_is_running_xip(&data->controller)) { /* We can't continue from here- the LUT stored in * the FlexSPI will be invalid so we cannot XIP. * Instead, spin here */ while (1) { /* Spin */ } } LOG_ERR("SFDP probe failed"); return -EIO; }     When I debugged it step-by -step, it seems to me each flash device uses up 40-48 space in LUT. Therefore having two flashes makes it so that it exceeds the maximum LUT that is 64.   Am I doing something wrong? What can I do to make this work i.MXRT 105x Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr I understand that you are using the two flashes independently, not in parallel mode. You can reserve the LUT for the flash used for XIP and use IP commands to access the other flash. Another option is to recycle the LUT for two flash, as the difference of both is the size, and disable SFDP for the second flash. BR, Omar Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr Hi, I am facing the same issue. Could you please tell me how you solved your problem. I just need to store data in the second flash memory. How can I disable XIP for the second flash only ? Thank you, Best Regards, Adrien Cléris

S32 Design Studio for Power Architecture® 2017.R1 - ライセンス有効化の問題 こんにちは、 ライセンスの有効化に関して、ご支援をお願いしたいのですが。 以前のリクエストは処理されましたが、誤ったバージョンが再有効化されました。現在はPower Architecture v2.1用のS32 Design Studio にアクセスできるようになりましたが、現在のプロジェクトでは実際にはS32 Design Studio for Power Architecture 2017.R1(S32DS-PA v2.0)を使う必要があります。 アクティベーションを修正して、正しいライセンスのバージョンを復元してもらえますか? サポートありがとうございます。 よろしくお願いします、 アレッサンドロ Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue こんにちは、 あなたのためにリクエストしました。 完了次第、ご連絡いたします。 よろしくお願いいたします。 ピーター Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue こんにちは、ピーターさん。 ご協力ありがとうございます。 まだ何のアップデートも受け取っておらず、ライセンスも期限切れのままであることをお知らせしたかったのです。その結果、現在はS32 Design Studio for Power Architecture 2017.R1(v2.0)を使用できず、作業を継続することもできません。 よろしくお願いいたします。 アレッサンドロ Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue こんにちは、 現時点で全て準備が整っているはずです。 よろしくお願いいたします。 ピーター Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue どうもありがとうございます、 アレッサンドロ

ADC应用模块选择 我想围绕 MXP 开发板开发一个应用程序，但我很难选择可以使用的具体计算模块。种类繁多，我有点不知所措，不确定哪些产品真正能满足我的需求。 据我了解，有多家片上系统 (SoC) 提供模数转换器 (ADC)。我需要一台计算能力更强、至少有 4 个 ADC 通道的设备。我可以使用哪些具体的开发板？我可以使用哪些模块和开发板来构建这个应用程序？是否有供应商可以协助我选择要购买的具体板？ Re: Module selection for ADC application 我认为使用 MPU 可以确保有足够的处理能力，而且我们并不太担心功耗或成本。我们也对使用Profinet很感兴趣。然后它应该至少有 4 个 ADC 通道，每个通道的采样率超过 100ksps。据我了解，i.MX 9 MPU 可能适用。 我想到的一种替代方案是购买一台树莓派 Pico，并配备一个独立的 ADC 模块和以太网模块。但我认为恩智浦的系统应该能够满足我的所有需求。即使我选定了某个特定的芯片，市面上的产品种类也很多，而且我通常也不清楚能否得到合适的ADC，而ADC对我来说是最重要的特性。 Re: Module selection for ADC application 你好， 你要买什么？ 它是微控制器（MCU）吗？还是微处理器（MPU）？ 如果您能提供更多关于该项目的信息，我们可以为您提供帮助。 此外，我们的网页上还有产品搜索功能。 https://www.nxp.com/design/design-center/development-boards-and-designs:EVDEBRDSSYS?collection=devBoardsDesigns&start=0&max=12&language=en&query=typeTax %3E% 3Et633_t763 此致敬礼/Saludos， 阿尔多。 Re: Module selection for ADC application 你好， 是的，i.MX9 系列的任何一款处理器都可以使用，具体哪一款更适合您的使用场景，取决于您的显卡和其他外设。 为此，i.MX91、i.MX93 和 i.MX95 这三款芯片都采用了 FRDM 板，并且 ADC 的规格相同： • 它包含八个通道，其中四个通道连接到封装中的引脚。 • 支持 1MS/s 的工作频率 • 多种启动转换模式（正常、注入式） 普通模式支持单次拍摄和扫描（连续）转换 注入模式仅支持单次转换 • 支持 TRGMUX，允许任何 ADC 通道使用 16 个触发通道 i.MX93 https://www.nxp.com/products/i.MX93 i.MX93 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 i.MX91 https://www.nxp.com/products/i.MX91 i.MX91 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91 i.MX95 https://www.nxp.com/products/i.MX95 i.MX95 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX95 另外，您也可以查看每个 EVK 的相关信息，但既然您提到了 RPI，我认为 FRDM 板可能会让您感兴趣。 此致敬礼/Saludos， 阿尔多。

imx95 在挂起到内存时关闭 vdd_soc 你好， 我们尝试在IDLE状态后关闭VDD_SOC。 例如在 m33 控制台上： lm 暂停 lm M7 挂起 闲置的 然后我们关闭 VDD SOC（通过设置 pf09 待机模式并关闭 VDD SOC） 然后松开备用销， m33 上的 VDD_SOC 从头开始，我们仍然节省了 RAM。 我们在 spl 中修改代码，使其在 bl31 中使用热启动路径，并成功启动到内核。 然而，之后内核就卡住了，您可以查看以下最新日志。 我想知道这两个案例之间可能存在哪些区别： - 正常挂起情况：（保留 vdd_soc） - 如果出现异常情况（vdd_soc 关闭），我们是否应该在 m33 启动时执行其他操作来重新初始化某些内容？ [2026-07-06 10:39:55.070]注意：BL31：已恢复 NS 上下文 [2026-07-06 10:39:55.074][ 1018.529356][T3251] 调用 its_restore_enable+0x0/0x1ac [2026-07-06 10:39:55.080][ 1018.529356][T3251] 调用 cpu_pm_resume+0x0/0x5c [2026-07-06 10:39:55.084][ 1018.529356][T3251] 调用 kvm_resume+0x0/0x68 [2026-07-06 10:39:55.089][ 1018.529356][T3251] 调用 irq_gc_resume+0x0/0x110 [2026-07-06 10:39:55.094][ 1018.529356][T3251] 调用 irq_pm_syscore_resume+0x0/0x24 [2026-07-06 10:39:55.100][ 1018.529356][T3251] 调用 timekeeping_resume+0x0/0x188 [2026-07-06 10:39:55.105][ 1018.529356][T3251] 调用 sched_clock_resume+0x0/0xd0 [2026-07-06 10:39:55.110][ 1018.529619][T3251] 启用非启动 CPU... [2026-07-06 10:39:55.142][ 1018.559214][T0] 在 CPU1 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3：CPU1：找到分发器 100 区域 0:0x0000000048080000 [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1：已启动辅助处理器 0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1 已启动 [2026-07-06 10:39:55.191][ 1018.608610][T0] 在 CPU2 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3：CPU2：找到重新分发器 200 区域 0:0x00000000480a0000 [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2：已启动辅助处理器 0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2 已启动 [2026-07-06 10:39:55.240][ 1018.657836][T0] 在 CPU3 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3：CPU3：找到 redistributor 300 区域 0:0x00000000480c0000 [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3：已启动辅助处理器 0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3 已启动 [2026-07-06 10:39:55.289][ 1018.707065][T0] 在 CPU4 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3：CPU4：找到 400 号分发器区域 0:0x00000000480e0000 [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4：已启动辅助处理器 0x0000000400 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4 已启动 [2026-07-06 10:39:55.339][ 1018.756298][T0] 在 CPU5 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3：CPU5：找到 500 重分发器区域 0:0x0000000048100000 [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5：已启动辅助处理器 0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5 已启动 [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-lifecycle rpmsg-lifecycle：PM：调用 rpmsg_lifecycle_resume_noirq @ 3251，父级：平台 [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle：PM：rpmsg_lifecycle_resume_noirq 在 1 微秒后返回 0 [2026-07-06 10:39:55.383][ 1018.802181][T3251]arm-smmu-v3 490d0000.iommu：PM：调用 arm_smmu_resume [arm_smmu_v3] @ 3251，父级：49000000.总线 [2026-07-06 10:39:55.394][ 1018.812966][T3251]arm-smmu-v3 490d0000.iommu：PM：arm_smmu_resume [arm_smmu_v3] 在 60 微秒后返回 0 [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM：正在调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：44000000.总线 [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 3 微秒后返回 0 [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 2 微秒后返回 0 [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM：调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM：正在调用 imx_mu_resume_noirq [imx_mailbox] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM：imx_mu_resume_noirq [imx_mailbox] 在 0 微秒后返回 0 [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM：调用 lpuart_resume_noirq [fsl_lpuart] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM：lpuart_resume_noirq [fsl_lpuart] 在 2 微秒后返回 0 [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM：调用 lpuart_resume_noirq [fsl_lpuart] @ 3251，父级：44000000.总线 [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM：lpuart_resume_noirq [fsl_lpuart] 在 4 微秒后返回 0 [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 1 微秒后返回 0 [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：42000000.总线 [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM：调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251，父级：44000000.总线 [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM：lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.中断控制器：PM：调用 genpd_resume_noirq @ 3251，父级：soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM：GENPD_RESUME_NOIRQ dev=4b0b0000.中断控制器domain=display task=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD 功能域=13 状态=开启 任务=kworker/4:5 进程 ID=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram 日志中没有错误，但 a55 就此停止运行。 正常情况下（未关闭vddsoc），它会继续运行。 我们试图降低睡眠模式下的功耗，因此我们尝试通过这种方式关闭 vddsoc，同时保持 RAM 的运行。 Re: imx95 turn off vdd_soc when suspend to ram 日志中似乎没有任何错误信息。是否关闭电压可能会导致电流消耗的差异。你注意到功耗方面有任何变化吗？为什么要关闭VDDSOC？ Re: imx95 turn off vdd_soc when suspend to ram 嗨@thinkembedsw VDD_SOC（及相关数字电源）电压降低至“挂起模式”电压。它不支持直接关闭。 BR

imx95はRAMへのサスペンド時にvdd_socをオフにする こんにちは、 アイドル状態になった後、VDD_SOCをオフにしようとしています。 例えば、m33コンソールでは次のようになります。 lm サスペンド lm M7 サスペンション アイドル 次に、vdd socをオフにします（pf09のスタンバイモードをvdd socオフに設定することによって）。 次にスタンバイピンを放します。 m33 の VDD_SOC は最初からやり直しますが、RAM は保存されたままです。 bl31でウォームブートパスを実行するようにsplのコードを変更し、カーネルへの起動に成功しました。 しかしその後、カーネルが詰まってしまい、以下の通りの「最新のログ」が確認できます。 2つのCASEで何が違うのか気になります。 - CASEノーマルサスペンド:(保持vdd_soc) - Case Abnormal(vdd_soc オフ) この場合、M33の起動時に何か再初期化するために別のことをすべきでしょうか? [2026-07-06 10:39:55.070]通知: BL31: ウォームレジュームNSコンテキストが復元されました [2026-07-06 10:39:55.074][ 1018.529356][T3251] its_restore_enable+0x0/0x1ac を呼び出しています [2026-07-06 10:39:55.080][ 1018.529356][T3251] cpu_pm_resume+0x0/0x5c を呼び出しています [2026-07-06 10:39:55.084][ 1018.529356][T3251] kvm_resume+0x0/0x68 を呼び出しています [2026-07-06 10:39:55.089][ 1018.529356][T3251] irq_gc_resume+0x0/0x110 を呼び出しています [2026-07-06 10:39:55.094][ 1018.529356][T3251] irq_pm_syscore_resume+0x0/0x24 を呼び出しています [2026-07-06 10:39:55.100][ 1018.529356][T3251] timekeeping_resume+0x0/0x188 を呼び出しています [2026-07-06 10:39:55.105][ 1018.529356][T3251] sched_clock_resume+0x0/0xd0 を呼び出しています [2026-07-06 10:39:55.110][ 1018.529619][T3251] ブート以外のCPUを有効にする... [2026-07-06 10:39:55.142][ 1018.559214][T0] CPU1でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3: CPU1: 再分配器100の領域0:0x0000000048080000が見つかりました [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1: 起動済みのセカンダリプロセッサ0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1が起動しました [2026-07-06 10:39:55.191][ 1018.608610][T0] CPU2でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3: CPU2: 再分配器200の領域0:0x00000000480a0000が見つかりました [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2:起動されたセカンダリプロセッサ0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2が起動しました [2026-07-06 10:39:55.240][ 1018.657836][T0] CPU3でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3: CPU3: 再分配器300領域0:0x00000000480c0000が見つかりました [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3: 起動された二次プロセッサ0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3が起動しました [2026-07-06 10:39:55.289][ 1018.707065][T0] CPU4でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3: CPU4: 再分配器400領域0:0x00000000480e0000が見つかりました [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4:セカンダリプロセッサ0x0000000400起動 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4が起動しました [2026-07-06 10:39:55.339][ 1018.756298][T0] CPU5でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3: CPU5: 再分配器500領域0:0x0000000048100000が見つかりました [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5:起動したセカンダリプロセッサ0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5が起動しました [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-ライフサイクル rpmsg-lifecycle: PM: 呼び出し rpmsg_lifecycle_resume_noirq @ 3251、親: プラットフォーム [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle: PM: rpmsg_lifecycle_resume_noirq が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.383][ 1018.802181][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] @ 3251 を呼び出し中、親プロセス: 49000000.bus [2026-07-06 10:39:55.394][ 1018.812966][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] が 60 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 3 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 42000000.bus [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 44000000.bus [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 4 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.interrupt-controller:PM: genpd_resume_noirq @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM: GENPD_RESUME_NOIRQ dev=4b0b0000.interrupt-controllerドメイン=display タスク=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD ディスプレイ ドメイン=13 状態=オン タスク=kworker/4:5 pid=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram ログにはエラーは記録されていませんが、a55はそこで停止してしまいます。 通常の場合(vddsoCを切らさずに)、そのまま動作を続けます スリープモードでの消費電力を減らそうとしているので、この方法でvddsocをオフにしつつRAMは残しています。 Re: imx95 turn off vdd_soc when suspend to ram ログにはエラー情報がないようです。電圧を遮断するかどうかによって、消費電流に差が生じる可能性があります。消費電力に違いを感じますか？また、VDDSOCをオフにしたい理由は何ですか？ Re: imx95 turn off vdd_soc when suspend to ram こんにちは@thinkembedsw VDD_SOC（および関連するデジタル電源）電圧は、「サスペンドモード」電圧まで低下します。直接電源を切ることはサポートしていません BR

GuiGuiDer2.0.0构建目标设备时出错 我现在创建了一个基于frdm_mcx947的guiguider工程，使用的版本是2.0.0,选用的ARM GCC为14.4.1。 我已经配置好了arm gcc工具。 编译时报错信息如下：C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. 我使用在cmd中查找编译工具是成功的： C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe

IMX8Mini上のソフトウェアISP 弊社ではIMX8miniを使用していますが、以前はハードウェアISPを内蔵したimx8mplusを使用していました。しかし、IMX8miniにはハードウェアISPのサポートがありません。 デベイヤリング、3A、ガンマ補正、その他のISP機能を実行するためのオプションにはどのようなものがありますか？調査の結果、NXP Soft ISPはimx8miniでは利用できず、libcameraはimx8miniで公式にはサポートされておらず、またlibcameraとそのパイプラインハンドラー関連の統合に関する経験もありませんでした。 もう一つ、imx8mplusでは、ビデオをISP経由でルーティングするか、キャプチャモードでISI経由でビデオをルーティングする機能があります。iMX8miniでは、vvcamスタックなどの機能がないのに、どうやってそれが起こるのですか？ ちなみに、当社のカメラには内蔵ISPが搭載されていないため、プロセッサ上でソフトウェアISPを実行する必要があります。 皆さんの中には、このことをご存知の方もいらっしゃると思います。 ありがとうございます。 S ヴィシュヌ i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Software ISP on the IMX8Mini こんにちは、 @SiddavatamVishnu さん。 i.MX8M Miniでは、カメラデータはCSI+ISIを使用してセンサから直接メモリに転送されます。ISIはISPではありません。画像を移動させたり、多少サイズ変更したりできるだけです。i.MX8M PlusのようにRAW画像を処理できるステージはなく、vvcamやSoft ISPスタックも利用できません。 Libcameraはi.MX8M Miniでは非常に限定的な形でしかサポートされていません。この機能は、センサー内部にISP（画像信号プロセッサ）を内蔵したカメラ（いわゆる「スマートカメラ」）でのみ動作します。i.MX8MMに搭載されているLibcameraは、ISP機能を追加するものではなく、単にキャプチャの管理を支援するものです。これは、失われたISPの代わりにはなりません。 CPU上で完全なソフトウェアISPを実行することは技術的には可能ですが、CPU負荷、消費電力、複雑さが高いため推奨されません。また、NXPはi.MX8M Miniでそのようなソリューションを提供またはサポートしていません。 i.MX8M Miniはカメラのキャプチャ専用です。ISP機能が必要な場合は、SoCの外部で処理する必要があります。 よろしくお願いします、 チャビラ Re: Software ISP on the IMX8Mini libcameraにはSoftISPのGPU実装があり、i.MX8MMで使えるかもしれませんが、i.MX8MMのGPUはそれほど大きくないため、高いスループットが得られないかもしれません。動作はしますが、高フレームレートではないので、あなたの要件次第でしょう。