何故デバッグしているコードがMMU/MPUが有効になる前はブレークポイントやステップが動作しませんか

適用範囲：DS-5

現象

DS-5デバッガはブレークポイントのヒットに失敗したり、ステップがターゲットを実行させてしまうことがあります。稀なケースにおいて、メモリの中身の修正(イメージのロードなど)が命令を破壊することがあります。

原因

明示的なブレークポイントの配置や、コード内での高レベルステップ時にソフトウェアブレークポイントがDS-5デバッガで使われることがあります。ハードウェアブレークポイントとソフトウェアブレークポイントの違いに関する情報はここで確認できます。

ソフトウェアブレークポイントの使用または明示的なメモリの書き換えはターゲットプロセッサによってメモリの変更が正しく検出されるよう、デバッガによるキャッシュメンテナンス処理が必要とされます。

DS-5デバッガはプロセッサ上のメモリ管理ユニット(MMU/MPU)がまだ無効で、L2キャッシュコントローラが有効である間はメモリの更新を不正に扱います。この状況では要求されるキャッシュのメンテナンスが実行されていません。

例：

• bare-metalアプリケーションがMMU/MPUを有効にする前にL2キャッシュコントローラを有効にしました。L2キャッシュが有効になっていますが、MMUが有効になる前にはコード領域内のステップ実行とブレークポイントは失敗します。
• ターゲット上で動作しているブートローダはL2キャッシュは有効、MMU/MPUは無効のままにします。ここではデバッガによってアプリケーションがメモリにロードされる前でも問題がおきる状況にあります。このケースではイメージのロードがメモリを破壊する可能性があります。

解決策

この問題にはいくつかの回避策があります：

1. イメージをロードせずにターゲットに接続し、registerペインまたはmemoryペインを使ってbare-metalデバッグセッションの開始前には明示的にL2キャッシュコントローラを無効にしておきます(これは接続シーケンスにおける簡単なDS-5スクリプトを追加することで自動化することもできます)。
   これはbare-metalアプリケーションがロードされる前に問題の発生する状況が存在するケースを解決するでしょう。
2. MMU/MPUが有効になるまでL2キャッシュが無効なままになるようアプリケーションのスタートアップコードを書き換えます。
3. アプリケーション内の影響をうけるコード領域へのブレークポイントの変更やステップを避けます。
4. "hbreak <symbol>"コマンドを使用して明示的にハードウェアブレークポイントを配置します。
5. "stepi"コマンドを使用して、高レベルステップのかわりに命令レベルのステップを使用します。

最後の4つの方法は、イメージロード前にL2が有効になっていない(MMU/MPUも無効)場合のみ有用です。