SAF ライブラリの Scheck_Dma_RamBlockingTransfer および sCheck_CortexM7_ErrRead 関数のアセンブリ コードでいくつかの問題が発生しています。int_sram_no_cacheable セクションのメモリ マップ内にセクションがあり、そこに 3 つの特定のセクションがすべて保持されます。
SO、現時点での問題は、同様のメモリ マップを持つ GHS ベースのコンパイラーを使用した作業プロジェクトがあり、それがうまく動作していることです。動作中のソフトウェアをベースにサードパーティの BSW スタックを追加すると、いくつかの問題が発生しますが、メモリ マップ ファイルとすべてが同じであり、すべてのセクションが適切に表示されます。メモリ セクションではメモリの重複は見られません。各セクションには十分なメモリがあります。しかし、上記の機能は互いに重複しているようにCAN見えます。
作業中のプロジェクト画像:
非動作プロジェクト画像:
これらの比較では違いがわかります。これらの関数は重複している部分があり、マップ ファイルに記載されているとおりに一致していません。現在、これらの関数を実行しているときにハードフォールト ハンドラー エラーが発生しています。
CAN なぜこのような行動が見られるのかを正確に特定するのを手伝っていただけますか。電話してこの問題について報告していただければ非常に助かります。これは、私たちにとって、このプロジェクトの統合に向けた次のステップへの一種の障害となります。
こんにちは、 @vinaychitturiさん、
おそらく、リンカー ファイルでセクションを 64 バイトにCANでしょう。
. = ALIGN(64);
SAF バージョンは特定の RTD ドライバと互換性があり、ドライバのリリース ノートには GHS コンパイラおよびリンカー オプションが指定されています。プロジェクトのオプションをCAN確認できますか?
MPU に関しては、MPU 領域はそのサイズに合わせて調整する必要があり、これは ARM が指定した方法です。32KB の領域がある場合は、32KB に揃える必要があります。ただし、領域のサイズは 8KB または 16KB にすることもCAN。
よろしくお願いいたします。
ダニエル
こんにちは@danielmartynek
起動コードを確認して、何が起こっているのか、なぜ重複の問題が発生しているのかを確認しました。
作業プロジェクト:
このプロジェクトでは、.mcal_const_no_cacheable の後の sram_no_cacheable セクションの ROM セクションと RAM セクションでわかるように、ramcode_no_cacheable に 68 バイトのギャップが使用されています。しかし、そのギャップは RAM と ROM の両方に存在するので、それは良いことです。SO、コピーしようとすると、RAMとROMに同じギャップがあるため、初期化中にフラッシュからSRAMにセクション全体をコピーすることができます。
非稼働プロジェクト:
この非動作プロジェクトでは、.mcal_const_no_cacheable の後の sram_no_cacheable セクションの ROM および RAM セクションでCANように、ROM では ramcode_no_cacheable に 4 バイトのギャップが、RAM では 68 バイトのギャップが使用されています。しかし、そのギャップは RAM と ROM の両方で同じではありません。SO、初期化中にフラッシュから SRAM にコピーするときに、RAM と ROM のバイト ギャップの違いによりコピーが重複してしまいます。
動作するものと動作しないものの両方を添付しました。SO、私の質問は、なぜこれら 2 つのプロジェクトで ROM と RAM のメモリ配置が異なっているのか、どうすれば ROM と RAM に同様の配置と同様のギャップを持たせることがCANのかということです。
前回の返信では、MPU アライン ベース アドレスに従って 32kb をアラインする必要があるとおっしゃっていましたが、それほど多くの non_cacheable メモリは使用されていません。リンカー ファイルでは、no_cacehable 全体は 0x4d00 バイトのみです。MPU でどのような変更を行う必要がありますか?
ファイルをありがとうございます。
__RAM_NO_CACHEABLE_START で始まる MPU 領域のサイズが 32 KB であることに気付きました。つまり、MPU 領域をサイズに合わせて調整する必要があります。
32KB = 0x8000 に揃えてみてはいかがでしょうか?
これが根本的な原因だと言っているのではないが、一致させる必要がある。
よろしくお願いいたします。
ダニエル
こんにちは@danielmartynek
リンカー ファイルとスタートアップ コードを共有しました。おっしゃるとおり、スタートアップ コードのシーケンスも調べてみます。
こんにちは、 @vinaychitturiさん、
MAP ファイルに正しい配置が示されている場合、問題はフラッシュから SRAM へのコードのコピー プロセスにある可能性があります。
コードを SRAM にコピーするリンカー スクリプトとスタートアップ コードを共有していただけますか?
さらに、影響を受ける関数が存在すると想定される SRAM アドレスにウォッチポイントを配置するCAN。次に、スタートアップ コードをステップ実行して、メモリがどのように初期化されているか、コピー プロセス中に破損や不整合が発生しているかどうかを確認します。
よろしくお願いいたします。
ダニエル