2419179_ja-JP

[#1]

RW612: FlexSPIポートの混在（CACHE64書き込みバッファ）、PMUゲートCM33クロック、リセット後にPSRAM FSELが失われる

RW612（u-blox IRIS-W10モジュール、CHIP_INFO 0x7002）上に通信スティックを構築します。コードはFlexSPIポートA1の外部16MB QSPI NORからXIPを実行し、同じコントローラーのポートB1には2MBのQSPI PSRAM(APS1604M-3SQR、DQSなし)が接続されています。ファームウェア:MCUXpresso SDK 25.06.00 + FreeRTOS、およびZephyr 4.5.0-rc1です。3つの問題点が見つかりましたので、その根本原因と推奨設定について教えてください。測定値、除外した項目、登録住所、コード抜粋を含む完全な報告書を添付します。

1) CACHE64_CTRL0書き込みバッファが有効になっているFlexSPIポート間でのデータ混合

PSRAMはコードバスウィンドウからアクセスされ、コードはポートAからXIPを実行しているため、PSRAMアクセスは時にフラッシュワードを返すことがあり、命令フェッチは誤ったワード(ヒープコードやNET割り込みのBusFault/UsageFault)を返すこともあります。同一のコードアドレスを持つ画像に対するA/Bテスト：バッファオンの場合、約115分で9回の障害が発生。バッファオフの場合、約195分で0回の障害が発生（p値は約1e-4）。SDK SystemInit()はXIP上でこのバッファを有効にします。

- CCRのCACHE64_CTRL0に訂正や制限はありますか?ポートBにPSRAM、ポートAにXIPを使ったENWRBUFは?SDKはデフォルトで安全ですか?

- システムバスウィンドウ(0x28000000/0x38000000 with CACHE64_CTRL1、Zephyr GitHub issue 99943で示唆されているように)は、PSRAMの隣にXIPの隣で必須ですか?CTRL1書き込みバッファは安全ですか？（バッファ7の場合）どのAHB RXバッファ／プリフェッチ設定をお勧めしますか？

両方向の混合のメカニズムは何ですか？

2) PMUはCM33クロック（gate_cpu_clk）を制御し、デバッガが接続されたときにのみコアが再開します。

基板はリセットも故障記録もなくフリーズし、映像にWFIも表示されません(FreeRTOS)。デバッガが接続した瞬間(Cortex-M33のアタッチが素でさえ)すぐに再び動作します。SysTick/ENETカウンターは停止前に読み取られ、DWT_PCSRサンプルはコアが進んでいないことを示している。リセットを有効にした状態でLPOSCにWWDT0を有効化した場合のみ、この問題は回避できた（70分間で0回の故障に対し、無効化した場合は20分間で6～7回の故障）。Zephyrでは、同じクラスがWFIに残るコアとして表示され、OSタイマー割り込みが有効化されています。WFIなしのアイドルループはこれを回避します。

- WFIを使用せず、SCR = 0の場合、PMUはいつCPUクロックをゲート制御するのでしょうか？デバッグ接続によってゲート制御が解除されるのはなぜですか？また、WWDTリセットが有効になっている場合、ゲート制御が解除されないのはなぜですか？SYSCTL2 SOURCE_CLK_GATE CPU_CLK_ENは実際には何を制御しているのでしょうか？

- RW612で通常のWFIを使用するには、どのようなウェイクアップ/PMU構成が必要ですか？WFI（給水設備）のない、忙しいけれど何もしない状態は、長期的に見て許容できる戦略でしょうか？

3) ディープリセット後にMCI_IO_MUX FSELビット3（QUAD_SPI_PSRAM、0x40004020）がクリアされる

ハング後にWWDTリセットを行った後、QUAD_SPI_PSRAM機能選択ビットがクリアになり、PSRAMパッドが浮かび上がり、すべての読み取りが返0x1797523E、コードが再びピングループを適用するまで続きました。Zephyrはこのピン群自体を適用しません。

- どのリセットタイプがMCI_IO_MUX FSELとパッドプルをリセットしますか？ROMはFSELと接触しますか？ZephyrはXIPの隣でPSRAM(ピン、LUT分離、キャッシュポリシー)をサポートする予定ですか?

未公開項目:NETがZephyrでエラー(ENET_GetRxFrameSizeステータス4001、BABR/CRCエラー)を受け取り、RMIIで100 Mbit/sの全二重KSZ8081を受信しています。これは既知の問題でしょうか?

現在の回避策(CTRL0バッファをPSRAMで書き出し、システムバスウィンドウ、LPOSCでWWDT0をリセット、WFIなしのアイドル、毎回の起動でPSRAMピングループを再適用)は添付のレポートに含まれています。ご指導いただければ幸いです。

製品: WiFi RW6XXRe: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

@dimush様、

総合的な分析に基づくと、まずはフラッシュメモリとPSRAM間のデータ破損／混在の問題を解決する必要があります。

以下の設定が正しいことを確認する必要があります。

FlexSPIポートA -> QSPI NORフラッシュ -> code-bus/cache0 -> XIP
FlexSPIポートB -> PSRAM -> システムバス/キャッシュ1 -> ヒープ/データ

また、以下の商品もおすすめします。
CACHE64_CTRL0.ENWRBUF = 0
CACHE64_CTRL1.ENWRBUF = 0 // トラブルシューティング中
PSRAMプリフェッチ = 無効 // トラブルシューティング中

[注]

FlashとPSRAMは、それぞれ適切なAHBマッピングパスを使用する必要があります。RW612フラッシュキャッシュとPSRAMキャッシュは、それぞれコードバスとシステムバスにマッピングされています。
FlexSPI LUTの変更、ポートの再構成、メモリエイリアスの切り替え、またはIPコマンドによるメモリの変更を行った後にのみ、FlexSPIがアイドル状態になるまで待って、対応するAHB RX/TXバッファとCPUキャッシュをクリアする必要があります。キャッシュは通常のPSRAMヒープアクセスの前にクリアしてはいけません。

トラブルシューティング中は、PSRAMの非キャッシュ可能なシステムバスエイリアスを使ってキャッシュ機構をさらに分離することもできます。

ありがとうございます

よろしくお願いいたします。

維東

Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

ありがとう、ウェイドン。私たちのZephyrビルドはすでにこのレイアウトを使っています:ポートAからコードバス/CACHE64_CTRL0経由XIP(ENWRBUF = 0)、システムバス0x38000000/CACHE64_CTRL1経由でポートBにPSRAM、通常のヒープパスではキャッシュ保守なし。このシステムに移行して以来、第1の問題で発生したデータの混在は見られなくなりました。今度は、CACHE64_CTRL1.ENWRBUF = 0 かつ PSRAM プリフェッチを無効にした状態で、現在のイメージと A/B 比較を実行し、結果を報告します。

残りの問題は2つ目の問題で、約18～20ボード時間ごとにコア全体が停止してしまうことです。SysTickで駆動されるタイマーとワークキューは、最後のウォッチドッグフィードから約1秒以内に同時に停止し、WWDT0リセットによってのみ復旧します。これは、WFIが無効で、システムバスのPSRAMウィンドウが既に設定されているアイドル状態のときに発生します。PMUがWFIなしでCM33クロックをゲートするタイミングや、問題3(WWDTリセット後にFSELビット3がクリアされたMCI_IO_MUX)についてコメントしていただけますか?

Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

@dimush様、

最新情報のご提供ありがとうございます。

問題2に関して、PM2のエントリとウェイクアップ設定を確認するには、以下の参照フローを使用してください。必要な調整を行った後、問題が再現可能かどうか確認してください。

まず、PM1の基準値を設定します。

PMUはPM0のままです

SCR.SLEEPDEEP = 0

WFIを実行する

PM1では、有効かつ有効な割り込みソースはすべてCM33を起動させる必要があります。

PM2に入る前に、ウェイクアップソースを必要なすべてのレベルで設定する必要があります。

• 周辺タイマーまたはGPIO割り込みを有効化・設定;
• 対応するNVIC割り込みを有効にする。
• PMUウェイクアップマスクで、対応するPM2ウェイクアップソースを有効にします。
• ウェイクアップソースに必要なクロックがPM2内でアクティブな状態を維持するようにしてください。
• 古いペリフェラルの割り込み状態をすべて消去します。
• 次の有効なタイマーマッチ/比較イベントをプログラムします。

NVIC割り込みが保留状態にあることだけでは、そのソースがPM2ウェイクアップソースとして構成されていることを証明するものではありません。PM2はタイマー、GPIO、FlexSPI、USB、DMA、イーサネットなどのウェイクアップソースをサポートしています。

文書化されたPM2移行は以下のとおりです。

PM0 -> PM2:

PMUの電力モードを2'b01に設定します。

WFIを実行する

PM2では、CPUの状態が保持されている間、CM33のクロックはゲート制御されます。AONドメインと選択されたPM2起動ソースはアクティブな状態を維持します。

以下のコードは、処理手順を説明するためのものであり、直接コピーして使用することを意図したものではありません。

configure_wakeup_source();

enable_peripheral_interrupt();

enable_nvic_interrupt();

enable_pmu_pm2_wakeup_source();

clear_peripheral_interrupt_status();

program_next_timer_event();

/* PM2に入る前にCPU_CLK_ENを有効にしておく */

set_pmu_power_mode(PM2);

__DSB();

__ISB();

__WFI();

__ISB();

本番環境実装では、PMUレジスタを直接プログラムするのではなく、対応するMCUXpresso SDKバージョンが提供するパワーマネージメントAPIを使用してください。SDKのAPI名称はバージョンごとに異なる場合があります。

PM2に入る前に、SYSCTL2.SOURCE_CLK_GATE.CPU_CLK_ENが有効になっていることを確認してください。PM2をエミュレートするためにこのビットをクリアしてはいけません。CPUクロックゲーティングはPMU電源モード遷移によって実行されるべきです。

PM2に入る直前に、以下の値を記録してください。

PMU電源モード

SCB->SCR

SYSCTL2.SOURCE_CLK_GATE

CPU_CLK_EN

PM22対策マスク

NVICの有効化/保留ステータス

タイマー有効化/ステータスレジスタ

最後に、FreeRTOSのWFI非対応構成を別途テストしてください。

WFIなし

SCR.SLEEPDEEP = 0

PMUの電力モードはPM0のままです。

CPU_CLK_EN = 1

これらの条件下でもCM33が停止する場合、その挙動は正常なPM2遷移とはみなすべきではない。その場合は、予期せぬクロックゲート動作、またはRW612 PMU/クロックゲーティング用シリコンの問題の可能性として調査する必要があります。

問題3に関して、WWDTリセット後、RW612はブートROMブートフローを通じて再起動します。

起動ROM -> FlexSPI NOR/FCB - >アプリケーションイメージ

アプリケーションイメージにPSRAMのピン多解式設定コードが含まれている場合、そのコードを再度実行して有効にします。したがって、アプリケーションコードに必要なPSRAMピン-マルチックス構成が含まれているか必ず確認してください。

ありがとうございます

よろしくお願いいたします。

維東

Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

ありがとう、ウェイドン。ご依頼いただいたFreeRTOSのWFI非対応テストを、弊社の高速再現ボードで実行しました。BoardInit の後に明示的に設定され、1 秒ごとに再チェックされる条件: イメージ内のどこにも WFI がない (逆アセンブリで検証済み。ティックレス アイドルはオフ)、SCB->SCR = 0 (SLEEPDEEP = 0、SLEEPONEXIT = 0)、PMU PWR_MODE = PM0 (PWR_MODE_STATUS = 0)、SYSCTL2.SOURCE_CLK_GATE = 0x700100D2 (CPU_CLK_EN = 1)、WWDT は無効。注: ROM/ブートローダーは SOURCE_CLK_GATE = 0x300000C6 を残しました。CPU_CLK_EN = 0、コアが動作中。

結果：CM33は約7分以内に3回停止した（最初の停止は約6分後の稼働後）。SysTickとOSタイマーのギャップチェックによると、デバッガーが接続されるまでコアは進んでいませんでした。最初の停止では12.4秒、その後は接続するたびに進みました。割り込まれたThreadは毎回lwIP RXタスクであり、PC 0x20002344(SRAM内のコード)でした。停止1秒前のレジスタスナップショット：PWR_MODE 0、PWR_MODE_STATUS 0、WAKEUP_LEVEL 0x3、WAKEUP_MASK 0x20、WAKEUP_STATUS 0、PM2マスク 0x0/0x200/0x800000、SCR 0、ICSR 0x00400000、SOURCE_CLK_GATE 0x700100D2、NVIC ISER 0x00010400/0x00040000/0/0x00080000、ISPR3 0x120、SysTick CTRL 0x10007、CLKCTL0 PSCCTL0..2 0x02410E07/0x0E020001/0x8、CLKCTL1 PSCCTL0..2 0x08000D00/0x00010003/0x8000004D。アタッチ後、DHCSR = 0x01100001 (実行中)。

あなたの基準によれば、これは予期せぬクロックゲートであり、PM2遷移ではありません。さらに2つの観察結果：LPOSCでWWDT0を有効化した場合、FreeRTOSでは以前は停止が発生しなかった（70分で0）。Zephyrでは、アイドルループが毎回OSタイマーを読み取るビルドで、91ボード時間(約4ボード時間)停止なしで動作していましたが、現在それを分離しています。完全なレジスターのダンプを添付できます。次のステップとして何を提案しますか？また、これに関する既知の誤りはありますか？

Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

@dimush様、

最新情報のご提供ありがとうございます。

最も低いレジスタレベルやIPコマンドレベルで調査を続けると、誤った方向に進んでしまう可能性がある。別のアプローチを取るべきです。RW612とu-blox W10モジュールが正常に動作していると仮定し、SDKレベルから調査を再開します。

あなたはW10モジュールを使用しているとおっしゃっていましたね。私は以前、u-blox W10 EVKのデバッグを行ったことがあります。お使いのモジュールがFM25Q128A QSPI NORフラッシュを使用しているかどうかをご確認ください。その後、以下を検証できます:

• FCBフラッシュのタイミング設定。
• 実行時のLUT設定。

さらに、W10のPSRAMはお客様追加です。部品番号と仕様をお知らせください。また、LUTの設定も確認する必要があります。

ありがとうございます

よろしくお願いいたします。

魏東

Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r

ありがとう、ウェイドン。構成は以下のとおりです。完全なFCB、ランタイムレジスタ、および実行中のボードから読み取られたLUTワードは、添付のRW612_FlexSPI_config_dongle_c0.txtに記載されています。

フラッシュメモリ：はい、FM25Q128A - Fidelix、JEDEC ID F8 42 18、16 MB、ポートA1、XIPです（最初のレポートでは誤って「Fudan」と記載されていました）。0x08000400 の FCB は u-blox IRIS-W1 "Fidelex 8/16 MB" です。flash_config.c(FRDM-RW612 ベース): readSampleClkSrc 1 (DQS-pad ループバック)、CS ホールド/セットアップ 3/3、sflashPadType 4、serialClkFreq 7 (133 MHz 列挙; FRDM-RW612 は 5 = 100 MHz)、QE は WRSR 01h を介して 0x0200 で設定、シーケンス EBh 1-4-4 をモードバイト 0x00 と 4 つのダミーサイクルで読み出します (LUT 0x0A1804EB 0x32041E00 0x00002604)。ROMはこのパーツのSFDPを読み取れないため、フルFCBが使われます。

ランタイム:ブートローダーはFlexSPIのルートを130 MHzに設定します。Zephyrアプリケーションはコントローラ設定をXIPで維持し、ランタイムの読み込みLUTはFCBと同じで、PSRAM initはルートディバイダーを/3に設定します。MCR0.SERCLKDIV = 1 の場合、シリアルクロックは両方のポートで約 43 MHz になります (PSRAM SCLK で測定: 43 MHz)。MCR0 0xFFFF1110、MCR2 0x200009F7、AHBCR 0x00200078、FLSHA1CR1 0x63。

PSRAM: AP Memory APS1604M-3SQR、16 Mbit、2.7～3.6 V (3.3 V 電源)、QSPI SDR、DQS ピンなし (RDQS プルダウン)、3.3 V で最大 109 MHz、tCEM 8 μs。ポートB1：2MB、CSホールド/セットアップ3/3、データ有効時間1、書き込みマスクオフ。LUT を 6 つのダミーサイクルで EBh 1-4-4 を読み取り (0x0A1804EB 0x26043206)、38h 1-4-4 を書き込み (0x0A180438 0x00002200)、66h/99h をリセットします。CACHE64_CTRL1はシステムバスの0x39000000を通じてのみアクセスされます。XIPはコードバスをCACHE64_CTRL0で使用します。ENWRBUF = 0。この構成ではPSRAMのスコープで測定:SCK 43 MHz、CE#低パルスは最大19 us(APS1604M tCEMは8 us)。

ポートBのサンプリングはFRDM-RW612リファレンスと一致します（両ポートともDQSパッドループバック、RX_CLK_SRC_DIFF = 0）。

コアの停止についてですが、Zephyrでもトラブルシューティング設定(CTRL1でバッファを書き出す、プリフェッチをオフにする)でも同じことが起こりました。現在使用している2つのビルド（1つはトレースフックあり、アイドルフックなし、もう1つはアイドルループでOSタイマーを読み取る）は、停止することなく約50ボード時間稼働しました（予想では約2時間）。