V850用JTAG-ICEの開発(つづき)

開発中のV850用JTAGデバッガがだいぶん完成に近づいてきました。

今回のJTAGデバッガは、内蔵フラッシュROMにも、内蔵RAMにも同じようにダウンロードできます。あと1ヶ月以内にリリースされると思います。ご期待ください。

先週末には、このJTAGデバッガと、GCCやGDBとの連携を確認しました。
GDBスタブ機能を動かして、GDBやInsightから接続を受けて動作できるのを確認しました。

V850のプログラムをRAM上で動くようにGCCでコンパイルしダウンロードして実行すると、FPLでROMに書き込んでから実行するのとくらべて、圧倒的に待ち時間が短くできます。

GDBとの接続を試していて困ったことは、GDBはV850のレジスタが66個もあると思い込んで作られていること。
V850には32個の汎用レジスタと12個のシステムレジスタしかありませんが、GDBはシステムレジスタが32個あると仮定して未定義なものも含めて読み出そうとしてきます。さらにプログラムカウンタと、FPという謎のレジスタも含めて66個を読み出そうとしてきます。
V850のマニュアルを読んでもFPなんてレジスタはないので、なんだこりゃということになるのですが、どうやらGDBのソースを読んでみるとFPというのはレジスタ29の別名らしいです。GCCが関数呼び出しの最適化にでも使うものなのでしょうか。詳細は不明。

それから、GDBはリモート接続した際に、RUNコマンドが入力されると、勝手にkillパケットというのをスタブに送ってしまうようです。killパケットを受け取ったらスタブは接続を切断しなければならず、その後どのようにしてよいやら。killを送ったGDBのほうはTCPの接続を切ったつもりになっているので、スタブ側から何を送ってもそれ以降GDBは反応しなくなります。

GDBのソースを読んでみると、ターゲットのPIDがヌルなIDでなくターゲットが既に実行中の場合には、RUNの前にKILLを行う、という方針になっていました。
うーん、GDBのリモート機能というのは、ターゲットとの論理的な接続と、ターゲットCPUのプロセスが動作しているかことがごっちゃになっているような感じなのですが、なんでなのかは詳しくはわかりません。調べてもいません。そういうものなのでしょう。

ターゲットにKILLコマンドを送った後、じっと待ってればGDBから再接続を試みてくるので、何度かやれば正常にRUNできるのですが、気持ちが悪いです。
ともかく、LOADコマンドでプログラムをロードしたら、RUNではなく、CONTでプログラムを動かせばよいようなので困ることはないようです。

ああ、Insightは重いし不安定。GDBは気絶するほど難解な操作性。
正直、マニア以外にはきついです。
BorlandやMicrosoftの統合開発環境でWindowsのプログラムをデバッグするのとは雲泥の差です。

もうGDBは介さずに、JTAGデバッガ上からCのソースコードデバッグができるようにしたいなと、すこし思い始めてきました。