h8/3052 GDB-stub上でのプログラムの実行 ITUタイマ割込みの使用について

質問

現在h8/3052でITUタイマを利用して20msecごとに割り込みがかかるようにするプログラムを作成していますが、割り込みに関して動作が確認できません。デバッグ環境を整えるためにターゲットにはあらかじめGDB-stubを書き込んであります。
実際に作成しているプログラムの割込みの部分は、
//割込み処理関数

pragma interrupt
void int_imia0(void) //割り込み関数
{
extern volatile unsigned int count;
count ++;
ITU0.TSR.BIT.IMFA = 0;
}
で割り込みが行われたときの処理を行い。
//メイン関数内
EnableInterrupt(); //割り込み許可
StartITU0(); //タイマスタート
while (1){
AD.CSR.BIT.ADST = 1; /*変換スタート*/
while (AD.CSR.BIT.ADF == 0); /*変換終了待ち*/

data[c] = AD.DRA >> 6; /*下位へ6ビット分ずらす*/
data[c] = data[c] & 0x3ff; /*上位6ビットクリア*/
time[c] =(count * 2000000) + (ITU0.TCNT * 32); /*A/D変換処理時間の算出*/
if(time[c]>20000000)
{
bleak;
}
}
のようにして、ここで20msecごとに割り込みがかかるように設定しています。
で、出力ファイルの
//MAPファイル
Name Origin Length Attributes
vectors 0x00220000 0x00000100 r
rom 0x00220100 0x00007f00 xr
ram 0x00228000 0x00007000 xrw
stack 0x0022f000 0x00001000 rw

vectorアドレス　ITU0割込みベクタアドレス（0x220060）
0x00220060 0x4 LONG 0x22020a DEFINED
(_int_imia0)?<code 340> (_int_imia0):<code 340> (_start)

として、外部RAM領域に設定したvectors領域のベクタ領域に割込み関数のアドレスが入るようにしています。
実際に動かすと、割込み関数でブレークポイントを設定しても割り込みがかからずにプログラムが動かなくなってしまいます。（どこかに飛んでいってしまっている。）

ここで質問なのですが、GDB-stub上でプログラムを動かす場合に、
・割り込みがかかった場合のベクタアドレスはGDB-stub側で設定しているベクタアドレス（内部ROM0x000060)に飛ぶようになってしまっているのか。
が、気になっています。

回答No.3

bug_bug

> 仮想ベクタ領域にターゲットプログラムの割り込み関数のアドレスを書き込めばOKということであってるでしょうか。

OKです。

> 一応STUB側の仮想ベクタテーブルに、、、
3052に限らず300HコアにはVBR(ベクターベースレジスタ)がありませんので、モニタプログラムがソフトウェア的に仮想ベクタテーブルを実装してくれています。
ハード仕様に応じてどのエリアがRAM空間かは決まっておりませんのでユーザー個人個人で仮想ベクターテーブルをどこに置いたか、プログラム(B)のビルド時に指定してあげないといけません。

さらにプログラム(A)はモニタデバッグ用(RAM上で動く用)のセクション割付をおこなった上でビルドする必要があります。

本来動かしたい自作プログラムはROM上で動くことを想定していても、デバッグ時には外付けRAM上で動かしますので、すべての関数アドレスやベクタテーブル、静的変数あらゆるものがオフセット(サンプルの場合0x220000)が加算されたアドレスに配置されます。
自作プログラム上での静的変数の参照や関数のコールすべてがオフセット加算されたアドレスを参照しなければならなくなりますので、デバッグ用のセクション割付で対応します。

これに気づいていないと、ISRから別関数をコールしたら、なんかROM領域へジャンプしてるっ！ってことになりかねません。
この辺りが「難易度が全然違う」と記した理由です。

もし動作に問題が残っていたら、開発環境とモニタプログラムの入手元を補足してもらえれば具体的にお話できるかもしれません。

お礼

ベクタテーブルをSTUBを構築する際に、3052のRAM領域(0xFFFDF10)に設定したので、測定を行うプログラムのコンパイルの際のベクタアドレスをそこの部分に設定してあげたら、動作が確認できました。

ありがとうございます。
まだ、質問があって新しく質問を書きました。（H83052　ITUタイマ機能　時間の測定について）もしわかることがあれば、教えていただきたいです。

回答No.2

bug_bug

あてずっぽうですが、よくあるミスとして
各レジスタはしっかり設定したつもりだったけどITU0の割り込み優先度が初期値0のままでマスクされており、実は割り込みが発生してなかったなんてことはないでしょか？(IPRA2)

以下、駄文です。

一般的にモニタプログラムを利用する場合、デバッグ対象である作成プログラム(A)とは別に、コアとなるプログラム(B)を先にターゲットのROM上へ書き込む必要があります。
プログラム(B)は多くの場合、雛形が用意されていますので、それぞれのターゲットのハード仕様に応じて適切な設定値の変更を利用者個人個人で行い、ビルドする必要があります。
（RAM上に展開するデバック対象プログラムの各セクションのアドレス指定が必要。ベクタテーブルの設定もここに含まれる）

■割り込み発生後の流れ
(1)3052はベクタテーブル固定で、プログラム(B)に記述された割り込みベクタがまず参照されます。
(2)プログラム(B)はRAM上にあるプログラム(A)のベクタテーブルを参照した上でISRをコールするようにコーディングされています。
（簡単に表現するなら、2段ジャンプするようなものです）

以上よりモニタプログラム環境構築で気をつける点べき点は、
(1)プログラム(B)を適切なマッピング情報を設定した上でビルドする
（設定すべきマッピング情報はプログラム(A)がRAM上に展開された状態を想定)
(2)モニタプログラム環境からプログラム(A)を想定しているRAM上に書き込む

加えて3052のタイマ割り込みを利用する上で気をつけるべき点は
(1)ハードウェアマニュアルを参照し適切なITU関連レジスタ設定を行う
(2)該当ITUの割り込み優先度を設定する(割り込みコントローラの設定)
(3)CPUのCCR割り込みマスクを解除する(アセンブラ記述、又は開発環境のライブラリを利用）
(4)タイマそのものをスタートさせる(タイマスタートレジスタの設定)

サンプルとして提示頂いたコードではモニタプログラム環境に問題があるのか、タイマ割り込みを利用するためのレジスタ設定などチップの駆動方法に問題があるのか、ちょっと切り分けができないですね。

モニタプログラム環境の構築が初めてであれば、メーカー保証のROMへの書き込み回数を気にせず自作プログラムでCPUを直接駆動し、スタートアップ処理や割り込み駆動に問題がないことを動作確認した上でデバッグ環境構築にトライした方がスムーズに進むと思いますよ。（難易度が全然違う為）

お礼

親切な回答ありがとうございます。
STUB（モニタ）側で設定されている2段ジャンプの2段目に設定されている仮想ベクタ領域にターゲットプログラムの割り込み関数のアドレスを書き込めばOKということであってるでしょうか。

一応STUB側の仮想ベクタテーブルにターゲットプログラムの割り込み関数のアドレスを書き込むように設定したら、割り込みがかかるようになりました。

回答No.1

zwi

Ｈ８は専門外なんですが、ターゲットのプログラムのベクタテーブルのアドレスの設定が行われていないようなのですが大丈夫なんでしょうか？
Ｈ８知らないので勘違いなら申し訳ない。