デバッガでプログラム実行中に、あるメモリ領域にウェイトなどでハードウェアとしてアクセスできない時間が一定以上あると、デバッガはターゲットからの通信が切断されたと判断し、以下のようなエラーを表示します。
ULINK - Cortex-M Error Cannot access target Shutting down debug session.
質問
ULINK接続時にタイムアウト時間を長くする方法、もしくはエラー判定自体を無効化する方法はありますか
回答
●タイムアウト時間の変更
ULINK使用時にタイムアウト時間の修正は現状できません。
また、タイムアウト時間の詳細に関する仕様は、現在ARM社より公開されておりません。
●リトライ回数の変更
ULINK使用時にリトライ回数を明示的に設定することは、現状できません。
通常、 ULINK2/pro ～ DAP 間の JTAG/SWD 通信するための最低周波数は5kHzであるため、CPU動作周波数がそれよりも高速な周波数であれば通信可能です。
しかし以下の場合で、ULINK側がどの程度待つことが可能かは仕様によって明示されておりません。
- 複数データ通信中に次データ受信までの時間が非常に長い場合
- CPU動作周波数が5kHz以下で動作する場合
デバッグ接続がコア（あるいはDAPバス）よりも早いなら、デバッガからの要求は1つ以上のACK[0:2] = WAITの応答を受け取ります。そして、デバッガはOK/FAULT応答を受け取るまで、同じ要求を繰り返し ます。
しかし実際は、ホストPC側は無制限に要求が処理されるのを待つのではなく、TCK/SWCLKが高速なほど、そのリトライ回数は制限されます。
ただし、リトライ数は TCK/SWCLK 周波数によって変わるのではなく、アクセスタイプとレイヤタイプに依存します。
具体的には、ULINK デバッグドライバがリトライするように、ULINK2 ファームウェアでもまた、デバッグドライバがリトライする度に数回リトライしますが、その内部的な情報は、現時点で公開されておりません。
よって、リトライ回数は、ご使用の環境に依存します。