RL78/G14にてデバッグしてます。
INTP6 両エッジにて割り込みを発生させるために、PIF6 = 0U; PMK6 = 0U; するとリセットがかかり、2回目は正常に割り込みスタートできます。
リセット要因を調べたいのですが、どのタイミングでRESFを参照すればよいのでしょうか?
また、リセットの要因は何が考えられるでしょうか?
宜しくお願い致します。
チョコです。
>PIF6 = 0U; PMK6 = 0U; するとリセットがかかり
それだけでリセットがかかったという話は聞いたことがありません。
INTP6の割り込みベクタはきちんと設定されていますでしょうか。
>どのタイミングでRESFを参照すればよいのでしょうか
どこでも必要なところで参照して構いません。通常は、main関数の先頭でいいかと思います。
>リセットの要因は何が考えられるでしょうか?
リセット要因はハードウェア マニュアルの「24.2 リセット要因を確認するレジスタ」の
ところに書かれた5つの要因とそこに現れないPOC+RESET端子によるリセットがあります。
意図しないリセットでは、WDTでのリセットかRAMパリティエラーによるリセットがよく
話題になっています。
回答ありがとうございます。
RESFを確認しましたが0で何もフラグが立ってませんでした。
電源も3.3Vで安定してますし、RESETは外部プルアップでHIGHにつってます。
割り込みベクタは0x4AにINTP6割り込み処理関数のアドレスが設定されてます。
電源投入1回目にPIF6 = 0U; PMK6 = 0U;するとリセットされ
2回目にPIF6 = 0U; PMK6 = 0U;してもリセットかからず動作します。
原因を調べる方法はないでしょうか?宜しくお願い致します。
INTP6 を 3.3V に固定してもリセットが掛かりますか?
>RESETは外部プルアップでHIGHにつってます。
LVDは動作許可にしていますか。
安定な立ち上がりを考えると、LVDをリセット・モードで使って、
動作クロックを満足する電源電圧までリセットがかかるようにして
ください。
(マニュアルの「25.1 パワーオン・リセット回路の機能」の最初の方に
「ただし,34.4または35.4 AC特性に示す動作電圧範囲まで,電圧検出
回路か外部リセットでリセット状態を保ってください。」と記載されて
います。)
fujitaさん
簡易的に試してみました。INTP6の配線を変更し3.3Vに外部プルアップのみにするとリセットかかりませんでした。でも意味がよくわかりません。
使い方として、INTP6は外部のクロックパルスを接続し、両エッジにてカウントしています。電源投入時点でクロックパルスも発生し、INTP6スタート時点ではすでにHIGH,LOW繰り返している状況です。スタートアップにてINTP6設定し、メイン処理の中でINTP6スタートしてました。INTP6スタート前にCLKパルススタートしてはいけないのでしょうか?
チョコさん
LVDはリセットモードで3Vくらいに設定してます。ちなみに、LVDを使っていると
>「ただし,34.4または35.4 AC特性に示す動作電圧範囲まで,電圧検出
>回路か外部リセットでリセット状態を保ってください。」と記載されて
>います。)
これは内部でしてくれてるんですよね?
>電源投入時点でクロックパルスも発生し、
RL78/G14の電源電圧よりも入力電圧が高くなってはいないでしょうか?
間違ってました。クロックパルス生成用の電源もタイマRJのクロック出力を使用しているため、電源投入後でした。INTP6スタートよりも前にクロックパルスは発生しています。
よって、立ち上げ時においても電源電圧よりは高くなってないです。
ちなみに、電源電圧より高くなった場合はRL78/G14が壊れて、このような動作になる可能性もあるのでしょうか?
追加の情報です。
E1接続してエミュレートの場合、電源断状態からE1接続後初回実行時はINTP6スタート時にリセット動作して、次のINTP6スタートにて正常に動作します。
そのまま一旦エミュレートにて(電源は入ったまま)リセットし、2回目実行時はINTP6スタート時にリセット動作しません。
電源立ち上げ後初回実行時にだけ起こるようです。何か手がかりないでしょうか?
>電源電圧より高くなった場合はRL78/G14が壊れて、このような動作になる可能性もあるのでしょうか?
可能性は考えられます。電源電圧よりも高い電圧や負の電圧が印加された場合には、
通常の回路ではなく、寄生回路の影響で、変な動作になる可能性があります。
(もちろん、最悪の場合には破壊に至ることもあります。)
>INTP6スタート時にリセット動作して、
確実にINTP6スタート時でしょうか?ステップ実行でも同じでしょうか?
また、そこの部分のコードはどうなっていますでしょうか。
何度もすいません。
間違いがありました。INTP6スタート時ではなく、もう少し先のINTP6割り込み関数内にてリセットかかっていました。
これまで、動作確認に空きポートをテスト出力として使用し、テスト出力するコードの位置を変えながら、オシロで波形を確認しておりました。
オシロのレンジが広くそのテスト出力を取りこぼしておりました。
INTP6割り込み関数処理はクロックのHIGH/LOWフラグ判定によりHIGH/LOW幅測定用タイマをストップ/スタートし、HIGHの場合はクロック数をカウントアップし、最後にクロックが一定時間入力されないタイマをストップ&再スタートしています。
最後のストップ&再スタートのところにブレークポイントを設定しても、2回目のリセット後にはブレークポイントまで走りますので、同時にP130(外部ICのリセットに使用)の波形をオシロで確認しています。毎回同じ位置でリセットするわけではないようです。1コードずれることがあります。ステップ実行ではリセットかかりません。
タイマが関係しているのでしょうか?
その部分のソースは下記です。
TT0 |= _0004_TAU_CH2_STOP_TRG_ON;
TMMK02 = 1U; /* disable INTTM02 interrupt */
TMIF02 = 0U; /* clear INTTM02 interrupt flag */
TMMK02 = 0U; /* enable INTTM02 interrupt */
TS0 |= _0004_TAU_CH2_START_TRG_ON;
INTP6割り込み関数の内容を、後ろ半分をコメントアウトしてリセットが掛かるかテスト、相変わらずリセットが掛かるようであれば残り前半部分の後ろ後半もコメントアウトしてテスト、リセットが掛からないのであればコメントアウトした部分の前半をコメントアウトを解除してテスト、みたいに繰り返していけば問題箇所の絞込みができるのでは。
調査方法はfujita nozomuさんの方法でいいとしても、RESFが0というのは
納得がいきません。起動後に2度読み出しているのではないでしょうか。この
レジスタは1度読み出すとクリアされるので、2度目では0しか読めません。
マニュアルにもRESFの値を一度RAMに読み出しておいて、RAMの値を使って
判断するように記載されています。この点は問題ないか確認してください。
また、タイマの起動処理は全く問題ありません。TAU0ENが1になっていれば、
これでTM02が起動するだけです。
リセットかからなくなりました。INTP6割り込み関数にてクロックパルスのカウントをしておりますが、このカウンタ変数が初期化されておらず、初期化することででなくなりました。
DTCも使っておりまして、DTCにて転送する転送先/転送元アドレスをセクションを代えて固定しております。その続きにカウンタ変数も配置されていて初期化されていない状態でした。RAMはスタートアップにて全てクリアされているものと思っておりました。セクション変えると自分でクリアしないといけないんですね。
でも、カウンタが初期化されずにカウントアップしてもオーバーフロウするだけではないんでしょうか?リセットする意味がよくわからないです。
また、RESFはやっぱり1度しか読んではないです。それでも0なんです。そのため再度、電源やクロック信号電圧など確認しましたが問題なく、プログラムにて絞込みをしたところ上記に気付けました。
セクションの配置やRAMの配置など勉強が必要だと実感しました。何度もありがとうございました。
>リセットかからなくなりました。
何はともあれ、よかったですね。
>このカウンタ変数が初期化されておらず、初期化することででなくなりました。
これはRAMパリティ・エラーのパターンなんですが。
もしかして、コード生成を使用していませんか。
端子割り当ての確定以外何の変更もなしで、コード生成してみたところ、クロック発生回路
のリセット要因確認がディフォルトではチェックされているので、初期化処理で、RESFが
読み出されるようです。
具体的には、起動時に実行される"R_Systeminit"の中でR_CGC_Get_ResetSource()
関数が呼ばれています。この関数はr_cg_cgc_user.cの中に存在し、RESFレジスタを
読み出して、変数reset_flagに格納していました。
これが悪さをして、main関数がスタートした時点ではRESFが0になっていたのではない
でしょうか。
これなら、今回の動作の説明が付きます。