製品情報 | 機能 | 仕様 | 対応CPU | VerUP | FAQ | 解説テキスト | 接続図 | GNU/gcc | ルネサスC | ||||||||||||||||||||||||||||||||||||
皆様よりいただいたご質問等を、このページに反映させていきたいと思いますのでよろしくお願いします。 H−debugger+DEF | デバッガ用ソフトウェアパーツ ■H−debugger+DEF SH-2品種のBOOT-UBC仕様の場合にデバッガ起動及び「RstMon」でSP値がベクタ1値と相違がありますが何故ですか。(対象:BOOT-UBC) BOOT-UBC仕様の場合、デバッガからのRESET->NMIを起動させるまで、ターゲット側のプログラムは走行します。 その走行中にSP値を操作するコードがありますとSP値は変化してしまいます。 対応策として、mainへ飛ぶ前にソフトタイマー(20ms〜200ms)を入れるか、SPを再設定するコードを入れて下さい。 <対応1> SoftTimer(20); <対応2> mov #4,r0 mov.l @r0,sp TOP デバッガ操作のみで外部I/Oへのパルス出力をしたいのですが、どう操作すればよいですか。(対象:一般) メモリーセットコマンドとパイプライン処理の複合で、コマンド入力部に直接入力で対応して下さい。 ex) 1000 S PBDRL 1 W.100 | 1000 S PBDRL 0 W,100 ↑1000回 PBDRL<0bit>に、約100ms毎に[1],[0]を書いてパルス出力します。 時間に関しては、ソフト処理および通信処理時間により+α(約30ms)の誤差はあります。 (DEFバージョン7.10B以上) TOP Dump窓にて直接アドレスのロングアクセス(DWORD)で参照したいのでが、どうしたらよいですか。(対象:一般) Dump窓のシンボル入力部でキャスト演算子との組み合わせで指定して下さい。 ex) (long)0xffff_0000 参考項目として、ワードアクセス(WORD)の場合は、(short)キャストになります。 TOP BOOT-PBC、BOOT-UBC、H-UDI仕様について、各どういう仕様なのかよくわかりません。(対象:一般) なかなか説明しにくのですが、簡単に言いますと、 --------------------------------------------------------------------------------------------- <H-UDI> ・デバッグ用ファームは非公開エリアに入り、E10A用ポートと非公開のブレークコントローラを使用します。 ・オンチップデバッガE10A(ルネサス製)のハード仕様に、準拠させたタイプになります。 --------------------------------------------------------------------------------------------- <E10T> ・デバッグ用ファームは非公開エリアに入り、E10T用ポートと非公開のブレークコントローラを使用します。 ・オンチップデバッガE10T(ルネサス製)のハード仕様に、準拠させたタイプになります。 --------------------------------------------------------------------------------------------- <E8> ・デバッグ用ファームは、内臓FROMに入り、E8用ポートとCPU内蔵のアドレスブレークを利用したデバッガになります。 ・オンチップデバッガE8(ルネサス製)のハード仕様に、準拠させたタイプになります。 --------------------------------------------------------------------------------------------- <BOOT-UBC> ・デバッグ用ファームは、内臓FROMに入り、BOOT用SCI(+SCK)ポートとCPU内臓のUBCを利用したデバッガになります。 --------------------------------------------------------------------------------------------- <BOOT-PBC> ・デバッグ用ファームは、内臓FROMに入り、BOOT用SCI(+SCK)ポートとCPU内臓のPBCを利用したデバッガになります。 --------------------------------------------------------------------------------------------- <BOOT-PBC無> ・デバッグ用ファームは、内臓FROMに入り、BOOT用SCI(+SCK)ポートを使用したデバッガになります。 なお、この品種はハードブレーク機能が無いタイプになります。 --------------------------------------------------------------------------------------------- 当然、CPUの使用ピンも違ってきますし、デバッグ機能にも相違があります。 対応CPUと制限事項に簡単にまとめた表がありますのでご覧下さい。 TOP H8/Tinyシリーズで電池バックアップされたシステムですが、FROMに書込みした場合の注意事項はありますか?(対象:H8/Tiny) H8/Tinyシリーズの場合、FROMに書く時の手順として高速ブートモード(エミュレーションモード)に遷移させてからFROM書き込みシーケンスに移行させています。高速ブートモード中は外部からのRESET信号が無効になってしまいますので、書き込み後H-debuggeを外した状態で、かつモニタ(ファーム)が起動出来ない状態の場合、VCCをOV(ゼロ)に落とし、必ず高速ブートモードから抜けさせて下さい。 TOP 外部RAM仕様でデバッグをしていますが、ダウンロードする時に「範囲内は内蔵フラッシュROMに、超過部分はRAMデバイスに転送します。はい」で実施しますと転送スピードが遅くなり、「超過部分のみRAMデバイスに転送します。(ROMエリアはべリファイ実施)いいえ」で実施しますとベリファイエラーが表示されます。なぜですか?(対象:全CPU) この外部RAM仕様でのデバッグでは、DEFバージョン6.50Aまでは、ベクタテーブルとスタートアップ関数部分(ROMエリア)のコードが入ったHEXファイルが前提になっています。この症状は多分、外部RAM部分のコードしかないHEXファイルだと思います。必ずROMエリアも含めたHEXファイルでダウンロードして下さい。 ただし、DEFバージョン6.60Aより、外部RAMエリア単独のHEXファイルもダウンロード出来るように機能追加をしました。 ただ、この時も同じようにBSC設定用スクリプトファイルを必ず登録して下さい。 TOP ルネサスC(統合環境)使用でブート仕様CPUをデバッグする時にルネサスC添付のスタートアップ関数をステップ実行でデバッグしたいのですが手順を教えて下さい?(対象:ブート仕様CPU) 割込みモード2の場合の例で説明します。 resetprg.c ------------------------------------------------------------------------------- #include "iodefine.h" // @ <-追加 #pragma section ResetPRG __entry(vect=0) void PowerON_Reset(void) { SYSCR.BIT.INTM = 2; // A割り込みモード2にします。 set_imask_exr(0x6); // Bこの命令を入れるか、ステップ実行時にショートPBの「DI」をクリックします。Debug終了時コメントにする。 SoftWait(1); // C1ms Wait CPU設定で200ms遅延防止タイマを使用しない場合の例です。 _INITSCT(); ・ ・ ------------------------------------------------------------------------------- 上記の例のように、PowerON_Reset(void)関数の頭より、_INITSCT();の間にA〜Cの命令を記述して下さい。 Bに関しては、記述しなくてもショートPBの「DI」で代用できます。 このように記述しておきますと、Reset->NMIが掛かる間にデバッグに必要な手続きが済みますので、最初からステップ実行等が、 できるようになります。 TOP ブート仕様CPUで初めて基板の電源をONにするのですが、デバッグ可能状態にするには、どのような手順で進めたら良いでしょうか? (対象:ブート仕様CPU) 初めて基板の電源を入れる場合、ターゲット基板との通信を可能にする為、モニタの書き込みが必要になります。 手順としては、 @<ファイル>−<ブートロード>−<モニタプログラム>の操作で、基板にモニタのみを書きます。 この操作により、リセットベクタアドレスに「bra 0x800」等の閉ループのニモニックが書かれますが、CPUが暴走しない為の対策です。 A一度モニタが入りましたら、ユーザ作成のアプリを<ファイル>−<ダウンロード>で、内蔵FROMにプログラムを書きます。 この操作により、ユーザプログラムモードで、アプリとモニタを自動添付してFROMに書きますのでA番の繰り返しで、 デバッグ作業が可能となります。 TOP ルネサスC(統合環境)の設定で、HEXファイル(*.mot)とHCsymconvが作成する(*.sym/*.lin)を<Debug>ディレクトリに作成したいのですが、どうしたら良いですか?(対象:R8C以外) 弊社提供のサンプルは、全てプロジェクトディレクトに作成するパターンになっていますが、<Debug>CONFIGDIRに作成することも可能です。 設定変更は2箇所あります。 @<最適化リンカ>−<カテゴリ:出力>の<オプション項目:出力ファイル:$(CONFIGDIR)\$(PROJECTNAME).mot>に設定する。 通常デフォルト状態です。 A「HCsymconv」のオプション項目を<"$(CONFIGDIR)\$(PROJECTNAME)" >のみの指定にします。 この指定で、<Debug>CONFIGDIRから「*.dbg」を読んで、同じディレクトリに「*.LIN/*.SYM」を作成することになります。 また、HCsymconvのオプションSW「-r」を外した例になっていますので、各Cソースが別々のディレクトリに有ってもCソースデバッグ可能となります。 (DEFバージョン4.20A以上) TOP 回路図(H8-3048F-ONE_3029F.PDF)をダウンロードして確認したのですが,ここで質問があります。 この回路図はモード7との事ですが、トランジスタでMD1,0を制御しているため、MD2が'H'のときはMD1,0が'L'、 MD2が'L'のときはMD1,0が'H'で、MD2,1,0が'H'のモード7にはならないような気がするですが...。(対象:H8/3029,3048F-ONE) 確かに言われる通りですがH8/3048F-ONEの場合、エミュレーションモードへの遷移時に、このモード選択方式となります。 エミュレーションモードに遷移させる場合、一時的にMD2:H MD1:L MD0:L にする必要があり、 これは、ルネサスの非公開技術資料の為、公開はできませんが、この手順が必要となります。 そして、ファーム転送後、MD2:Lにして通常モードにしています。 【エミュレーションモード遷移時の動作モード】 MD2 MD1 MD0 L H H (モード7) L H L (モード6) L L H (モード5) となります。 TOP H8/3029,3048F-ONEで「エミュレーションモード遷移」が成功しません。何故でしょうか?(対象:H8/3029,3048F-ONE) まずは下記内容を確認して下さい。 【操作確認】 @「エミュレーション」−「モード遷移」の操作時、初めてH-debuggerで接続する場合は、 「フラッシュROM全消去指示」を「する」側にチェックして下さい。 【ハード確認1】 H-debuggerとターゲットとの接続確認をします。 @ターゲット接続テストツール「DEF5.20A以上」で、各信号のLOW/HIGH/パルス状態の波形計測をして下さい。 【ハード確認2】 CPUが正常動作するか下記手順にて確認をします。(CPUが初期状態であることが条件です。) CPU設定が「H8/3048F-ONE」又は「H8/3029F」になっているままで、DEFを終了させて下さい。 @ターゲットの電源を入れなおす。 ADEFを立ち上げる。 B【ターゲット接続テストツール】を起動する。 CSD1:High(出力) DSCK:High(出力) ENMI:High(出力) FFWE:High(出力) GMD0:Low MD1:Lowにして下さい。 HRST:Low(出力) IRST:High(出力) JSD1:Low(出力) KRST:Low(出力) LRST:High(出力) MSD2:Low【入力】<−確認【重要】モード遷移の入口です。 NSD1:High(出力) OSD2:High【入力】<−確認【重要】モード遷移が開始しました。 上記通りにならない場合は、CPU動作不可が考えられます。 TOP ブート仕様のCPUの場合、SP設定後200〜400msソフトタイマの処理を推奨と記述してありますが、何故でしょうか?(対象:ブート仕様CPU) ブート仕様のモニタ型デバッガはICEと違い、開始時にリセットスタート番地(0x800)に停止させておく事ができません。 H-debuggerの場合、DEFのスタート時/RstMon/ダウンロード終了時に、ターゲットに対して「Reset」発行後 「NMI」信号をアクティブにしモニタ起動させた後、PCレジスタを0x800値に書き換えて、あたかも0x800番地に停止して いるように見せかけています。 つまり、Reset解除後−>NMI発生させる時間まではターゲットCPUは走行します。 この時に内部I/O等の初期化が実行されてしまうわけです。 なぜ、Reset解除後NMI発生までに時間が掛かってしまう理由として、リセット信号をCPUに直接接続する場合は良いのですが、 リセットIC経由の接続をするユーザもいる為、リセット遅延時間200ms後にNMIを発生させています。 この様な理由によりデバッグ中は400msのソフトタイマを入れることを推奨しているわけです。 ただし、DEF(Ver5.70A)よりターゲット基板のRESET遅延が無い場合、CPU設定で遅延防止の不要設定をすれば【20us】の ソフトタイマになります。つまりRESET立ち上げから20us後にNMIを発生させます。(対象:ブート仕様CPU) TOP リセット回路ですが、遅延時間を200ms以下となっていますが、何故でしょうか?(対象:全CPU) H-debuggerは、リセット解除してから200ms後にモニタが存在しているか調査にしに行きます。 RESET制御の場合、上記のFAQにも記述してあるようにRST-IC経由の場合も考えられますし、 H-debuggerからのオープンドレイン出力で制御していますので、PULL-UP抵抗値によっては立ち上がりが訛る場合があります。 これらの理由により、200ms以下に抑えて下さい。と記述しています。 ただし、DEF(Ver5.70A)よりターゲット基板のRESET遅延が無い場合、CPU設定で遅延防止の不要設定をすれば【20us】の ソフトタイマになります。つまりRESET立ち上げから20us後にNMIを発生させます。(対象:ブート仕様CPU) TOP ルネサスCでinline_asm関数記述をしたところ、その関数事態にもコードが発生してしまいます。何故でしょうか?(対象:全CPU) 下記の例のよう記述しますと余分なコードも発生せず正しくCソース表示されます。 例) #pragma inline_asm(NOP4) static void NOP4(void) { NOP NOP NOP NOP } void main() { NOP4(); } <注意事項> @inline_asm関数の関数属性を必ずstaticにして下さい。 Ainline_asm関数の記述はモジュールの先頭で記述して下さい。又はインクルードファイルに纏めて下さい。 Bコンパイル時の出力指定は「*.src」にして下さい。 TOP H8Sシリーズで割り込みモード0でデバッグをしていますが、割り込み関数にブレークポイントを設定しましたが予定箇所で停止せず全く違う場所で停止しています。何故でしょうか?(対象:H8S/22xx,25xx,26xx) このシリーズでのPBC(PCブレークコントローラ)は、目的PC値で割り込みが発生してブレークする機能になっています。 割り込みモード0での割り込み関数内は通常ディセーブル状態になっていますので停止せずイネーブル状態になって初めて停止します。この性質により問い合わせの症状になってしまいます。 この症状の退避策は多重割り込み許可状態の割り込み関数記述をして下さい。 TOP ルネサスC(統合環境)でInline関数記述をしたところCソース表示が正しく表示できません。何故でしょうか? inline関数記述によるライン情報は、現状DEFのソース制御にとって矛盾した情報が出てきてしまう事による不具合です。 Inline関数のデバッグおよびデバッグ終了時は下記の方法で対応して下さい。 <Inline関数のデバッグ時> <main> #define DEBUG #include "inline.h" <inline.h> #ifdef DEBUG #define Inline static #else #define Inline static inline #endif Inline func() {....} この様にインライン関数をデバッグする時はstatic関数にしてデバッグします。 こうしますとモジュール単位での関数になりますので、Inline展開の関係としては同等になります。 <Inline関数のデバッグ終了時> // #define DEBUG この様にコメントにしたのちビルドしますと、インライン展開します。 この時にシンボルコンバータ「HCsymconv(Ver3.30A)」にオプションSW(-i)を追加して下さい。 この追加により矛盾したライン情報は削除されます。 ただし、DEF(Ver6.80B)より、SH-2シリーズ以外は、inline関数等の重複情報に対応しました。 TOP いまH8S/2134Fをターゲットとしてプログラムを作成していますが、DEFでハードウェアブレークを掛けるとブレークポイントより数行(数命令)ズレたところでストップします。最適化を外しますとそのズレは小さくなりますがやはり遅れます。何故でしょうか? H8S/21xxシリーズのブレーク方式は、「プリフェッチブレーク」です。 実行してからでは無く「プリフェッチ」した時点でブレーク割り込みが発生しますのでこの動作をします。詳細な注意事項は、HELPを御覧下さい。 TOP H8S/2258Fでデバッグを始めたところですが、初期化プログラムをステップ実行で確認していたところ「3sec内にブレーク/トレース割り込みが発生しませんでした。」とアラート表示され中断してしまいます。何が原因でしょうか? 初期化プログラムの実行中にプライオリティ7の他の割り込みが発生してしまい戻ってこれなくなってしまった現象と思われます。 割り込みモード2のCPUをデバッグする場合、下記の初期化方法を推奨します。 <初期化手順> 1)スタックポインタの設定 2)割り込みの発生する可能性のある要因のIPR値を「6」にする。(PCブレークは「7」のまま) 3)レジスタEXRの割り込み要求マスクレベルを「6」にする。(PCブレーク/トレ−ス割り込み以外はディセーブル) 4)割り込みモード2に設定する。 5)必要に応じて20〜400msのソフトタイマを入れる。 6)ユーザ側の初期化プログラムを記述する。(使用する割り込み要因のIPR値を6以下に設定) 7)初期化プログラムの終了したところでレジスタEXRの割り込み要求マスクレベルを「5以下」にする。(他の割り込みイネーブルにする) 8)メインプログラムの実行 以上です。 −−−−−(追記)−−−−− 5)必要に応じて20〜400msのソフトタイマを入れる。についての説明 DEF操作での「RstMon」を使用、又はターゲットリセット(ターゲット電源ONも含む)した場合、H-debuggerよりリセット出力後NMI割り込みを発生させモニタを実行しユーザプログラムを停止させた後、PC値をリセットベクター値に強制設定させ、あたかもリセット停止しているように見せかけています。 このモニタを実行させる前にCPU内部レジスタ値が変わる(ユーザ側の初期化プログラム)のを嫌う場合はソフトタイマを入れて下さい。 なお、RTOS(TRON等)を使用している場合は、OSの初期化中にNMIを発生させ中断させたのち、PC値をリセットベクタ値にさせ、再実行しますと誤動作する場合がありますので、この場合は必ずソフトタイマを入れ、NMIを発生させるまでOSの初期化に入らないようにして下さい。 ただし、DEF(Ver5.70A)よりターゲット基板のRESET遅延が無い場合、CPU設定で遅延防止の不要設定をすれば【20us】の ソフトタイマになります。つまりRESET立ち上げから20us後にNMIを発生させます。(対象:ブート仕様CPU) TOP H-debuggerは、取り説どうり使用していきますと、ROMベースでのデバッグ環境と思われますが間違いありませんか? もしそうだとすれば、フラッシュromの書き込み回数に制限されると思います。 新規の開発プログラムですと、デバッグ期間に多くの時間を費やすことになりますし、書き直しが何度も発生すると思いますが大丈夫でしょうか? ROMベースでのデバッグ環境はH-debuugerの特徴のひとつです。 確かにルネサスは100回と制限していますが、この制限の意味はフラッシュROMの特性上100回を超えて書き込んだROMは数年後に消える可能性があるという意味です。 弊社ではデバッグ用の基板と製品用の基板を分けてご使用する事を推奨しています。 現実弊社でもデバッグ用基板の書き込み回数が数千回(多分5〜6千回ぐらい)超えていますが問題なく書き込めています。 割り切ってデバッグ用基板を数枚程用意しておけば問題ないかと思いますがいかがでしょうか? TOP CPUはH8SシリーズですがJSR 命令部でステップ実行を行うとかなり先のコードへステップしてしまいます。 その間のコードは実行されているのですが、デバッグが行えません。 トレース実行でも同じ現象が起こります。また、JSR を BSR に変えても同じ現象が起こります。 今のところプログラムを実行して最初の JSR 命令でこのような現象がでています。 H8Sシリーズの場合、JSR/BSR命令の場合のステップ/トレース実行は、PBCを利用しています。 この現象は、割り込みモード2の「EXRレジ」が6以下になっていない現象です。 スタートアップで6以下にするか、「DI」ショートPBをONにしてからステップ/トレース実行をして下さい。 TOP ホストとして使用していましたPCを入れ換えることになり、新しいPCにDEFをインストールして起動しようとしましたところ、"EAccessViolation."というメッセージを表示するのみで起動しません。 "EAccessViolation."エラーのでる可能性として次の事が考えられます。 最新バージョン「例 Ver3.40等」で作成された環境ファイル「DEF.ENV」を旧バージョン「Ver3.10」にCopyして使用しますとこのエラーがでる可能性があります。 理由) CPUが増えているため管理テーブルが大きくなっています。「DEF.ENV」には、そのテーブルインデックスを記憶させていますので、旧バージョンでメモリエラーが発生する可能性があります。(DEF Ver3.50以上では対策済み) 対策) もし、この様な使用方法でしたら「DEF.ENV」を削除してから「DEF」を起動して下さい。デフォルト設定で起動します。 TOP DEFで構造体のメンバーやグローバル変数の値が表示されません。値を表示させたい変数または構造体にカーソルを合わせると"void label"と表示されます.(統合環境を使用しています。) 統合環境のコンパイル設定が、「*.src」設定にしていませんか? インラインアセンブラ記述が必要な場合この設定になります。 なお、ルネサスCの場合「*.src」設定にすると一度アセンブラソースファイルに落される為、シンボルは、全て「label」になります。 インラインアセンブラの必要な関数は、全て同モジュールにして、他モジュールのコンパイル設定を「*.OBJ」にして下さい。 そうしますとデバッグ情報が得る事が出来ます。 TOP CPU(H8S2238)にモニタを書き込みたいのですがうまくいきません。動作クロックは1.842MHzで,DEFの水晶発振子の設定を2MHzにしています. H8S/2238でのブート書き込み最低周波数は2MHzになっていますので、周波数を上げて下さい。 TOP H-debuggerを使用するにあたり注意事項がありましたら教えてください。 1)H8シリーズの場合200h〜7FFh番地、SHシリーズの場合800h〜FFFh番地を空けてください。 2)H8シリーズの場合800h番地にスタックポインタの設定命令を置いてください。 3)SHシリーズの場合1000h番地からプログラムスタートするようにしてください。 4)スタックポインタの設定後、約400msのソフトタイマーを置いてください。 5)その他については、CPU別の使用制限事項をご覧下さい。 ただし、DEF(Ver5.70A)よりターゲット基板のRESET遅延が無い場合、CPU設定で遅延防止の不要設定をすれば【20us】の ソフトタイマになります。つまりRESET立ち上げから20us後にNMIを発生させます。(対象:ブート仕様CPU) TOP DEFのオプション->CPU設定にある水晶発振子のクロック値は、正しい値を入れる必要がありますか? 必ず正しいクロック値を選択してください。 フラッシュROMの書込み時に、設定されたクロック値を基にソフトタイマを利用していますので、正しく設定されていない場合には、正常書込みが出来ません。 なお、設定したいクロック値がクロック値リストの中に無い場合には、近いクロックで設定したいクロック値より大きいものを選択してください。 TOP ブートモードでモニタープログラム転送したのですが、転送終了後の終了メッセージで[OK]をクリックしても同じメッセージが繰り返し表示されてしまう。 モニタプログラム転送終了後、H-debuggerはターゲットにリセット出力した後、ターゲットと通信して確認を行なっています。 その時、通信が確立しなかった場合に、このような現象になります。 原因として、ターゲットのリセット遅延時間が200msec以上、もしくは、NMIが接続されていないかプルアップされていないことによりNMI割込みが発生しない為と思われます。 TOP BP1,BP2 は H8S/26xx のみの機能 となっているようですが、これはハードウェアブレーク機能ですか? H8 300H (3664) を使用したいのですがハードウェアブレークは、かけられますか? Tinyの場合は、BP1のハードウェアブレークが可能です。 CPUのブレークコントローラのが1個のものに関しては、BP1のみでハードウェアブレークをかけます。 TOP 付属するターゲットボードのCPU(H8S/2612)以外のCPUを使用する場合、サンプルで使用されているH8S/2612用 IO定義ファイル "io261x.h"に相当するものは、自分で作るのですか? それともどこかにあるのですか? 「取り扱い説明書(導入編)」に書いてありますように、"C:\Program Files\Aitex\DEF\sample"フォルダ内に使用できるCPUのサンプルプログラムが収めてあります。 その中より、必要なIO定義ファイル "io****.h"をコピーしてお使いください。 TOP H8S/2612でシリアル2CHを使うのですがデバッカにシリアルを1CHとられてしまうと2CHのデバックができないと思うのですが どのようにすればいいのでしょう? H-debuggerは、デバッグ用にブートモードで使用するシリアルチャンネルを利用してデバッグを行ないます。 H8S/2612の場合でしたら、SCI_2を使用してデバッグを行ないますのでSCI_0とSCI_1の2チャンネルは、ユーザーで使用することが出来ます。 TOP H-debuggerで、アップロードというコマンドがあるので試してみたのですが、拡張子は.MOTでもファイル形式はSフォーマットではなくINTELHEXフォーマットになるのでしょうか? 拡張子を変えても書き込みは、インテル拡張フォーマット形式で書き込みます。 ただし、DEFバージョン5,10Aより、インテル/モトローラ形式が選択できるようになりました。 TOP ルネサスC又はGNUのアセンブラのソース表示デバッグは可能ですか? 可能です。 ただし、ルネサスCのみです。 GNUの場合は、ラインアドレス情報を得る方法がわかりません。 弊社はC言語でのインラインASMでの方法を取っています。 サンプルをご覧下さい。 TOP ローカル変数の内容を確認したいのですが、シンボルが出ません。 どのように確認すればいいのですか? ローカル変数の宣言に"static"を付けることにより可能となります。
ただし、ルネサスC(Ver4.00以上)とDEF(Ver3.00以上)の組み合わせでしたらローカル変数および構造体の参照が出来ます。 TOP 文字が大きすぎて行間が空かず、特に英小文字で下に突き出る文字(g、j、p、q、y)の下側が切れてしまっています。 「View窓」「ダンプ窓」について、フォントを小さくすることはできないのでしょうか? 画面プロパティの設定の詳細のディスプレイのフォントサイズが”大きいフォント”になっていませんか? ”小さいフォント”にして下さい。 TOP ファイルのダウンロードで”SYMファイルが見つかりませんでした”と表示されてしまうのですが、何故でしょうか? ファイルおよびディレクトリの名称に‘.’ピリオードを使用したり、ファイル名に、@?#の特殊記号を使用していませんか? 使用している場合には、取り除くか、違う文字を使用してください。 TOP 非常に大きい(長い)アセンブラソースだとデバッグ画面に全リストが表示されないのですが、どういう事でしょうか? またそれを解決する方法はなにかありますか、教えて下さい。 1ソースの表示制限は、最大9999行になっています。 CView画面の上部に"C"と"Asm"のラジオボタンがあります。 Cボタンだとソース表示になり、Asmボタンだと実際のメモリ上の逆Asm表示になり、この場合だと制限がなくなります。 ソースファイルが大きい場合は、モジュール分割をしてリンクする方法で出来ればお願いします。 TOP DEF でモニタ中にブレーク可能な行は青く表示されますが、青く表示されない(ブレークポイントが入らない)行を青くするにはどうしたら良いのでしょうか? 青くなっていない行は、オプティマイズが掛かり最適化されています。 ですから、デバック中はオプティマイズを外すか、割り切って使うかのどちらかになります。 TOP プログラム実行中にRAM値を確認することはやはりできないでしょうか? オンザフライ機能で可能です。 ただし、原理はリモートデバッグですので、プログラム実行中に「NMI」割り込みを掛け処理終了後に「RTE」させています。 処理時間は、CPUのパワーによって左右されますが、だいたい1バイトあたり「0.n」msの処理時間です。 「H-debugger」から出力している「NMI」信号を計測すれば、わかります。 TOP 配列や構造体のシンボリックデバッグが出来ないと記述されてましたが、配列や構造体のデータの格納や読み出しがちゃんと行われているかどのように確認すればいいのですか? 配列と構造体の先頭については、シンボルデバッグができます。 要素指定に関しては、今後のテーマとして考えていきたいとは思っています。 また、"PUTCH()"を利用して、内容の確認をすることも出来ます。 ただし、ルネサスC(Ver4.00以上)とDEF(Ver3.00以上)の組み合わせでしたら ローカル変数および配列[6次元]および構造体の参照が出来ます。 TOP 日立のデータシートを見るとFLASH ROM書込み回数が100回までとなってますが、どのような時にFLASH ROMに書き込んでいるのですか? ステップ実行・ブレークポイント設定する度に書き換えてるのですか? モニター・ユーザープログラムダウンロード時にFLASH ROMに書き込みます CPU内蔵のブレークコントローラを使用してステップ実行・ブレークポイント設定を実現していますので、FLASH ROMに書き込んでいません。 TOP モニター付で動作していたターゲットプログラムが、モニター無しでダウンロード・実行しようとしたら動作しないのですが、何が原因と考えられますか? 以下の、原因が考えられます。
H-debuggerとH8/3672との結線はE10T_x端子を使用する事が取説に書かれていますが、オンボード書込みプログラミング時もこの結線で良いのでしょうか? また、ハードウェアマニュアルにはオンボード書込み時にSCIを使用する旨が記述されていますので、オンボード書込み時はやはり切り替えなければいけないのでしょうか? E10T仕様(日立オリジナル I/F)に合わせてありますので、ブートモードの移行も「E10T_x」の信号を使用して自動的に切り替えます。 "Tiny"に関しては、標準ブートモードを使用していません。 TOP ターゲットのFWE端子はプルアップ抵抗4.7Kオームを介してディップSWに接続してあります。 H-debugger側ではスリーステート出力でターゲット側ではFWEをプルダウン抵抗10Kオームで接続しなさいと記述されてましたが、このターゲット環境ではどのような接続をしたらいいのでしょうか? FWE信号は、通常「LOW」で、フラッシュROMに書き込む場合「HIGH」にします。 ターゲット側で「HIGH」が確保できればダイレクトでも構いません。 TOP H-debuggerのRESET出力(オープンコレクタ)は、ターゲットのRESETに接続しないとまずいですか? H-debuggerのリセットSWを押してから、ターゲットのリセットSWにてリセットすれば動作するのですか? RESET信号は、H-debuggerで色々とコントロールしていますので接続が必要です。 TOP モニタプログラムをダウンロードするとき、ターゲットをブートモードにする(基板側のジャンパ等の設定)と記述されてますが、どういったことでしょうか? また、H-debuggerのほうでFWE端子を操作してくれるのですか? CPUにより違いがありますが、ブートモードにする為に、MDx等のモード入力の切り換えが必要な物がありますので、その部分に関して基板側の設定が必要となります。 FWEは、H-debuggerよりコントロールします。 TOP ■デバッガ用ソフトウェアパーツTOP
C言語ではソースブレークという手法を用いているということですが、アセンブラ(日立かGNU)で開発してデバッグする時、ブレークはかけられますか? この場合は、ハードブレークのみ使用となります。 TOP デバッガ用ソフトウェアパーツのソースブレーク・標準出力―[PUTCH]のヘッダファイルはどこにありますか? 御購入CDの「\sample」下に、GNU/gcc・Hew1.2・Hew2.0・Hew3.0・Him用のヘッダファイルと使用例サンプルソースがあります。 TOP デバッガ用ソフトウェアパーツのソースブレーク・標準出力―[PUTCH]を使用する場合、日立のコンパイラの設定は何か変わるのですか? 変更はありません。 TOP PUTCHはローカル配列を表示できますか? PUTCHは、1文字表示パーツですのでご自分でprintf関数を作成すれば表示できます。 TOP |