E1エミュレータを使ってRL78/G10をオンチップデバッグ中にプログラム実行を停止するとCPUとの通信が切れてしまいます。
この状態が頻発していて、まともに止まるのは数えるほどしかありません。
エミュレータとCPUは添付した画像の通りにしています。
配線に問題があるのか、それとも他に問題があるのか、教えていただけませんか？
CPU : R5F10Y16ASP
開発環境 : CS+ [CC]
エミュレータ : E1
origamiさん
プログラムが暴走していると、origamiさんのように強制ブレークしても戻ってこないことがあります。
ちなみに、ブレークポイントを設定した場合に正常にブレークできます？
Kirin様
浅学で申し訳ないのですがRL78/G10シリーズはブレークポイントを設定出来なかったと思うのですが、何か方法があるのですか？
ハードウェアブレークポイントを2箇所まで設定できますよ。
回答ありがとうございます。
週明けまでデバッグできる予定がないので、月曜にハードウェアブレイクポイントを試してみたいと思います。
チョコです。
RL78/G10でのハードウェアブレークポイントの張り方は他のデバイスのソフトウェアブレークポイントと
同じようにできます。ただ、2ポイントだけなので、3ポイント目を設定しようとしてすぐに叱られます。
表示メニューからイベントを表示してブレークポイントを確認できるようにしたほうがいいと思います。
あけましておめでとうございます。origamiです。
ハードウェアブレークを設定したところ、プログラムが停止しました。
ですがメニューバーの「停止」を実行すると失敗してしまいます。
やはりこれはプログラムが暴走しているのでしょうか？
たぶん、そーゆーことだと思います。
プログラムの暴走の原因として考えられるのは何ですか？
クロックの操作に誤りでもあるのかな・・・
スタックのサイズは大丈夫でしょうか？
E1が数バイト使用するので，スタックに余裕がないと停止できなくなる
可能性があります。
標準では，スタートアップ・ルーチン（r_vg_cstart.asm）の中で0x40に
設定されているはずです。
暴走して，スタックが深くなりすぎて，停止できない可能性があります。
割り込みの確認をしてみてください。（特に，WDTの割り込み）
>クロックの操作に誤りでもあるのかな・・・
少なくとも，ブレークポイントまではちゃんと動作しているのであれば，
その可能性は低いと思います。
上でコメントしましたが，まずはスタックを確認することをおすすめします。
（割り込みについては，ベクター・テーブルがきちんと設定できていないと，
暴走します。）
横から失礼。
ハード的要因はOKでしょうか？
電源、リセット回路・・・・等
私も当初、E1と上手く接続できませんでしたが、私の場合、リセット信号をプルアップしたら解消した経験があります。
マイコン側のリセット回路を接続していないのが、気になります。
PS:WDTは如何？
チョコ様
CPUのROMが2KBあるのですが、そのうち97.56%まで使用しています。
この状態だとスタックを確保できていないという事でしょうか？
割り込みのベクタテーブル設定は下記のように行っています。
#include "iodefine.h"
#pragma interrupt Excep_INTP0(vect = INTP0)
#pragma interrupt Excep_INTTM00(vect = INTTM00)
#pragma interrupt Excep_INTTM01(vect = INTTM01)
#pragma interrupt Excep_INTAD(vect = INTAD)
#pragma interrupt WDT_reset(vect = INTWDTI)
Jin様
リセット信号をプルアップしてみましたが上手くいきませんでした。
リセット回路については、その回路自体が無いので接続していません。
P.S:WDTのどの部分を調べたらよいでしょうか？浅学で申し訳ありません。
横槍失礼します。
スタックはROMではなく、RAMです。
また、ROM使用率がもっと少ない頃は、E1とは常に正常通信していたのでしょうか？
Yesなら、main()をほぼ空にすれば正常にブレークするのではないでしょうか？
ビシ様
現在のRAMは168Byteまで使用しています。(CPU:R5F10Y16ASP)
ROM使用率が少ない初期の頃は停止できていました。
main()はあまり使用していません。ほぼ割り込みで処理しています。
>現在のRAMは168Byteまで使用しています
RAMは256Byteあるので、スタック（64Btye）を含めてもオーバはしていないと
考えられますが、スタックそのものがオーバしている可能性があります。
メモリ・ウィンドゥでどの程度消費されているか確認するのがいいでしょう。
>ROM使用率が少ない初期の頃は停止できていました
プログラムが大きくなると、変数も増加していきます。Cのプログラムで暴走
するのは、スタックがあふれるか、ベクタを定義していない割り込みが発生
している可能性が高いと考えられます。
通常、ローカル変数はスタック領域に確保されるので、これも注意です。
R５F10Y16は割り込みのソースは少ないので、残りのすべての割り込みに
ダミーのベクタを設定して、ベクタのとび先には、空の割り込み関数を置いて
みるのも方法かもしれません。
中途半端でごめんなさい。
先ずは、WDTを有効にしているか、否かですが、
仮に、無効にできるのであれば、WDTは無効状態でブレーク実行されてみてはいかがでしょうか？
Jinです。
＞ROM使用率が少ない初期の頃は停止できていました。
と、言う事は、WDTは関係なさそうですね・・・・・
チョコさんの書き込みに補足です。
私はCallWalkerを使ってます。
①CS+のビルド・ツールのプロパティのリンクオプションタブのその他のスタック情報ファイルを出力するをはい。
②RenesasElectronicsCS+のユーティリティーのCallWalkerを起動。
③CallWalkerのFileのImportStackFileでスタック情報ファイル(プロジェクトディレクトリ内のDefaultBuild内のxxx.sni)を読み込む。
モダンなプログラマはローカル変数をたくさん使うのでROM使用率97.56%はかなりきわどくRAMもきっちりと検証しないとかなり危険だと私も思います。ヒープは使っていないんですよね。
>R５F10Y16は割り込みのソースは少ないので、残りのすべての割り込みにダミーのベクタを設定して、ベクタのとび先には、空の割り込み関数を置いてみるのも方法かもしれません。
上記を試したころ、1/2の確率で停止できるようになりました。
しかし、停止してからプログラムを再開するとプログラムが止まってしまいます。