タイミング依存のバグが見つかった

不具合に気付いたのはPICのTMR0レジスタを読み出したときです。TMR0は常にカウントUPしているので、読み出す度に異なる値が表示される筈なのですが、０を示したままです。はて？

調べてみると、ホストとPIC間のコマンド送受が正しく機能していません。あれこれコードを弄っているうちに、間違いをやらかしたのでしょうか？節目ごとに取っておいたbackupコードと今のコードの差分を調べたのですが、ホストとPIC間のコマンド送受に影響しそうな変更は見つかりません。orz

最初に機能を組み込んだときの不具合（<==覚悟している）はそれ程応えませんが、あともう少しという所まで進んで、コマンド送受という重要な機能の不具合に見舞われるとかなり気落ちします。

気を取り直してデバッグを始めました。eusartRxBufferには受信データが正しく格納されています。それを読み取るコマンド処理に何か問題がある筈です。

先頭の１バイトをコマンドとして読み取り、残り３バイトをパラメータとして読み取るというのが正しいシーケンスです。Ringbufferを使ったデバッグ・ログで処理の様子を調べてみると・・・

ん！

先頭の１バイトを読み取ったあと、もう１バイト読み取ってから３バイトのパラメータ読み出しを始めています！

何故、余分に１バイト読み取っているのか・・・

フラグを判定した後、直ぐにリセットするのが流儀なので、ほとんど無意識に下のようなコードを書いたのですが・・・

         if( receive_complete )
        {
               receive_complete = false;     <==これが原因だった
               read_command();
        }

receive_completeフラグがfalseということは『受信待ち』を意味します。パラメータ受信を開始してから次のデータを受信していれば問題無いのですが、先に次の受信データが届くと、そのまま読み出してしまいます。

パラメータ受信の開始と次のデータ受信のタイミングが変わり、パラメータを正しく受信できなくなっていました。パラメータ受信を開始するまで、receive_completeフラグはtrueを保っていなければならなかったのです。これまでは、たまたま上手く動いていただけだったようです。

タイミング依存のバグが、リリース後に発覚するとなかなか原因が掴めず往生しがちです。この段階で見つかって良かった！（<==なんて気楽に喜んで良いのでしょうか）