E1エミュレータとの通信が途切れる

Jin様

>仮に、無効にできるのであれば、WDTは無効状態でブレーク実行されてみてはいかがでしょうか？

WDTの割り込みを禁止してみたのですが、やはり停止に失敗してしまいます。

＞origamiさん

皆さんが仰る通り、スタック不足の様な気がします。。。

一案ですが、OKだった初期の頃を例えば1年前とすると、6ヶ月前の状態に戻すとどうなりますか？

もしOKなら、半年間で追加したプログラムのいずれかに原因がある、と思います。

最終的には、少しずつプログラムを削り、切り分けするしかないかもしれません。

勿論、kijoさん仰せの通り、CallWalkerでの確認の方が先決です。(簡単ですから...)

CallWalkerでスタックを確認してみました。

左側に表示されているMAX以外の数値を加算していったところ、350になりました。

単位がByteならスタックの容量(64Byte)をはるかに越えてますよね・・・

origamiさん

＞左側に表示されているMAX以外の数値を加算していったところ、350になりました。

すみません、勘が悪くて何をされたのか察しがつきませんが、重要なのは、左上の(Max:xxxx)です。

このサイズ(単位はバイト)と、

>現在のRAMは168Byteまで使用しています

を加算してRAM容量を超えていたら、その時点でNGです。

※CallWalker-Viewメニューの、RequiredとUsedで算出されるサイズが異なります。

スタックはそのファンクションが終了すれば解放されます。私の場合は、R8CやSHですが、多重割り込みを無くして割り込み処理をなるべく小さくしているので、割り込み専用のスタックエリアはなかったはずなので、mainと最大の割り込み処理を足した分でサイズは十分になります。通常はmain(yyy)のサイズがそのままxxx.cal(MAX:yyy)に反映します。

関数のポインタ呼び出しや多重割り込みや再帰呼び出しを使っているときは要注意です。込み入った話になるのでここでは触れない方が良さそうです。C言語で階層化設計されているのでしょうから、最適化をかけてしまってはいかがでしょうか？ローカル変数がメモリー上に無かったり、処理が無くてブレークポイントが設定できないなどデバックは大変になりますが、なんとかなると思います。思惑が外れてブレークポイントが設定できない場合はバクの可能性大です。

ビシ様

不出来な質問者で申し訳ありません・・・

スタックはMax56になっています。

現在のRAM使用量が168Byteなのでスタックと加算して224Byteになります。

RAM容量の256Byteを超えていないのでNGではないようです。

スタック見積もりツールは再帰呼び出しがあると正しくスタック使用量を見積もれないようですが該当はしないでしょうか?

int tarai(int x, int y, int z)
{
    return (x <= y) ? y : tarai(tarai(x - 1, y, z), tarai(y - 1, z, x), tarai(z - 1, x, y));
}

void main(void)
{
    tarai(12, 6, 0);
}

チョコです。

グローバル変数領域とスタック領域を足して、256Byteを超えるかで判断されて

いるようですが、それだけでは問題があります。スタックは、スタートアップ・

ルーチンで指定している領域しか確保されていないので、領域の配置によっては

おかしくなります。とりあえず、スタートアップ・ルーチンのスタック領域の

サイズを大きくしてみてはどうでしょう。（とりあえず、16Byte増やして、

0x50（80Byte）辺りにしてはいかがでしょう。

チョコ様

>とりあえず、スタートアップ・ルーチンのスタック領域のサイズを大きくしてみてはどうでしょう。（とりあえず、16Byte増やして、0x50（80Byte）辺りにしてはいかがでしょう。

試してみたところ、停止できるようになりました。ありがとうございます。

ただ、停止後に実行しようとすると、失敗する時があります。

(CPUリセット後スタートをすると失敗しない)

チョコです。

> 試してみたところ、停止できるようになりました。

とりあえずは、おめでとうございます。

> ただ、停止後に実行しようとすると、失敗する時があります。

デバッガがスタックを使用したために、おかしくなっている可能性があります。

（最初の頃に書いたように、デバッガが数Byteスタックを使うのでその分の影響）

今のところは、もう少しスタック領域を広げてみるしか思いつきません。