PICのWWDT

久しぶりに技術的な書き込みです。

現在　私が主力で使っているＰＩＣには、色々と新機能が載ってます。
演算機能付きのADC2なんかは　かなり目を惹く存在ですが、
ウオッチドッグタイマーも拡張されていまして、WWDTという名称になっています。

頭に増えた「W」は、Windowの略。
OSのWindowsとは全く関係ございません。
ウオッチドッグタイマーのリセットコマンドである「CLRWDT」命令を使うタイミングに対し、
枠が設定されたという意味なのです。

これ、私も最初は意味がチンプンカンプンだったのですが、
メーカーが公開しているTB3123という説明書で意味が理解できました。
簡単に言ってしまえば、「CLRWDT」命令の発行は、遅すぎてもダメ、早すぎてもダメ、
という話なのでした。

遅すぎるダメというのは、従来のウオッチドッグタイマーと同様の話。
ウオッチドッグタイマー設定時間よりも遅れちゃうと、
システムリセットが　かかってしまうわけ。

問題はその逆、早すぎる場合。
その時間の　しきい値は、設定で変更可能です。
設定はパーセント単位になっております。
この設定を100パーセントに設定すると、従来のウオッチドッグタイマーと同様、
早すぎＮＧは無くなる、という風にメーカーは申しております。

と・こ・ろ・が、どうやらそうとも言えない感じなのです。

100パーセントに設定した場合、ハード的に早すぎ検出機能が死ぬわけではなく、
しきい値の値を変更しているだけの模様。
すると、メインクロックが高速の場合、早すぎ検出が作動してしまうケースが有るみたい。


実はまもなく納品する製品のファームウェアで、従来はクロック1MHzで動かしていたものを、
将来拡張の為にクロックを12MHzに変更したら、挙動がおかしくなった事案が出ました。

調べてみると、ウオッチドッグタイマーによるリセットが発生していたのでした。
クロックを上げた為にタイムオーバーが発生するなんて、おかしな話。
どうやらこのリセット、早すぎＮＧで起きてるようなのです。

早すぎＮＧ検出は不要なので、ウィンドウの設定値を100%にしておりますが、
それでも起きてしまいます。

ウオッチドッグタイマーはLFINTOSCの31KHzで駆動していますので、
メインクロック12MHzで数行のコマンドだと、クロック同期タイミングの関係で、
おかしな状況になってるんじゃないかと推測中。

2019/3/19　追記
追調査の結果、WWDTはシロでした。
原因はメインクロックが10MHzを超えるあたりから、SPIの通信にエラーが増えることでした。
エラーが起きると想定外の取得値が入ってくるため、その後の処理ルーチンで
すごく時間がかかってしまい、WDTがタイムアウトしちゃったようです。
メインクロック1MHzくらいだとほぼエラーは皆無なので、
なぜメインクロックが上がるとエラーが増えるのかは、また別な調査が必要ですね。