ウォッチドッグ・タイマ

ウォッチドッグ・タイマのカウント・クロックは、発振子のクロックがそのまま入るのでしょうか？

いいえ、発振子のクロックそのままではありません。
ウォッチドッグ・タイマの動作に関する内容は各デバイスのUMをご参照ください。

解説
ウォッチドッグ・タイマのカウント・クロックとしては通常はメイン・システム・クロック(fx)を分周したものが使用されます。

たとえば、
　uPD780034Aサブシリーズでは fx/256
　uPD784216Aサブシリーズでは fx/128、またはサブシステム・クロック
　78K0/Kx1では X1発振クロックを 1/16に分周したものか内蔵発振器の 1/4分周
がカウント・クロックとして使用されます。

CPUの暴走対策としてウォッチドッグ・タイマを使用します。
プログラムの簡略化のため、 定期的にかかるタイマ割り込みの中でウォッチドッグ・タイマのクリアを行っていますが、 問題はありますか？

タイマ割り込みの中でウォッチドッグ・タイマをクリアする方法はお勧めできません。
この方式では、メイン・ルーチンが暴走してもタイマ割り込みが受け付けられれば、 ウォッチドッグ・タイマはクリアされてしまい、暴走を検出できません。

より厳密な暴走検出を行うには、一定時間内に必ず処理しないといけない部分に個別にフラグを準備しておき、 その処理を行ったらそのフラグをセットします。
タイマ割り込みのように定期的に動作するプログラムで、 そのフラグを確認し必要なフラグが全てセットされていたら、 そこでウォッチドッグ・タイマをクリアするようなことを考えてください。

uPD784038のUMに「オペランド・エラーから RETB命令で復帰を行うと無限ループとなるため、 システムの初期化をプログラムで行うようにしてください」とあります。
この場合はシステムの初期化を行わなかった場合、どのような動作になりますか？

この処理を行わないと、以降割り込みを受け付けなくなることがあります。
　78K4では割り込みの優先度制御に ISPRレジスタを使用しており、 ここに現在実行中の割り込みのレベルを設定する事で割り込み優先度の確認を行っております。
ISPRレジスタがクリアできないと、ISPRで示された割り込みレベルより優先度の低い割り込みは受け付けられなくなります。
　このISPRレジスタは読み出しはできますが、書き込みを行う事ができませんので、 ISPRレジスタを直接クリアする事はできません。 このためにマニュアルに記載されたような処理を行う必要があります。

ウォッチドッグ・タイマ割り込み処理から、パワーオン時の処理に分岐させると、 その後の割り込み要求を受け付けなくなってしまいます。

この対策としては ISPR が 0 になるまで RETI 命令を実行してください。
具体的な方法はユーザーズ・マニュアル「割り込み機能を初期状態に戻す方法」 にプログラム例が記載されておりますので、そちらを参照ください。

uPD78F9116Aのウォッチドッグ・タイマを使用してオーバフロー時に リセット信号を発生させた場合、 CPUが再度動き出すにはどのくらいの時間がかかるのでしょうか？

CPUが動作を開始するまでには、
　内部のリセット時間
　実際にクロックが発振するまでの時間
　発振安定待ち時間
が必要となります。この時間の後 CPUは動作を再開します。

uPD78F9116Aの場合には内部のリセット時間は約10uSで、 発振安定待ち時間は 6.55mSとなります。

なお、78K0/Kx1ではリセット解除後は内蔵発振器出力の 17クロック後より動作を再開します。

インターバル・タイマとして使用後、ウォッチドッグ・タイマ・モード 1または 2に切り替え可能でしょうか？

はい、可能です。

「オーバフロー発生時リセット動作」というモードでオーバフローでリセットされた場合、 端子入力の /RESETと同じ動作になりますか？

はい、そうなります。
なお、詳細はユーザーズ・マニュアルの「リセット機能」をご参照ください。

ウォッチドッグ・タイマは、プログラム実行中に１秒タイマと同様に動作停止・開始できますか？

ウォッチドッグ・タイマは一度起動すると、ソフト的に停止させることはできません。
ウォッチドッグ・タイマはソフト的に停止できない事で、ソフトの監視に使用することができます。

注
78K0/Kx1ではリセット解除時にウォッチドッグ・タイマは動作しています。
内蔵発振器が停止可能の場合に限り止めることが可能 (再開は不可) です。

STOPモードではウォッチドッグ・タイマ動作を停止しますが、STOP状態を解除した後は、 どのようになるのでしょうか？

STOPモードではクロックがなくなるので、タイマは停止しています。
STOPモードが解除されたときにはウォッチドッグ・タイマはクリアされた状態から再スタートします。

注
78K0/Kx1では STOPモード中は停止し、解除後には継続してカウントします (クリアされません)。

STOPモードの解除時、クロック発振安定時間中はウォッチドッグ・タイマはカウントしているのでしょうか。
クロック発振安定時間よりもウォッチドッグ・タイマの方が短ければ、 ウォッチドッグ割り込みが発生してしまうと考えられます。

78K0や 78K0Sでは発振安定時間の間はウォッチドッグ・タイマのカウントは停止しています。
従って、お問い合わせのようなことは発生いたしません。
78K0/Kx1で、ウォッチドッグ・タイマのカウント・クロックとして内蔵発振器の出力を選択した場合には、 発振安定時間にウォッチドッグ・タイマはカウントを行いますので、お問い合わせのような可能性があります。

ウォッチドッグ割り込みが発生した場合に、メモリのチェックサムを計算し、 エラーが発生したら、cstartアドレスからリスタートをしています。
しかし、リスタート後に割り込みを受付なくなってしまいました。
PSWもマスク・レジスタも確認しましたが、割り込みは可能状態になっていました。

おそらく、ウォッチドッグ割り込みとしてノンマスカブル割り込みを使用されているのではないでしょうか。
この場合には単に cstartアドレスからリスタートしたのでは、 その後の動作はノンマスカブル割り込み処理としての実行となります。
このために、割り込みを受け付けなくなっています。

この状態を抜けるには、必ず RETI命令を実行してノンマスカブル割り込み状態から抜ける必要があります。
具体的な方法としては PSWと分岐先アドレス (この場合cstart) をスタックに積み、 RETI命令で分岐先アドレスに分岐します。

以下の例では 0番地からベクタを読んで、そこに分岐しています。

    MOV     PSW,#02H ; ダミーのPSWをセット
    MOVW    AX,!0    ; リセットのベクタ値を取り込んでいます。
    PUSH    PSW
    PUSH    AX       ; これでRETIのためのスタックを準備
    RETI             ; これでリセット・ベクタに分岐

uPD780958を使用しているが、ウォッチドッグ・タイマの割り込みの中での処理について、 一般的なコーディングを教えて欲しい。

ウォッチドッグ・タイマの処理方法は個々のシステムで考え方が異なりますので、 一般的コーディングというものは存在しません。

比較的多く使われているのは、リセットのエントリへ分岐して初期化からやり直すものです。
このデバイスの場合にはウォッチドッグ・タイマのオーバフローでリセットをかける機能をもっていますので、 その機能を使用されるほうが簡単です。
何らかのエラー処理を行う必要がある場合には、リセットは使用できませんので、 上のFAQ (78wdt-0011) の回答を参考にして処理してください。

割り込みは全てＣで記述していますので、ベクタ・テーブルの登録はアセンブラで書き、 飛び先はリセット状態と同じ所にします。
これだけのソースになると思いますが問題ありますか？

その処理では一度ウォッチドッグ・タイマの割り込みが発生すると、 以降は割り込みが受け付けられなくなる問題がございます。
この場合にはウォッチドッグ・タイマのオーバフローでリセットをかけるような設定で使用してください。

ウォッチドッグ・タイマのクリア／スタートについてのサンプル・プログラムはありますか？

サンプル・プログラムはありません。
ウォッチドッグ・タイマはプログラムの暴走を検出するための機能で、 プログラムが正常に動作している場合に通るところでクリアすべきものです。
これは個々のシステムで異なりますので、サンプル・プログラムと言うものはございません。

uPD784218AGFで、ウォッチドッグ・タイマがオーバフローして割り込みがかかったとき、 ウォッチドッグ・タイマは停止 (RUNビットが 0) しますか？

いいえ、ウォッチドッグ・タイマが停止するのはリセットがかかったときだけです。
ウォッチドッグ・タイマがオーバフローしただけでは停止しません。

[概要]
７８Ｋ０／Ｋｘ２には従来のウォッチドッグ・タイマを機能強化したものが搭載されています。強化された機能のうちで以下の機能は全く新規のもので、これらはウォッチドッグ・タイマとして特に設定を行わないでも動作します。

• 命令をフェッチできないアドレスからフェッチした場合にリセット発生
• データをアクセスできないアドレスをアクセスした場合にリセット発生

これ以外に

• 特定の期間以外でウォッチドッグ・タイマをクリアしようとするとリセット発生
  （ウィンドウ機能）

などの特徴があります。
ウォッチドッグ・タイマの基本的な内容については、「ウォッチドッグ・タイマの基本」を参照してください。

[使い方の基本]
プログラムが正しく動作しているかを確実に把握することは困難なことです。ウォッチドッグ・タイマを使う場合にも、

"どうなっていれば正しく動作しているか"を最初に定義することが必須です。

このためには、まずプログラムが正常な動作をしているときにはどのような処理フローで動作しているかを把握する必要があります。いろんな場合分けが存在するような場合には大変かもしれませんが、これがきちんと把握できないと仕様の追加が必要になったときや評価項目設定等が大変になります。通常、プログラムを開発する場合には、ここまでは問題なくできるはずです。逆に、この段階で引っかかってしまうようだと、プログラムの開発方法に問題が考えられ、プログラムが完成した（と思った）としても、ディバグ段階でトラブルが多発する可能性が大いに考えられます。

次に、正常な動作時の処理時間やタイミングの見積もりを行います。特に、非同期に発生する割り込み処理がある場合には全体の処理時間が変動しますので注意が必要です。その比率が大きい場合には、ウォッチドッグ・タイマのウィンドウ機能は使えないと考えた方がいいでしょう。

[処理時間解析]
以下に処理時間解析の例を示します。
処理内容のリスト

処理番号	処理内容	処理時間
１	初期化処理	100μs
２	メイン共通処理	1ms／100μs
３	メイン処理１	20ms
４	メイン処理２	30ms
５	共通のサブルーチン	100μs
６	メイン処理１のサブルーチン	200μs
７	メイン処理２のサブルーチン	300μs
８	シリアル受信割り込み	10μs
９	シリアル送信完了割り込み	5μs
１０	タイマ割り込み（1ms周期）	50μs
１１	Ａ／Ｄ完了割り込み	5μs

初期化が完了したら、メイン共通処理を行い、そこでタイマを起動し、その割り込みを許可しておきます。また、シリアル通信の割り込みを許可しておきます。
メイン共通処理はその後の処理要求を待つ部分です。通常はタイマ割り込みにより起動されて、タイマ割り込み処理後、メイン処理１の処理要求確認、メイン処理２の起動タイミング確認を行い、何も処理要求がなければ100μsの処理後はHALTモードに入って次のタイマ割り込み待ちになるものとします。処理要求はシリアル通信により送られてくるものとし、シリアル受信割り込みでは送られてきたデータをリングバッファに保存するだけとします。シリアル通信は最短では520μs間隔（19.2kbps相当）で受信割り込みが発生することがあり、メイン共通処理ではHALTモード中にこの割り込みでHALTが解除された場合には再度HALTに入るものとします。タイマ割り込みでの起動により処理要求が認識され、その解析を行い1msの処理を行いメイン処理１またはメイン処理２に分岐します。処理要求の解析ではサブルーチンを2回コールするものとします。
メイン処理１では必要な処理を行い、その結果のステータス10バイト分をシリアル通信によって送信するものとします。メイン処理１ではサブルーチンを10回コールし、シリアル送信は割り込みを使用することで、メイン処理１と並行して実行できるものとします。
メイン処理２は一定の周期で起動され、８チャネルのアナログ信号を読み込んで、Ａ／Ｄ変換とを処理するためにサブルーチンを８回コールします。サブルーチンではＡ／Ｄの割り込み処理時間を含めて300μsの処理時間がかかるものとします。また、このサブルーチン以外ではＡ／Ｄコンバータは動作しないものとします。


このような場合に、動作としては大きく３つに分けられます。これらは排他的に動作するものとします。
(1)処理要求待ち
メイン共通処理での処理要求待ちで、1msのタイマ割り込みで起動されます。タイマ割り込み処理を含めて150μsの期間処理を行い、残りの期間はHALTモードで停止します。



処理要求があった場合には、タイマ割り込みで起動されたメイン共通処理では1ms及びサブルーチンでの処理（100μsが2回）及び次のタイマ割り込み処理の50μsが必要になります。これはタイマ割り込みの頭からみると、1.3msとなります。シリアル受信割り込みはこの間に０回〜最大では３回入る可能性がありますので、これを含めると最大では1.33msかかることになります。シリアルの処理時間比率は小さいので、それを無視した場合の処理要求確認から実際の処理がスタートするまでのタイムテーブルは以下のようになります。



(2)メイン処理１の実行
メイン処理１ではその処理時間20msにサブルーチンの処理時間（200μsが10回）とシリアル送信完了割り込み処理（5μsが10回）で合計22.05msの処理時間となります。この間にタイマ割り込みは22回発生しますので、その処理時間である1.1ms処理が長くなります。この1.1msの間にもさらにもう1回のタイマ割り込みが発生しますから合計では23.2msかかることになります。処理要求確認のタイマ割り込みからは24.5msで完了することになります。もし、この期間にもシリアル受信割り込みが発生していたとすると、最大で47回のシリアル受信割り込みが発生することになり、その処理時間は0.47msで、それでも次のタイマ割り込みまでには完了できることになります。



(3)メイン処理２の実行
メイン処理２ではその処理時間30msにサブルーチンの処理時間（300μsが8回）で32.4msの処理時間となります。この間にタイマ割り込みが32回発生しますが、それにより実行時間が1.6ms長くなるので、さらに2回のタイマ割り込みが発生し、全体では34.1msで処理が完了となります。これは、処理要求確認のタイマ割り込みからは35.4msで完了することになります。もし、この期間にもシリアル受信割り込みが発生していたとすると、最大で69回のシリアル受信割り込みが発生することになり、その処理時間は0.69msとなります。0.6ms以上シリアル受信処理でかかると、次のタイマ割り込みも発生するので、最悪では36.14msとなります。



以上をまとめると、３つの場合について以下の実行時間となります。

(1)処理要求待ちは1msごとに150〜160μs
(2)メイン処理１の実行は24.5〜24.97ms
(3)メイン処理２の実行は35.4〜36.14ms

ここまででは、各処理における実行時間の見積もりです。以上では個々の処理部の処理時間が与えられているものとして、計算しましたが、実際に命令の実行時間から処理時間を求めるのは困難です。そのため、デバッグを進める中で、イン・サーキット・エミュレータの時間計測機能を用いて処理時間を求めることになります。この場合に注意する必要があるのは、「測定できるのはある特定のパターンで動作している状態での処理時間」ということです。それが、どのような動作であり、同期／非同期で発生してくる割り込みがどのように影響しているかを確認しておく必要もあります。その上で、必要と思われる変動要素を加味した処理時間を求めてください。
これは、ウォッチドッグ・タイマの検討に必要な情報の一部ですが、どちらかと言うと処理性能の評価です。場合によっては、システムの要求仕様として、メイン処理１は20〜30msで完了し、メイン処理２は25〜50msで処理完了するといった条件が最初に与えられる場合もあります。しかしながら、このときの値は殆どの場合でかなりの幅をもちますし、場合によっては最大値しか示されない場合もあり、ウォッチドッグ・タイマの検討ではあまり使えない可能性があります。
また、ウォッチドッグ・タイマの動作の基準クロックにはばらつきが存在します。そのばらつき以上の精度で処理時間を求めても、通常はあまり意味はありません。せいぜい１０％程度の精度で求めれば十分です（この例のように比較的単純な場合はいいのですが、複雑な処理では厳密に求めるのは大変です）。処理時間の精度が要求されるのはウォッチドッグ・タイマのウィンドウ機能を用いるときです。もっとも厳しい条件の場合には、約８％しかクリアできる期間がありませんので、４％以下の誤差で処理時間を求める必要があります。

[動作パターンと検出条件]
実際の検討を進めるには、メイン処理１，２に対する要求がどのような頻度やタイミングで発生するかを明確にする必要があります。その上で、どのような条件で検出を行うかを決めます。
例えば、以下のような要求条件で検討してみます。

（例１）

• 100msに1回メイン処理２が起動される。
• 1時間に１回メイン処理１が200msごとに20回要求される。
  （メイン処理１実行はメイン処理２より優先）

この場合にはどのような状態であれば正常と考えるかを規定する必要があります。ここでは以下の3種類の基準で考えます。

(1)メイン処理２やメイン処理１を実行すれば正常と判断
(2)メイン処理２やメイン処理１を定められた時間以内で実行すれば正常と判断
(3)メイン処理２やメイン処理１を定められた時間範囲で実行すれば正常と判断

(1)の場合にはメイン処理２やメイン処理１だけでウォッチドッグ・タイマをクリアすればいいことになります。処理のループとしては最低が100msですから、ウォッチドッグ・タイマのオーバフローまでの時間をこれ以上に設定して、メイン処理１とメイン処理２でウォッチドッグ・タイマをクリアすればよいことになります。78K0/Kx2ではこの条件を満たすオーバフロー時間は2¹⁵/fRL（最短で124.12ms）、2¹⁶/fRL（最短で248.24ms）、2¹⁷/fRL（最短で489.48ms）となります。さらに、(2)の条件を加味すると、2¹⁵/fRL（最短で124.12ms）を選択することになります。これを選択した場合、メイン処理１とメイン処理２が競合して、メイン処理２の実行が遅らされた場合には、メイン処理２だけでクリアしていると、ここの間隔はメイン処理１の分だけ伸びてしまい、124.5ms以上になり、オーバフローが発生するので、メイン処理１でのクリアも必要になることがわかります。
次に、(3)の例として、ウォッチドッグ・タイマのウィンドウ機能を使う場合について考えてみます。メイン処理１及びメイン処理２の最後でクリアするものとした場合の最短のクリアタイミングは下図の例１のようになります。ウォッチドッグ・タイマのクロックが遅いほうにずれた場合、オーバフロー時間は151.7msとなり、最もウィンドウを開いた場合でもオーバフロー時間の25%の期間（約38ms）はウィンドウが閉じています。下図の例１では最短では34.5ms間隔となるので、このままではウィンドウが閉じているときにクリアをかけることになります。そこで、メイン処理１でのクリアタイミングを処理の頭に変更すると、最短の間隔でも59ｍsとなるので、クリアタイミングはすべてウィンドウが開いている期間におさまります。



（例２）
上記の例１ではメイン処理１が200msごとに起動することにしてありましたが、これを100msごとに変更した場合にはどうなるでしょうか。今度はメイン処理２でのクリアからメイン処理１でのクリアまでの時間が厳しくなり、下の例３のように約38.9msとなります。



この場合には最悪でもウィンドウに納まるので、このままのタイミングでもいいのですが、マージンを大きくしたい場合にはメイン処理１の頭から10ms程度のタイミングでクリアしてください。このように、ウィンドウ機能を用いる場合には条件のちょっとした変更により影響を受けるので、注意が必要です。
ここで重要な点は

• オーバフロー時間を計算する場合には、カウントクロックの最大周波数で計算する。
• ウィンドウ期間を見積もるときにはカウントクロックの最小周波数を使う。

です。ウォッチドッグ・タイマのカウントクロックは規格上-10%〜+10%の範囲でばらつきます。検討を簡単にするためにカウントクロックとして最大周波数だけを用いて見積もる場合には、ウィンドウが閉じている期間は1.22倍して見積もる必要があります。つまり、

• 25%閉じる（75%開く）設定では約30%閉じていて、残り70%開いている
• 50%閉じる設定では約61％閉じていて、残り39%開いている
• 75%閉じる設定では約92%閉じていて、残り8％開いている

が確実にウィンドウが開いている期間となります。その上で、処理時間も最悪の組み合わせで考えてください。



[高度な検出条件設定]
（例３）
これまでは単純にウォッチドッグ・タイマをクリアするタイミングだけで検討してきました。上記の例では、メイン処理１が全く実行されなくてもウォッチドッグ・タイマでは検出できません（１時間に数回しか実行されない処理のことを考慮してウォッチドッグ・タイマ処理を設計するかどうか自体が問題ですが）。そこで、プログラムの処理の状況に応じたフラグを準備しておき、そのフラグを利用してメイン処理１の実行を監視することにします。具体的にはまずは次のフラグを準備します。

• メイン処理１間隔フラグ（カウンタ）

メイン処理１間隔フラグはメイン処理１を実行してからの時間を100ms単位でカウントします。メイン処理１はこのカウンタをクリアし、メイン処理２でカウント処理を行います。メイン処理２ではこのカウンタをチェックして1時間分のカウント以上であればウォッチドッグ・タイマをクリアしないようにします（実際には、１時間／100ms=36000カウントからメイン処理１の実行回数×繰り返しの間隔を引いた値となります。上記の例１のように200msごとでは20×2、例２のように100msごとでは20を36000から引きます）。これにより、１時間以上メイン処理１が実行されなかったことを検出できます。（タイミング例は示しませんが、上記のタイミング例２やタイミング例３と同じです。）

また、メイン処理１は処理の最後で必ずウォッチドッグ・タイマをクリアするようにし、メイン処理２ではこのフラグが0のときもウォッチドッグ・タイマをクリアしないようにしておくことが考えられます。この場合のクリアのタイミング例を下図に示します。このときのクリアの最大間隔は111.64ms、最小間隔は88.36msとなり、オーバフロー時間を2¹⁵/fRL（最短で124.12ms）と設定した場合にはウィンドウの開いている期間を50%（この場合に確実にウィンドウが開いているのは約80ms以降となります）に狭めても問題がなくなります。
（ただし、メイン処理１の直後にメイン処理２を実行したかの確認は行えません。）



さらに、ウォッチドッグ・タイマのクリアを処理の頭で行うようにすれば、処理時間のばらつきの影響はさらに小さくできるので、ウィンドウの開いている期間を25%にすることも可能です（この場合も、メイン処理１の直後にメイン処理２を実行したかの確認は行えません）。どちらのチェックを優先するかにより処理方法を決めてください。


ただし、これだけでは、1時間にメイン処理１を20回実行したかを確認するには不十分です。
そこで、メイン処理１実行フラグを追加することを考えます。

• メイン処理１実行フラグ（カウンタ）

メイン処理１はこのフラグをカウントアップします。メイン処理２ではメイン処理１間隔フラグの値をカウントアップして２または３（メイン処理１の間隔による）になったときにこのフラグを確認して、0または20（メイン処理１の連続した実行回数）以外の場合にはウォッチドッグ・タイマをクリアしないようにします。これでメイン処理１の実行回数も確認することはできます。
このように、ウォッチドッグ・タイマをクリアする際の条件を追加することで、より細かなチェックを行うことができるようにはなります。しかし、あまり複雑にすると本来実行すべき処理の制限が厳しくなる、処理が複雑になることで間違いが入り込む等、別のところで問題が発生する可能性があります。

(2005/11)