e2studioのデバッグ時のGDBコマンドについて教えてください。
現在e2studio7.4.0、CCRX:3.01.00、E1、RX64Mの組み合わせでデバッグを行っています。
デバッグ時にプログラムの一部を外部RAM（CS3）にダウンロードしたいため以下のknowledgeBaseを参照してCS領域を有効にするGDBコマンドを記入しました。https://ja.na4.teamsupport.com/knowledgeBase/19412977しかし、ダウンロード終了後（「再開」ボタン押下前）にメモリを確認するとデータがオール0の状態でダウンロードできていませんでした。
試しに「初期化コマンド」の欄内でなく、「コマンドを実行」の欄内にGDBコマンドを移し、ダウンロード終了後にメモリを確認したところ該当アドレスは不定な値（初期化完了直後の状態？）となっていたため、その状態でダウンロードボタンを押下することでプログラムが正しくメモリに配置されました。
つきましては以下についてお分かりになれば教えていただけますでしょうか。
①「初期化コマンド」のGDBコマンドと「コマンドを実行」のGDBコマンドとプログラムのダウンロードは どのような順番で行われるのでしょうか。
②外部RAMにダウンロードしてデバッグする手順、もしくは近しい情報が載っている資料等があれば 教えていただけますでしょうか。
※尚、GDBコマンドは以下を実行しています。set {short} 0x000803fe = 0xa50b プロテクト解除set {short} 0x00080006 = 0x5a03 内臓ROM有効、外部バス有効set {short} 0x00080008 = 0x003f RAM有効、ECCRAM無効、スタンバイRAM無効set {short} 0x00083822 = 0x0001 CS2設定set {short} 0x0008382a = 0x0203 CS2設定set {short} 0x00083022 = 0x0301 CS2設定set {long} 0x00083024 = 0x06040604 CS2設定set {long} 0x00083028 = 0x01100110 CS2設定set {short} 0x00083832 = 0x0001 CS3設定set {short} 0x0008383a = 0x0203 CS3設定set {short} 0x00083032 = 0x0301 CS3設定set {long} 0x00083034 = 0x05030503 CS3設定set {long} 0x00083038 = 0x01100110 CS3設定set {short} 0x00083852 = 0x0001 CS5設定set {short} 0x0008385a = 0x0202 CS5設定set {short} 0x00083052 = 0x0301 CS5設定set {long} 0x00083054 = 0x06030603 CS5設定set {long} 0x00083058 = 0x01100110 CS5設定set {short} 0x00083880 = 0x00ff CS有効set {char} 0x0008c106 = 0x5d 外部バス制御レジスタの設定set {char} 0x0008c104 = 0xff 外部バス制御レジスタの設定set {char} 0x0008c105 = 0x7f 外部バス制御レジスタの設定set {char} 0x0008c102 = 0x00 CS出力レジスタの設定set {char} 0x0008c103 = 0x00 CS出力レジスタの設定set {char} 0x0008c100 = 0x2c CS出力レジスタの設定set {short} 0x000803fe = 0xa500 プロテクト
zmbさんほや です。こんにちは。
> 「初期化コマンド」のGDBコマンドと「コマンドを実行」のGDBコマンドとプログラムのダウンロードはどのような順番で行われるのでしょうか。
これについては、無害なGDBコマンド(info mem とか)をそれぞれに入れて実際にデバッガを起動して、GDB traceで確認すれば分かると思います。適当なRXプロジェクトでやってみるとダウンロードが始まる直前で初期化の方のコマンドが実行され、ダウンロードが終わってmain関数にbreakpointを張った後、リセットベクタに飛ぶ前辺りで後の方のコマンド(「コマンドを実行」欄)が実行されています。
GDBコマンドは、デバッガが立ち上がってからなら「Debugger Console」にコピペでコマンドを打てるのでテキストファイルで持っておいて適当なタイミングで実行させるような使い方もできます。
「コマンドを実行」(Run Commands)欄のコマンドはResetボタン押下時(reset直後)も呼ばれるようです。Restartでは呼ばれませんでした。
ほやさん詳細なご回答ありがとうございます。
順序について理解することができました。また、「Debugger Console」からのコピペでもCS領域が初期化できることを確認できました。
また、GDB trace（コンソールの中にあったのですね...）を比較してコマンドの実行タイミングがご説明いただいたとおりであることも確認できました。いずれの場合も設定コマンド実行後"Done"となっており設定動作単体ではエラーや差異はないように見受けられました。
ただ「初期化コマンド」の方の設定コマンドが反映されない、且つメモリにダウンロードできない現象は変わらないため試しに「初期化コマンド」と「コマンドを実行」両方の欄に同じ設定コマンドを入れた場合、何故か最初のbreak時点でメモリにデータが反映されており、期待する動作を行うことができました。
どういう理屈で成功したのかわからないですがやはりGDB traceの中を解析するしかヒントはないのですかね。
zmbさん、こんにちは。NoMaYと申します。裏を取る(より確実に把握する)にはgdb traceの内容をチェックした方が良いですけれども、次のような観点から合点が行くようなことはないでしょうか？デバッガは諸般の事情でCPUリセットを何度も掛けたりします。ですが理屈的には以下のようなことが出来ると思うのですけれど。(でも実際に出来ていない、ということなのですね？)(1) 初期化コマンド群で外部RAMのCS等の設定完了(2) 外部RAMへダウンロード(3) CPUリセットが入る(かも知れない)(4) 実行コマンド群で外部RAMのCS等の再度設定完了(5) ソフトウェアブレークポイントなど設定(設定されていれば)(6) ブレークした時点で外部RAMの内容をメモリウィンドウで確認可能(な筈)
NoMaYさん
有用な情報をいただきありがとうございます。
>デバッガは諸般の事情でCPUリセットを何度も掛けたりします
>(3) CPUリセットが入る(かも知れない)
確かにご推察いただいたとおりの動作をしている場合は失敗時（初期化コマンド群のみ or 実行コマンド群のみ）の結果も成功時（初期化コマンド群 and 実行コマンド群）の結果も合点がいきます。
この観点でもう一度gdb traceを確認してみようと思います。ありがとうございました！
> この観点でもう一度gdb traceを確認してみようと思います。resetの前か後かも大事ですが、所詮GDB traceで見えるのはGDB serverとGDBの間のやり取りだけで、CPU上で実際何が起きているかまでは分かりません。単にコマンドを入れるタイミングの問題であればダミーのコマンドを最初にいくつか入れてやれば済むかもしれません。スタートアップコードを一回走らせた後でなら動くと言うのであれば、別の問題も考えられます。
ほやさん新たに情報をいただきありがとうございます。
今のところ上記の状態でCS領域関連レジスタの反映と外部RAM上へのプログラムの配置に成功できるのは以下の２つ手順の時になります。
【手順A】1.初期化コマンド欄にCS領域初期化関連コマンドを設定2.コマンド実行欄にCS領域初期化関連コマンドを設定3.デバッグ実行
【手順B】1.初期化コマンド欄にCS領域初期化関連コマンドを設定2.デバッグ実行3.エントリーポイントでbreak時にDebugger ConsoleからCS領域初期化関連コマンドを実行
GDB TraseでNoMaYさんのおっしゃった(3) のタイミングを確認していたところ"monitor reset"というコマンドが何回か実行されていたため試しに手順Aの後にDebugger Consoleから"monitor reset"と実行したところレジスタが初期値になりダウンロードしたデータが「メモリ」上で見えなくなりました。さらにその後、手順Bの3を実行したところダウンロードしたデータが見えるようになりました。
これらのことから"monitor reset"コマンドが実行されるためレジスタの値が初期化され、メモリ上のダウンロードデータが見えなくなるということがわかりました。
ほやさんとNoMaYさんから頂いた情報にて原因や動作の詳細について判明しました。"monitor reset"を抑止させたいのですが諸般の事情があると思うのでこのプロジェクトのデバッグはひとまず手順Aで行おうと思います。大変ありがとうございました。
「Debugger」タブ内の「デバッグ・ツール設定」で「ダウンロード後にリセットする」がデフォルトで「はい」になっているのをいいえにすれば１回減ると思います。おっしゃる通りリセットするにも意味はあるはずなので全くリセットしないで済ませるのは難しいでしょうけれど。