ウオッチドッグ・タイマーで失敗！

マイコン制御機器のプログラム開発、最終版に近づいてくるとあれこれ過酷なテストを繰り返します。
ひとつが「ウォッチドッグ・タイマー」の検証。
「ウォッチドッグ・タイマー」を定期的に再トリガーしないと、マイコンがリセット起動するという暴走対策です。
異常事態が起きた時、これがちゃんと動くかどうかも検証しておかなくちゃなりません。

※プロセッサ誌1989年6月号にレポートした
　「ストロボでマイコンが暴走した！？」
　　・http://act-ele.c.ooco.jp/toukou/toukou1.htm
　　・http://act-ele.c.ooco.jp/toukou/processor/proc198906.pdf

これ、故意に暴走させる良いトリガーでした。
ただし、紫外線消去の窓付きEEPROMでしか使えません。

※キセノン・デス・フラッシュと呼ぶようです。
　　・http://www.neko.ne.jp/~freewing/raspberry_pi/raspberry_pi_3_xenon_death_flash/


ウオッチドッグに絡んで、「あれれ？」な事態に遭遇しました。
デバッグ用としてマイコンの内部状態情報をシリアル出力していました。
1秒周期の状態出力と外部イベントが発生した時の情報の二つです。
動作検証のため、イベント発生の間隔をどんどん短くして、マイコンの内部処理に負荷をかけた時です。
「ウォッチドッグ・タイマー」が働き、マイコンがリセットしてしまったのです。
タイミングにまだまだ余裕があるはずの処理です。
しかし、同じことを繰り返すと再現性があります。
どこかの処理がスカタンしているのか、メモリーを食っているのか・・・
ウォッチドッグ・タイマーが働く原因が分かりません。
状態はイベント周期の違いだけ。

原因は・・・
デバッグ用に出力していたシリアル出力でした。
文字出力のためのバッファがいっぱいになり、出力完了待ちが生じていたのです。
通信ボーレートを昔ながらの「9600BPS」で行っていたのが、バッファ詰まりの原因。
イベント周期が早くなると、出力する文字数が増えます。
文字送出が間に合わなくなると送信電文がバッファに溜まります。
それががいっぱいになると、出力完了待ちが発生。
その待ち処理部分ではウォッチドッグを叩いていなかったのでリセットが発生したという次第。

出力文字バッファが一杯の時、バッファが開くまで待つか、出力しようとしていた文字を捨てるか悩むところです。
デバッグ用なら、「捨てたよ」をマークして、その行全部を捨ててしまう処理かと。