こんにちは、エキスパート
IASTから、M7アプリケーションがFR[AIBSEF]エラーを報告したという問題が報告されました。RTD4.0.2を使用していました。
S32G3 RM によると、AHB バースト サイズが BUFxCR[ADATSZ] のプリフェッチ サイズより大きい場合に AIBSEF がトリガーされます。BUF3CR[ADATSZ] が 0x80 であることを確認しました。これは、QSPI でサポートされている最大サイズ (1024 バイト) です。S32GレジスタのHBUSRTサイズを確認する方法をご存知ですか?この問題についてコメントをいただけませんか?
S32G RM にはもう 1 つの混乱点も見つかりました。WRAP* トランザクションは AHB 読み取りではサポートされていませんが、これは HBUSRT が実際には G3 ではサポートされていないことを意味するのでしょうか。もしそうなら、 FR[AIBSEF]の根本的な原因は何でしょうか?
こんにちは@arthur_shiさん、
QSPI で HBURST と HSIZE を設定する場所が見つかりませんでした。しかし、私の観点からすると、最大バースト = 16、最大 Hsize = 64 ビット = 8 バイトです。SO、AHB トランザクションの合計バースト サイズの最大値は 16 x 8 = 128 となり、1024 を超えることはできません。ドライバがビット FR[AIBSEF] を処理するのを確認できませんでした。ビット AIBSEF が発生した時点の QSPI のすべてのレジスタと QSPI 構成ファイルを送信していただけますか。問題を検出できるかどうか確認してみます。
よろしくお願いいたします。
ニ
画像から、AHB バッファは以下のように構成されているようです。
RM のマスター ID テーブルに従います。
ユーザーが M7 を使用している場合、マスター ID が他のバッファーと一致しないため、すべてのトランザクションがバッファー 3 にルーティングされるようです。しかし、バッファ 3 は 1024 に設定されているSO、なぜこのビットを取得できるのかわかりません。
ただし、バッファ構成を変更して、マスター ID がバッファ 0、1、2 と一致し、バッファ サイズが 0 で、シーケンス ID が 16 バイトのデータを示しているかどうかを確認できると思います。
複数のコアを使用している場合は、各マスター ID を異なるバッファーにルーティングしてみてください。たとえば、CM7_0 をバッファ 0 に、CM7_1 をバッファ 1 に、...
新しい AHB トランザクションを実行する前に、これらのビットが設定されているかどうかを確認してください。
これはお客様から受け取ったレジスターです
RM によると、AHB は WRAP と INCR の 2 つのタイプをサポートしているようです。しかし、S32G3 は INCR のみをサポートしています。HBurst と Hsize は QSPI では設定できません。これらは Core ドキュメントで定義され、起動時で構成されます。
お客様の場合、Core A53 のコア マスター ID 0、1、2 をバッファ 0、バッファ 1、バッファ 2 に設定し、バッファ サイズを 0 に設定しているため、バーストのサイズと比較するために使用されるデータ サイズは、シーケンス ID で設定されたデータです。彼らの場合、シーケンス内のデータ サイズは 16 バイトでした。起動時に設定されたバースト サイズがこの値より大きい場合、この問題が発生する可能性があります。
お客様からフィードバックを受け取りましたが、A53 コアからのアクセスを防止した後、問題は解消されました。したがって、この問題は A53 コアからの投機的なアクセスによって発生した可能性があります。このアクセスがAIBSEFエラーを引き起こす理由はわかりません。確認したいもう一つの質問は次のとおりです。
S32G3 QSPI は AHB バースト機能をサポートしていますか?前回のコメントでも述べたように、
QSPI は RM の AHB ワープ機能をサポートしていませんが、AHB バースト機能を紹介するセクションもあります。混乱しますか?この機能を確認するのにご協力いただけますでしょうか?