Darkside（リンクエラー修正しました）

　無限ループに入ってしまう場所を調べる。
　ＬＥＤ点灯命令を挿入するのが影響も少なくて確実だが、問題は試行回数が増えること。ＳＴＭ３２Ｆ４のデーターシートによれば、プログラムコードを格納する内蔵フラッシュメモリーの書き込み回数は最低１万回が保証されている。ただしこれは試験値ではなく、経験則に近い部分がある。１万回というのは十分な回数ではあるものの、事実上無限として扱うには少な過ぎる。１日に１００回書き換えて１００日分と考えると、開発が難航した場合には不安。
　そして、１万回書き換えて温度５５度で、データー保持期間は２０年と見込まれている。これも、微妙な年数だ。ＰＩＣ等で自作した機器で２０年経過してるものなどないが、フラッシュメモリーの保持期間がネックとなって動かなくなる工作も近未来には出て来そうだ。

　音楽ＣＤのデーターに寿命があり、それは人間の一生に比べて長いとはいえない。そういうのも以前に結構話題になったものだ。
　最近話題にならないのは誰もＣＤなんかで音楽聴かなくなったからだが、その新しい再生機器は大抵フラッシュメモリーに音楽を記録している・・・

　ともあれ無限ループは、７ビットアドレス送信後だと判明した。
　ＳＣＬとＳＤＡを逆接続していた時は、ここでＡＣＫが返って来なかった。それが再現している。プログラムコード修正前は返って来ていたのに、なぜかＡＣＫフラグは立たないだけでなく「ＡＣＫが返って来ない」フラグも立たない。更に調べると、バスエラーフラグが立っている！
　しかも、リセットボタンを押すと最初のスタート送信の段階で早々にバスエラーになる。
　どこかでおかしな信号が送られていて、Ｉ２Ｃバスの状態がおかしくなっているのか？
　ポイントは、リセットボタンを押してもセンサーはリセットされないという点。おかしくなったＩ２Ｃバスは、電源が入ったままのセンサーで「おかしな状態」がキープされるかのよう。一度電源を切らないと、Ｉ２Ｃバスが使えるようにならない。

　試しにクロックを４００ＫＨｚから１００ＫＨｚへと落としてみたが、バスエラーは変わらない。
　仕方なく最後の手段、オシロでＩ２Ｃの信号を調べる。

　通信相手は磁気センサーで、スレイブアドレスは 0x1d である。その２倍の 0x3a が確かに送信されている。１００ＫＨｚだと、波形もナマっていない。

　９発目のクロックを見ると、ＳＤＡはしっかりＬになっている。つまり、先日とは異なりちゃんとスレイブが反応してくれている。それなのに、なぜバスエラーなのだ？
　しかも、その後ＳＤＡは一瞬ＨになってすぐにＬになっている。

　ああそうだ、書き込みを３回行っているんだった。それにしても、２回目と３回目が詰まり過ぎている。これは、また何か凡ミスやらかしたな。

　これでＩ２Ｃが読めるようになった・・・というほど甘くはない。配線はＯＫになったが、スレイブからデーターを読むためのプログラムは確定していない。有力案が２つあって、どちらが正解か分からない。
　可能性の高い方を試すと、磁気センサーの値が取得できた。ところが、液晶に無限ループで常時表示させてみると、１秒ぐらいで表示が動かなくなる。しかも、動かなくなるまでの時間が一定しない。

　Ｉ２Ｃでは、ステイタスが変化するまで待つ、という部分が多い。いつまでもステイタスが変化しないと、無限ループになってしまう。通信不良だか何だかで、ときどきステイタスが変化しない場合があるのだろう。
　フライトコントローラーが無限ループに入ったら、墜落する。どんな状況でも、絶対に無限ループに入らないようにプログラミングしないと、使い物にならない。

　考えてみると、空モノは本当におっかない。プログラムの不具合がそのまま墜落に直結するのだから。クルマであれば、止まれば助かるだけまだマシだ。
　これだけ世界の空を航空機が飛びまくっていて、搭載マイコンの不具合による墜落はほぼゼロってのは凄いことだと思う。自分でやってみると実感するが、どうやって信頼性を確保しているのかちょっと想像できないような偉業である。

　無限ループというだけなら、ステイタス待ちのループにタイムアウトを作れば済む。
　タイムアウトをキッチリと設けたプログラムに書き換える。すると、最初の１回の表示までできなくなった。センサーデーターの取得を何十回か繰り返すうちに無限スープに入っていたものが、１回目から無限ループに引っ掛かる（正確には、タイムアウトで処理が打ち切られる）ようになってしまったのだ。

　容疑者を順番に潰して行った結果、Ｉ２Ｃ障害の原因は配線ミスである可能性が一番高そうだ。

　テスターを使い、結線を確認する。
　ＳＴＭ３２側のピンアサインは、割り当てが重複すると機能しない。だから、方眼紙に使用予定をメモし、確実に振り分けできるよう注意している。そのメモと、実際の信号は合っているか？
　メモには配線の色も記入してあるが、実際の配線と一致しているか？

　正しいピンから想定通りの信号が出ていることは、先日オシロで確認済み。そのピンから、メモ通りの色の配線に直結していることが確認できた。すると次は、ＰＸ４ＦＬＯＷのコネクターに導通しているかどうか？である。これもＯＫ。
　ただしＰＸ４ＦＬＯＷの場合、５Ｖ電源線は赤だがそれ以外の３本は黒であり、ＧＮＤは端だからいいとしてＳＣＬとＳＤＡが見た目で区別できない。ＰＸ４ＦＬＯＷの資料を確認し、どっちがどっちであるかを調べる。もちろん、dsPIC で動作確認した当時もそれは確認したのだが。

　すると、ＳＣＬとＳＤＡが逆接続である可能性が高いと判明。
　パソコンの電源が入らない理由を散々調べたら、コンセントが抜けてました・・・みたいな話だが、dsPIC で動いていたものをそのまま繋ぎ直しただけなので、可能性としては非常に低かったのだ。それがなぜ逆接続されてしまったかと言うと、配線の色。ＳＣＬとＳＤＡには茶色と紫色の配線を使っていたのだが、どっちがどっちなのか。dsPIC とＳＴＭ３２では、逆になっていたのだ！

　大型施設で大事故とか、病院で患者が死ぬとか、世間でも良くある事故原因である。電源線は普通に赤黒だったので、機器は壊れず問題なく電源が入っていた。

　調べまくったおかげで、Ｉ２Ｃに関する知識がかなり増えた。
　ＳＴＭ３２Ｆ４の初期化も調査。
　結果的に、ソフト側はもう改善しようがなさそうだと判明。Ｉ２Ｃ初期化から割り込み関連を削除してシンプルにし、各所のコードも再度チェック。しかし、実機で走らせると症状は全く同じ。

　危惧した通り、マスターデバイス側には問題がない。あくまで、スレーブデバイスが無反応なのが問題なのだ。

　こうなるともう、配線ミスしか考えられない。だとすれば、dsPIC に接続されていた際は問題なかったのだから、相当な凡ミスやってることになる。
　そうなると、Ｉ２ＣやＳＴＭ３２の信号レベルなどもっと立ち入った情報が欲しくなる。単純にＳＣＬとＳＤＡを逆接続してました、というレベルならまだいいのだが。

　ＳＴＭ３２のＩ／Ｏピンは、アナログ入力を除いた大半のピンに５Ｖ耐性がある。通常は３Ｖ動作のデバイスに５Ｖが入力されると、壊れる。しかし、ＳＴＭ３２の場合は５Ｖが入っても大丈夫で、Ｈレベルとして認識される。これは便利だし、オープンドレイン出力で５Ｖ信号を送り出す場合など５Ｖ耐性がないと困る。ここをうっかりしていて、サーボパルス出力に割り当てた４本のピンのうち３本には５Ｖ耐性が無いと判明。ＰＷＭ出力を利用しているため、好き勝手なピンに割り当てる訳にも行かず、Ｉ２Ｃ以外のところで問題点が発覚してしまった。

　だが、更に確認すると、５Ｖ耐性とはいえそれに最初から頼るのはマズいと気付く。ＳＴＭ３２は、電源電圧より高い電圧の入力に耐えられるような特殊な半導体として製造されているのではなさそう。つまり、電流に５ミリアンペア以内という制限があり、その範囲内で壊れないよう内部に保護回路が入っているだけっぽい。状況次第では壊れるし、定格以内で使用してもアナログ部分の精度に悪影響があると書いてある。
　Ｉ／Ｏピンの割り当て問題もあるので、大人しくレベル変換ＩＣ使った方が良いと思われる。

　こんな場合に真っ先に調べるのは秋月電子。案の定２５０円で基板が売られている。レベル変換ＩＣを２０ピンのＤＩＰに変換したもので、電子工作で扱い易く、小型軽量。重量が気になる空モノにも採用する気になれる。８信号対応なので、受信器パルス入力４本とモーター制御サーボパルス出力の４本をまかなえる。これで、完全にレベル変換の後腐れを無くすのがベストだろう。
　こういった頼り甲斐を重ねて来た実績があるから、秋月電子は人気なのだ。
　東急ハンスもそうだが、「欲しいものが売っている」から成功している。ニーズを的確に掴んだ売り手は、こんな時代でも栄える。とても単純な話だ。

　ハード的には、配線ミスが怖い。

　ＰＸ４ＦＬＯＷも３．３Ｖ系である。一方のＳＴＭ３２Ｆ４は、３．０Ｖ系である。しかし、最初のスレーブアドレス送信は、ＳＴＭ３２Ｆ４側がマスターとなって行う。３．３Ｖ系のＩ／Ｏに３．０Ｖ入力されて認識されない可能性は高くないだろう。
　配線を確認しても、ＰＸ４ＦＬＯＷとＳＴＭ３２Ｆ４のＩ２Ｃ配線は、直結されている。レベル変換ＩＣを通っていないのは間違いない。

　そもそもこの配線は、dsPIC で動作していた実績あるものを取り外し、移植したものだ。中途の配線は間違っていない。
　どんなに確認しても、配線ミスは発見できない。

　そうすると、Ｉ２Ｃの初期化ミスが気になる。サンプルプログラムでは、割り込みを活用してＩ２Ｃ通信を行っているのだ。党是だが、割り込みの初期化なども行われている。しかし自作制御ソフトでは、Ｉ２Ｃで割り込みは使わない。その関係で、おかしなことになっているのかもしれない。だが、オシロでの解析は、スレーブが返事してくれないのが根本的にマズいのだと判明している。

　返事してくれないスレーブが悪いのに、マスター側をいじってどうにかなるものなのだろうか？
　オシロ的には、マスターは正常に呼びかけを行っている。悪いのはスレーブ側であるかのように見える。しかし、スレーブに問題ないことは dsPIC で確認できている。理屈の上では、現象面だけでの判断では、完全に手詰まりなのだ。犯人不明。