昨日は、もう一つ、大きなバグが取れた。
先に説明した移動平均のロジックで、測定値が異常値となり緊急停止し、異常値が正常に戻って再開する際、移動平均を計算する配列に前の値が残ったまま移動平均の計算を再開すると、残っている値に新しい値が加算され、2バイトの範囲をオーバーしてメモリ破壊しリセットがかかるという現象。
移動平均ロジックを組込んだのは半年ほど前で、その後、LED照明やバッテリパルサーやらと余計な事に手を出していて、本筋のこちらの開発をなおざりにしていたのだが、実は、たまにリセットがかかるという症状には気付いていた。リセットがかかっても、その後は設計通りの動きをしているので、ま、いいか。。。。と見て見ぬふり。。。。
でも、ず～～～～～っと気持悪さを持ち続けていた。
そんな不具合が、ようやくすっきりと解消され、気分すっきり、秋晴模様・・・となるはずだった。
しかし、神は次なる試練を私に課すのであった。。。。。
プログラムの論理を簡単に説明すると、以下のように4つの制御系が常時回っている。
１．電圧測定は、mainループで常時測定
２．測定値や動作モードは262ms周期で表示(TMR1割込み×4回分)
３．MPPTターゲット電圧再設定は67s周期で実施(TMR1割込み×1024回分)
４．電圧制御のためのPWMデューティ制御は8ms周期(TMR0割込み)
AD変換の結果がきちんと取り込まれることを確認するまでは、PWM電圧制御ロジックは止めて検証していた。そこまで正常に確認ができたので、TMR0を動かして電圧制御の検証に入った。
と、と、ところが、TMR0を動かしたとたん、何とも不可解な現象に遭遇。切り分けするために、電圧制御ロジックは回避して、割込みハンドラ内で割込みを受ける部分のみを組込んだだけで動作を確認。
すると、移動平均を計算する配列の値が異常値を示し、Halt症状が発生。しかも、その発生タイミングが不定期。それほど時間を待たなくても確実に発生する。これまた、やっかいな不具合。。。
シミュレータやデバッガを総動員して、可能性のあるところにスナップショットを入れて追掛けるものの、なかなか捕まえることができない。どう考えてもロジックミスではなく、何らかの異常現象が起きている模様。
ch=0;
while(ch-3){ // ADチャネルループ
・・・
ch++;
}
ADチャネルは3つ使っているので、上記のようにch変数に0、1，2と順番に値が設定されるループ処理している。ところが、ごくまれにchに0x79～7Fの値が飛込んでくる。このパラメータは、ADCON0というレジスタに設定される基数に利用しているので、AD変換のチャネルにおかしな設定がされ、結果としておかしな値が返ってくると言う状況のようだ。
先日の例もあり、TMR0の設定がまだおかしいのかと、よくよくデータシートを読んでもそれらしい設定は存在せず。また、PICチップはこれまでいろいろな動作検証に使い回してきたものなので、PIC個体の故障も疑い、別のチップで確認するも、同じ症状が確認され個体原因ではないことが判明。
気持悪いながらも、以下のようにchを3以上の値ははじくようにしたところ、この不具合は回避することができた。しかし、不定期にchにおかしな値が飛込む状況は回避できていないので、根本的な解決とは行かずすっきりしない。
while(ch<3){ // ADチャネルループ
それでも何とか気を取り直して、電圧制御ロジックを組込んで、動作検証。
・・・・案の定、更におかしな症状に悩まされることに・・・
これまた不定期で、移動平均の変数に、おかしな値が入り、値チェックのエラーに引っかかる状況。どのような場合に発生するか、いろいろと試しながら特定しようとしたが、どうしても論理的に切り分けることはできず。2日がかりで原因特定しようとあれこれ調べたが、結局特定できなかった。
仕方ないので、TMR0の割込みをあきらめ、TMR1の割込みを転用して動作を確認。すると、何事もなかったように設計通りの動きをする。
う～～～～～～～～む。。。。。TMR0は、PICで最も基本的なタイマで設定もシンプル。それなのに、こんなに不可解な動作を引き起すことがあるなんて・・・
TMR1は表示系とMPPT電圧再設定のための周期に最適化して調整してしまっている。そこにPWM制御周期も入れるとなると、周期パラメータを最初から設計し直しになるので、頭の痛いところだ。
前半の気分よさとは裏腹に、最後はTMR0にあざ笑われているような気がして、何とも敗北感たっぷりに週末が終ってしまった。