2403373_ja-JP

はい

MIMXRT1160 XIPがランダムに失敗する

私は、166MHzで動作する8ビットフラッシュメモリからXIPを実行する複数のボードを所有しています。そのうちの1つが、時折「未定義の命令」エラーで失敗する。

信号の整合性の問題を疑っていますが、PCBにテストポイントがないので、それを確認できる唯一の方法は速度を166MHzから133MHzに下げることで、そのボードの問題が「解決」しているようです。

このエラーは、mcubootからアプリケーションをチェーンロードするときに最も頻繁に出るのが示唆的です。アプリケーション実行時にはより稀です。信頼できるトリガー方法も見つかりません。故障が現れるまで何度も電源を入れ直す必要があります。

このXIPの故障をより正確に診断する方法はありますか?

Re: MIMXRT1160 XIP fails randomly

ご説明いただいた現象は、フラッシュデータラインのPCB配線や信号品質の余裕が限られているため、166MHzにおける読み出しサンプリングマージン（セットアップ/ホールド）が不足していることが原因である可能性が最も高いです。これにより両方の症状も説明できます。133 MHzに落とすとサンプリングウィンドウが広がり、問題が「消える」ことになります。そしてMCUbootのチェーンロードは、コールドリセット直後に最初に密度の高いキャッシュコールド命令フェッチであり、マージンが最も厳しい場所です。そのため、そこで最も失敗しやすく、ランタイムフェッチは主にキャッシュに当たってほとんどトリガーされません。

以下のチェックを推奨します。すべてソフトウェア側で、PCBテストポイントは不要です。

まずはダミーサイクルから始めましょう。読み出しLUT内のダミーサイクル数が、166MHzにおけるオクタルフラッシュのデータシート仕様と厳密に一致していることを確認してください。自動生成されたFCB(例:プロビジョニングツールからのもの)がより低い値を使用している場合は、データシートで指定された値に設定し、データ有効ウィンドウを広げてサンプリングマージンを拡大するために1〜2回のダミーサイクルを追加できます。ダミーサイクルが不十分なため、最初のデータビートがターンアラウンド/未確定領域に配置されてしまい、断続的なエラーの典型的な原因となる。
読み取りサンプルクロックソースを確認します。166 MHz はreadSampleClksrc=3 ( kFlexSPIReadSampleClk_ExternalInputFromDqsPad:フラッシュデバイスから提供されるストローブ/DQS を読み取る) の場合にのみ仕様を満たします。現在0または1の場合、166MHzは仕様外であり、これは「133MHzで修正される」という記述と完全に一致します。基板上に実際のDQSトレースが存在することを確認し、このモードを使用してください。

これらの調整後も断続的な故障が続く場合は、166 MHzのマージンボトルネックを上記のステップ1〜3で隔離しながら、安全な基準として133 MHzで動作できます。また、こちらの投稿も参考になるかもしれません： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/mp/2178828

幸運をお祈りしています、
ギャビン

Re: MIMXRT1160 XIP fails randomly

エラーログや回路図の共有が役立つかもしれませんが、今のところの故障率はどうでしょうか?

Re: MIMXRT1160 XIP fails randomly

こんにちは、 @Gavin_Jia さん。

読み取りコマンドを様々なダミーサイクル数でテストしてみましたが、やはりエラーが発生します。

フラッシュボラタイルレジスタのダミーサイクル数を20に設定し、166 MHzをサポートできるようにしました。フラッシュのデータシートによると、20回のダミーサイクルで最大200 MHzをサポートするはずです。

readSampleClksrc=3はbootROMによって設定され、デバッガ接続で確認されます。

DQSトレースは確かに存在する。

時には、アプリケーションが実行中、最初の大きなフラッシュ読み取りの後に故障が発生することがあります。

Re: MIMXRT1160 XIP fails randomly

こんにちは、 @tbonkers さん。

詳細なテストをありがとうございました。あなたの調査結果に基づくと、これは166MHzオクタルDDR XIPの読み出しパスがサンプリング／信号完全性マージンの限界付近で動作しているという状況と最も整合性が取れています。

readSampleClksrc=3 およびDQSトレースは必要条件ですが十分条件ではありません。DDR DQSモードでは、RT1160側はDQSからSIOへの相対スキューが~±1ナ秒以内に保たれ、166 MHzがインターフェースの上限であるため、マージンは最小限です。

さらに調査したところ、基板を改造することなく現在の問題を解決するのに役立つ可能性のある解決策が以下のとおりです。

DLLのエラータERR011377を適用してください。RT1160の訂正表には、DLLロックステータスビットが設定された後も、外部フラッシュへの即時読み書きがタイミングの問題により誤ったデータを返す可能性があると記載されています。回避策としては、ロックビットが設定されてから少なくとも512回のFlexSPIルートクロックサイクルを待ってからフラッシュにアクセスすることです。この遅延は、ブートローダーおよびFlexSPI/DLL/クロックを再設定するアプリケーションのすべてのパスに適用されるようにしてください。これは「チェーンロード時に最も頻繁で、実行時に断続的」とよく合致します。
定量化可能なRAM常駐ストレステストを実行します（繰り返し電源のオンオフよりも効果的です）。テストコードと障害ハンドラをITCM/OCRAMに配置し、CRC比較を使用してAHBメモリマップから大きなフラッシュブロックを繰り返し読み出し、166/133/120MHzをスイープします。周波数が低下するにつれてエラー率が急激に低下する場合、それはタイミング/SIマージンの問題を裏付けるものです。
mcubootのCASE、ブートローダーが外部NORを消去・プログラムした場合、アプリケーションにジャンプする前にI/Dキャッシュを無効化しなければなりません。また、アプリケーションが異なるクロック/DLL/LUT/パッド設定でFlexSPIを再初期化していないかも確認してください。

最終的に166MHzのみが故障し、133MHzが安定している場合は、現在の基板の安全な動作周波数として133MHzを推奨します。166MHzが生産上必須の場合は、PCBのDQS/SCLK/SIOの長さのマッチング、インピーダンス、クロストーク、パッド駆動強度を見直し、次回の改訂でこれらの信号のテストポイントを追加する必要があります。

よろしくお願いします、
ギャビン