成功するときのバルクデータを取得。子のバルクデータでは必ず成功するので、EEPROMに書き込むまでにデータを壊しているようです。
続いて、エラーを起こすバルクデータと、それをEEPROMに書き込むときのパルスシーケンスの取得に成功。これをみると、I2CでEEPROMにデータを送る時点で、データが壊れています。
QY20から取得したデータを一旦、内部バッファに溜めます。並行して、EEPROMに書き込む処理が内部バッファから読みだすのですが、この内部バッファ操作の並行処理で爆っている可能性が高いです。データ抜けや少しズレた位置にデータが入っている現象は、バッファ操作ミスで起きた可能性があります。
リストアに成功する状況をテスト1回目で得られたので、そのままリストアの複数パターンのテストなどして、切り分けられたため、1時間半くらいで、原因の推定までたどり着きました。
で、、、入念にリングバッファ処理をチェック。引用元のプログラムは、受信用と送信用の２つのバッファがあり、それぞれに書き込み処理、読み出し処理の４つがあります。リングバッファアクセスのために、間接アドレス指定で、FSRレジスタを使っています。PIC16F1823/1825は、FSRが２つありますが、バッファ操作は上記の4つの処理があり、割り込み等で同時にFSRを利用しないように、排他処理しています。この排他処理によって、callの失敗が起きており、エラー処理が不十分というか、割り込み中なので、エラー処理できずに終わる可能性がありました。
今回のアプリは、受信、送信を同時に行うことはなく、バッファも1つにしました。
なので、２つのFSRを書き込み用、読み出し用でそれぞれ使えば、排他処理は不要です。また、書き込み中の割り込みで書き込み処理が走ったり、同様に読み出し中の割り込みで読み出し処理が走ることもないので、多重コールの心配ありません。
ということで、リングバッファ操作の排他制御を外しました。
で、、、数回のテストですが、すべて成功しているので、多分大丈夫。
昨日の暗雲垂れ込めた10時間の苦労が嘘のように一気に解消です。10時間の中で、テスト用、確認用のロジックを組んだことも解決に役立ったのですが。。
あと、なぜか、I2Cのクロックが出ない問題が起きなくなっています。
プローブの有り無し関係なく、10kΩのまま。
抵抗値は変更していないのですが。。。。いつ再発するのか。。。。