STM32F4 DISCOVERYのAD変換のトラブル対策

ロボット作ろう：シェーキー製作記

【後日追加】下記トラブル対策は正しくありません。
こちらの投稿をご覧ください。

シェーキーのソフトウェアもだんだん格好がついてくると、今までなあなあにしていた問題点が浮上してくるもので、最近はそれを潰すのに時間を割かれるようになりました。
その中でも致命的なのがAD変換でおかしな値を読み込むトラブルです。今回の投稿はこれの対策のお話です。

本機では、4ch分のAD変換値をDMAで周期的にメモリに展開し、アプリケーションからはこのメモリを参照することでアナログデータを取得するようにしています。これはSTM32ではポピュラーな手法のようです。

今回問題になったのは、リセット後AD変換の結果として非常に大きな値が読み込まれることがあるということです。本機ではAD変換の分解能を12ビットに設定しているので、最大値でも4095のはずですが、変換値が１1342とか23044とかというありえない値になってしまうのです。しかもこの現象は再度リセットするまで継続し、また、リセットしても間が悪い（？）とまた同じ結果になってしまうというタチの悪いものです。

おかしな値になっても、読み込むたびに若干変動するのでAD変換はしているようですが、何が起こっているのでしょう。

デバッガから起動した場合よりも、USBケーブルをはずしてスタンドアロンで起動した場合に高い確率で発生します。

これはかなり具合が悪い。なにか未設定のビットでもあるのかと調べましたが見つからずじまい。結局試行錯誤の結果、下記のように初期化シーケンスを組むことで何とかすることができました。

初期化シーケンス

電源投入（パワーオンリセット）
１・サーボパルス発生
２・100msほど（forループで）待つ
３・AD（DMA転送設定）開始
４・USART設定
５・GPIO設定
６・SysTick割り込み設定

最初にサーボを初期化するのは、速やかにサーボパルスを発生し、電源投入時にサーボが暴れるのを防ぐためです。そのあと、100msほどおいてからAD変換の設定をします。対策前はこの時間遅れがなく、即座にADを初期化していました。これを入れただけで現時点では問題は再発していません。

なお、時間遅れの部分は

uint32_t ii;
for(ii=0; ii<1000000; ii++){
}

という時間つぶしループで実装しています。

トラブルが起こってないかどうかは、シェーキーにバッテリ電圧読み出しコマンド"CHKBATT"を送ればわかります。正常なら12Vくらいの数値が返ってきますが、初期化に失敗していると200Vとかの値が返ってきてびっくりします。

うーむ、原因がわからないので気分が悪いけど、まあしょうがないですね。現時点ではこれでいきましょう。