RA6M5 CPUの開発で WDT制御を試みています。ルネサス様のWDTサンプルプログラム（wdt_ek_ra6m5_ep）を動作させると意図したカウント周期でカウントが行われてリセット条件に到達すれば当然リセットが発生するのですが、当方で作成したプログラムでは、リセット条件に到達するとリセットは発生するものの、なぜだかカウント周期がサンプルプログラムと比較して異常に遅いです。※試しに WDTデバイスのレジスタ（WDTCRなど）や、カウントに関わる クロック発生回路のレジスタ（SCKDIVCRなど）も サンプルプログラムと当方プログラムで全く同じにしてみましたが 状況は変わりませんでした。※ちなみに、使用ボードのクロック速度（PCLKB）は50MHzです）※"異常に遅い"とは PCLKB=50MHzのとき、CPU仕様としてWDTは リセットまでに最大2.6秒ほどまで待てるかと思いますが、 （ 0x3FFF ÷ (50MHz / 8192) ≒ 2.6秒） 現状当方プログラムは200秒以上経ってからリセットがかかるように なっていて、単純に考えてカウント周期が100倍？以上になっており、 クロック設定が明らかにおかしい様子です。当方プログラムは WDT以外にも FreeRTOS+TCPや FreeRTOS+FATなども実装しており、誰かが悪さしているのかもしれませんが現時点では見当もついていません。そこでWDTを使用する際に、WDTやクロック発生回路のレジスタ機能以外に考慮しなくてはならない要素など、何かご存じのことがあればどなたかご教授いただけないでしょうか。〇環境・e2studio：v2021-04・FSP：V3.0.0以上、よろしくお願いいたします。
ososさん、こんにちは。NoMaYと申します。すみません、RAマイコンは使ったことはないですが、RXマイコンにもあるオプション設定メモリの設定項目にWDTの設定も追加されていて、そちらの設定が優先される設定になっているということはないでしょうか？
NoMaY様ご返答ありがとうございます。RA(RA6M5)では、ユーザが任意のタイミングでWDTを開始できるモード（レジスタスタートモード）に"していなければ"、ご指摘通り、オプション設定メモリの設定値が使用され、プログラムで設定したWDTレジスタ通りにはWDTが動かないようです。ただ、改めて確認しましたが、やはり設定としてレジスタスタートモードが選択されており、オプション設定メモリの設定が影響されているようにも見えない様子でした。（念のため試しに、オプション設定メモリの設定値を、WDTレジスタの設定と同じにしてみましたが動作は変わりませんでした）
ososさん、こんにちは。NoMaYです。そうでしたか。他に、マニュアルを見て気になる表現が『セキュアデベロッパーのみがオートスタートモードまたはレジスタスタートモードを選択可能』ですね。(すみません、使ったことがなく私には良く分からないですが、でも気になりました。)そこも大丈夫ということになると、私ですと、一般論的ですけれど、以下を調べ始めるかな、と思います。(確認済みでしたら、すみませんけれど、でも、期待通りにダウンカウントして、アンダーフローして、それでも200秒後にリセットが発生するとしたら、マイコンの動作的/仕様的に問題あり、っぽい気もします。)● 本当に50MHzのPCLKBがWDTに供給されているか？マニュアルを見ると、カウンタがカウントダウンしていく様子は読み出せるようですので、一時的に、割り込み禁止(クリティカルセクションに入れるだけでなく完全に割り込み禁止)にして、NOPを100個～1万個ほど実行させてみて、どんな風にカウントダウンしていくか調べるちなみに、NOP 9万個までの#defineなら作ったことがあります。(行番号はいずれズレるかも知れません。)github.com/NoMaY-jp/FreeRTOS_examples_for_Renesas_R_CPUs/blob/main/13_RTOSDemo/RL78_RL78G14_FPB_GCC_e2studio/src/platform.h#L161
ososさん、こんにちは。NoMaYです。あと、気になるといえば、デバッガの設定で何かあったりしないだろうか？ですね。素直に2秒毎にクリアしないといけないなら、それではデバッグ出来ないですよね？(なぜならブレーク中にリセットが発生してしまいますので。と、ふと頭に思い浮かんだのです。)
ososさん、こんにちは。NoMaYです。もうひとつ気になったのですが、すみません、ちなみに、WDTCRの設定値を変更して(例えば、タイムアウト期間を変えたり、クロック分周比を変えたり)して、リセットが掛かるまでの時間は変わるのでしょうか？
ososさん、こんにちは。NoMaYです。ずっと考えていた訳ではもちろんありませんが、RTOS特有で間違えることがあるとしたら、自分では最初のリフレッシュの前にWDTCRを初期化したつもりでも、それぞれのタスクの開始順序が想定通りではなくて、既に他タスクでリフレッシュが行われた後だった、ということもあるかも知れない、と思い浮かびました。これは、チェック用のフラグ変数を用意して、リフレッシュと同時にそちらにもフラグを立てて、WDTCRの初期化処理のところでそのフラグを見てみることで分かるかな、とも思いました。
NoMaY様様々な観点からのご指摘ありがとうございます。1.クロック設定レジスタしか確認していなかったですので、もう少し PCLKBを怪しんでクロック周りの確認をしてみようと思います。 参考のコードまで上げていただきありがとうございます2.デバッガを付けた状態/外した状態では同じ状況となっています。 ルネサス様サンプルもそうでしたが、デバッガでCPUブレーク中は WDTのカウンタが停止しているようなので、デバッガによる影響は あまり無いのかな？と感じております。（一応、RA CPUはデバッグに関連して DBGSTOPCRレジスタなるものがあり、 WDTに影響与える設定があることだけは私も把握しています。 ただ弄ってみたもののリセット速度に影響を感じられなかったです）3.WDTCRの設定のうち、RPESシンボルやCKSシンボルを変えてみたところ リセットまでの時間が変わりました。 どうやら分周機能やコンペア機能は（正しく1/4分周などが為されているかは 別として）生きている様子です。4.デバッグ用に、WDTをリフレッシュするタスクのみを動かすように 変えてみましたが、問題が起きてしまいました。色々ご指摘いただいて調査した感じ、最初のご指摘であり、まだ調べ切れていない「本当に50MHzのPCLKBがWDTに供給されているか」という点が問題な気がしてきましたので引き続きクロック周りを調べてみようと思います。
問題解決いたしました。先週 NoMaY様にご指摘いただいた供給クロック設定について見直しましたが、異常は見つけられませんでした。途方に暮れていたのですが、ふと「カウンタ速度が遅いのではなく、カウンタが高速周期的に止まっているのではないか」ということに思いつきました。そこでWDTやクロック周り以外を確認した結果、作成プログラムが使用している外部ライブラリが省電力のため（？）、高速周期で WFI命令を実行して CPUを停止していました。そしてそのライブラリ内の WFI命令を取りやめたところ、期待した時間でリセットできるようになりました。懸念事項を一つずつ確認していった結果、ようやく辿り着くことができました多くのご指摘くださったNoMaY様、本当にありがとうございました。
ososさん、こんにちは。NoMaYです。解決して良かったです。その一方で、今回の件で頭に浮かんできたことを経て、私には、ひとつ新たな知見の習得になりましたね。(1) ウォッチドッグタイマのオプション的機能として低消費電力モード中に停止させる機能は良くあるものな気がする(2) それはそれで良いけれど実はいとも簡単に命令一発で低消費電力モードに遷移出来る(CortexならWFI、RXならWAIT、等)(3) 運悪く割り込み禁止中に暴走して命令列の隙間へ飛んでその後にたまたまそんな命令を実行したらデッドロックしそう(4) そんな気がしてRX651/65Nのハードウェアマニュアルを見直したらWAIT命令では自動的に割り込み許可になるのでした(5) 他方Cortexでは？と思いマニュアルを探して読んでみたのですがちょっと良く分からなかったです、、、ただ、ループで頻繁にWFIを使うのはArmが推奨しているようでした(以下の引用での赤文字は私によるもの)ARMv7-M Architecture Reference Manualdeveloper.arm.com/documentation/ddi0403/ee「B1.5.19 Wait For Interrupt略Note● Arm recommends that software always uses the WFI instruction in a loop, and does not assume that the processor either enters low-power state, or remains in low-power state, after any particular execution of the WFI instruction. This is because:－ The architecture defines WFI as a NOP-compatible hint, that the processor can ignore.－ A processor can exit the low-power state spuriously, or because of debug, or for some IMPLEMENTATION-DEFINED reason.● Some implementations of Wait For Interrupt drain down any pending memory activity before suspending execution. This increases the power saving, by increasing the area over which clocks can be stopped. The Arm architecture does not require this operation, and software must not rely on Wait For Interrupt operating in this way.」思うに、そう出来るなら、低消費電力モード中にも停止させない、という設定の方が良いのかも知れないです。
NoMaY様FSPのデフォルトでは CPU停止時に WDTカウンタを停止する設定が選択されていますが、仰る通り Armv7-Mの仕様的には WFI命令を多用しても不思議でない感じですので WDTを使用する際は意識的に CPU停止時にも WDTカウンタは停止させない設定にした方が無難のようですね。（もちろん FSP使用時に限った話ではありませんし、すべて自作コードで 開発する場合は自由にすればよいのでしょうが）大変勉強になりました