こんにちは、
AT_NONCACHEABLE_SECTION_INITとfsl_dcp.cでのその使用方法についていくつか質問があります。
これにより、「NonCacheable.init」に変数が配置されることになります。セクション。このセクションの名前は、キャッシュされないが初期化される領域であることを示唆している。おそらく、その変数はコア以外のマスターによってアクセスされる必要があるのだろう。
例として、evkmimxrt1020_dcp(RT1020-EVK用)を見てみましょう。
この例のリンカースクリプトは「NonCacheable.init」を.dataに配置します。(したがってDTCでは)初期化されますが、指定された非キャッシュ領域ではありません。
これは問題になりそうだ!
DCPドライバでAT_NONCACHEABLE_SECTION_INIT()がどのように使用されているかも見ていきましょう。
変数`s_dcpContextSwitchingBuffer`が初期化されていません!
つまり、2つのシナリオが考えられます。
よろしくお願いいたします
最大
こんにちは、 @mastupristi さん。
詳細な分析をありがとうございました。ご指摘いただいた両方の点について検討いたしました。
1. NonCacheable.init は DTCM に配置されています — キャッシュの一貫性の問題ではありません
リンカースクリプトが`NonCacheable.init`を配置するというあなたの指摘は正しいです。`.data` に格納され、`SRAM_DTC` (DTCM) に存在します。
しかし、これはRT1020におけるキャッシュコヒーレンシの問題を引き起こすものではありません。DTCMはCortex-M7上で密接に結合されたメモリであり、そのアクセスパスはハードウェア設計によってL1 Dキャッシュを完全にバイパスする。DTCM内のデータは、別途名前の付いた`NCACHE_REGION`には配置されていませんが、本質的にキャッシュ不可能であり、DCPなどのDMA対応周辺機器がアクセスしても安全です。
このアプリケーションノート(AN)をご確認ください: https://www.nxp.com/docs/en/application-note/AN12042.pdf
また、リンカースクリプトを変更してこのセクションをOCRAMまたはSDRAMに配置する場合は、対応するMPU領域がキャッシュ不可として構成されているか、ドライバ/アプリケーションが適切なキャッシュメンテナンス(クリーン/無効化)を実行していることを確認する必要があります。
2. マクロの使用 — 正しい観察、機能への影響なし
おっしゃる通り、`s_dcpContextSwitchingBuffer` は明示的な初期化子なしで `AT_NONCACHEABLE_SECTION_INIT()` を使用します。SDKの慣例に従い、`AT_NONCACHEABLE_SECTION_INIT()`はゼロ以外の初期値を持つ変数(`= {xx}`)を対象とし、`AT_NONCACHEABLE_SECTION()`はゼロで初期化された変数を対象としています。
この変数は静的な記憶期間を持つため、C言語は必ずゼロ初期化を保証します。つまり、機能的なバグはありません。バッファは特定の初期値に依存しません。DCPハードウェアが実行時にその内容を管理します。
とはいえ、`AT_NONCACHEABLE_SECTION()` を使用する方が意味的に適切であり、208バイトのフラッシュメモリを節約できます。私たちはこれをコード品質改善の機会と捉えています。
よろしくお願いします、
ギャビン