Oscilogi410の不具合対策で苦労した

(2016.09.28)
24時間連続計測試験について、『連続計測試験に失敗して・・・何とか対策を施して・・・』と記しましたが、”エラーで通信が途絶えたら、それを修復して計測試験を続行する”という対策でした。充電器の充放電試験を出来るだけ早く行いたいという事情を抱えて、苦肉の策でした。

少し余裕が出来たので、そもそも通信が途絶えてしまう原因は何なのか調べてみることにしました。

Oscilogi410は次の三つのプログラムで構成されています。
（１）Osci_Logi_Console（JAVA Swing）
（２）BCM2835_FOR_JAVA（C）
（３）Oscilogi2（XC32）

通信が途絶えてもOscilogi2の計測動作は継続していて、BCM2835_FOR_JAVAを再起動すると停止した通信が回復するので、Osci_Logi_ConsoleとBCM2835_FOR_JAVA間で問題が発生していることが推察されました。しかし、計測データとコマンドの送受を何千回も繰り返すことが出来るのですから、基本的な動作に問題は無く、ある特定条件下で回復出来ない不具合が発生していると考えました。つまり、どこか拙いタイミングでOsci_Logi_ConsoleとBCM2835_FOR_JAVA間のContext切り替えが生じているのではないか？ということです。しかし、その対策のために異なるプロセス間のContext切り替えを望むように操作することなんて出来るんでしょうか？

----------------------------------------------------------------
(2016.09.29)
そもそも、マルチコアのRaspi2Bや3BでContext切り替えというのは間違いです。
buffer-empty対策が抜けていただけだったのかも・・・----------------------------------------------------------------

対策その１
BCM2835_FOR_JAVAのnice値を+1してみる
対策その２
Osci_Logi_ConsoleとBCM2835_FOR_JAVAのContext切り替えを意識して行う
==>切り替わっても良いと考える所にusleep(5000)を入れてみる

この二つの対策で通信が途絶えることは無くなりました。残ったのはPICのデータ・ポインタが時折変な値を示すという不具合でした。どうやら一連の計測を終えて再計測を開始する辺りで、何かが起きているようです。

ここはPICkit3の出番です。データ・ポインタが異常値を示したときのOscilogi2の状態は・・・COMMAND_NULLになっています。これでデータポインタを読みだすと数値ではなく"NULL"という文字列が出力され、受け取った異常値（1314212940）と一致します。このとき受け取ったコマンド文字列は・・・”RCV 3”で正しく受信している。ということは・・・一旦設定されたCOMMAND_RCV_3が、その後でCOMMAND_NULLに書き換えられた？

ビンゴ～
一連の計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理が見つかりました。

データポインタを読みだす部分はこんなプログラムです。
i2c_write("RCV 3");
ope_sync();
idle_10ms();
i2c_read(buff,8);

”RCV 3”を出力してから、８バイトのデータを読み出すまでの僅かな時間に、偶々計測を終了してコマンド・ステータスをCOMMAND_NULLに書き換えていたという訳です。

計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理は必要ないことが判ったので、これを削除して一連の不具合対策は

『これにて一件落着～』 チョン（<==拍子木の音です）

------------------------------------------------------------------------------

このブログを読んで、自分もやってみたいと思ったあなたへ
是非、組み込み系の世界に飛び込んで下さい。
マルチコアのぐちゃぐちゃしたデバッグ作業があなたを待っています。

うへ～と思ったあなたへ
その反応は正常です。組み込み系（特にマルチコア・プログラミング）には近づかない方が身のためです。