GPS/GNSSモジュールを試用する11 -GtopFlashToolの謎に迫る-

今回の記事はSTM32の内容にもがっちり絡んでくるのでカテゴリどうしようかと悩み
ましたが結局GNSS関連としました。



前回、Gms-g9のファーム更新の際にGtopFlashToolなるものを使用してUART経由で
ファームウエアのアップデートを行っております。その時にGPSロガーとして使用して
いるSTM32Primer2に仕込んだUSB-CDCからではうまくアップデートを行うことが出来
なかったことを述べておりました。今回時間が出来てようやく重い腰を上げて調べる
ことになったのですがそこには意外な結果が待ち受けていたのでした。


●COMポートが開かない??
Lチカから先になかなか進むことができないねむいさんが唯一実用レベルで作った
STM32Primer2ベースのGPSロガーはSTM32のUSBデバイス機能を利用してGPS/GNSS
モジュールのNMEAセンテンスの記録の他にUSB-CDCとUSB-MSCを実現しております。

USB-CDC機能は主にGNSSモジュールのAGPS等の機能設定を仮想COMポートを開いて
シリアル通信の形で、USB-MSC機能はSDカードに記録したデータをPC上から簡単にTXT
ファイル形式で参照できるように出来ております。


で、GlobalTop GPS Viewer(v1.8)からでは上記のとおり問題なくUSB-CDCの仮想COMポ
ートを開きバリバリ通信できるのですが…

なぜか同じGtopが提供しているGtopFlashToolからはCOMポートが開けませんみたいな
エラーを吐いてアップデート作業ができません。

一方はちゃんとCOM開けてもう一方は開けないとかイミフだったのですが検索してい
るとそれっぽい質問が見つかりました。
Windows環境下ではUSB-CDCをなし得るためにusbser.sysを利用するのですがinfファイル
は自前で作らないといけません。MSDNの情報を基にinfファイルをいじってインストール
してみましたが…やっぱりダメorz

>http://support.microsoft.com/kb/837637/ja
> ユニバーサル シリアル バス (USB) モデムの .inf ファイルは Usbser.sys
> ドライバーを使用して両方および Usbser.sys ドライバー .inf ファイルからを
> 直接参照できます。ただし、お勧めしませんこの。
人間の言葉しゃべれこの。


もしかしてGtopFlashToolが何らかのUSBの通信レベルで何かがコケて仮想COMポート
が見えて無いのかと思い埃をかぶっていた秋月ロジアナを用いてUSBのプロトコルを
解析してみたのですがUSBの通信上ではSTALLした箇所が見つけられませんでした。
↑USBの解析できるまでのロジアナの設定で苦労しましたorz

ちょっと困り果ててしまいましたが鴨川を散歩してる最中にGPS Viewerから仮想COM
開けてたのを思い出してひょっとして何らかの固有の文字列をやり取りしてCOM開い
た判定してるのかと思ってUARTの通信を見たらなんと仮想COM開けてて信号のやり取
りまで出来ているようでした！ちゃんと開けてるじゃないですかー！
しかも制御文字もちゃんと送信されてるのでUART周りは全く問題なしと判断しました。
そもそも糞詰まり対策もやってダブルバッファリングまでしてるのでSTM32のUARTレ
ベルに関する点は問題はないです。となるとやっぱりもっと上の階層の問題ですか。


●別の仮想COMではどうなのか
依然述べたとおりFT232Rに代表される出来合いのFTDIのUSBシリアル変換ICなら全く
問題はなし、自作のUSB-CDCが怪しいと思い別の物を試してみました。

1．STマイクロ謹製のSTM32F1のUSB-CDCのサンプル(STM32F103/107共)
　　->できない
　　※私のSTM32Primer2のUSB-CDCはこれがベースです。
2. LPC2388のLPCUSBのUSB-CDC
　　->できない
3. STマイクロ謹製のSTM32F1/F2/F4用のUSB-CDCサンプル
　　->できるじゃない！
4. MBED CMSIS-DAPのVCOM(FRDM-KL25Zを使用)
　　->できるじゃない！

…ん？それじゃSTM32F1系のUSB機能がやばいのかしら???

5．Versaloon(STM32Primer2と同じSTM32F1系)のVCOM
　　->できるじゃない! orz
　　※VersaloonのUSBのソフトウエア側は独自実装


つまりSTM32のファームウエアの問題ですかorz
でもいろいろ試しててGtopFlashToolのエラーの出方の違いに気づきました！

先にGNSSモジュールをなにも繋がずにフラッシュ書き込みを実行しようとすると
駄目な方は繋いでも繋いでなくても"Fail to open the COM Port"になってて行ける
方はとりあえずCOMポートは開き何か読みに行ってるようで"DL_HANDLE error code"
になっていました。


●SEND_BREAK
というわけでSTM32Primer2のRlinkはOpenOCDでデバッグできないのでそれとソフト的に
等価なSTM32F107VCTのUSB-CDCを用いて上の"Fail to open the COM Port"になる
瞬間をinsightで捉えました…ら一瞬で原因が分かったorz


"Fail to open the COM Port"になる直前にVirtual_Com_Port_NoData_Setup()という
関数を通過していて引数に0x23が来てエラーを返していたことが判明。
この関数はホストから送られてくるUSB-CDC固有のリクエストを扱う関数のようで

このページによれば0x23はSEND_BREAKに相当するものであるとのこと。
STM32F1USB-CDCのサンプルでは未サポートとしてエラーを返していたためGtop Tool
はSEND_BREAKを実行できないCOMポートと判断して"COMポート開けません"とエラー
を返していたことが判明。

ってわけでSEND_BREAKのハンドルを追加してSEND_BREAKのリクエストが送られて
きたらとにかく"USB_SUCCESS"を返すようにしました。


おおっ！

GPSTr@ckerのUSB-CDCでもGms-g9のファーム書き換えできたじゃない♥

GPSViewerではSEND_BREAKは一切送信されていたなかったのでエラーにならなかった
(=COMポートを開くことができた)ことが理解できました。

ところでSEND_BREAKって何か？ともっと調べてみるとUSB-CDC-ACMの規格で定められ
たものだようで文字通り"BREAK信号を送信せよ"という意味です。
そしてBREAKって何というとRS-232Cの規格で定められたものでTxDをスペース(論理L)
に固定する行為を指すとのこと。RS-232Cの電圧レベルでいうと論理が逆転するので、
一定時間+15Vに固定することになります。

そしてGTopFlashToolはなぜわざわざSEND_BREAKを送信していたかということですが、
それはMTK系のGNSSモジュールのファームウエアアップデートの方法にあります。
MTK系モジュールはUART経由で特定のコマンドを受け取るとセルフアップデートモード
に推移しますがその過程で現在通信しているボーレートからセルフアップデート通信
用に自動的にボーレートが上がります。具体的には115200bpsに推移します。このとき
GtopFlashToolからCOMポート経由でBREAK信号が送られているようです。
9600bpsから急にレートの高い115200bpsに上がって間違ったデータとして受け取られ
ないように一定期間データの送信を止める措置を行っているわけです。



というところでいろんなマイコンのUSB-CDCの実装を見ているとSEND_BREAKに対する
取り扱いは現在ではごくまれにしか使われないためかまともにBREAK状態になる実装は
めったになく、適当にOKで返してるのが殆どです。逆に言うとSTM32F1系のUSB-CDCの
サンプルはちゃんと"unsupported"で返してたからマシだったのかも！？

そしてGitHubのGPSTr@ckerは既にGtopFlashToolでもちゃんとファームの書き換えが
出来るように修正済です。さらにFatFs0.10aに更新し今更ですがUSBライブラリもF1系
最終のV4.0.0準拠にして益々最強に強めております！


●あのお方
今回いろいろ調べて最終的に気付いたのですがUSBのファームウエアがらみで困って
いる人のもとに颯爽と現れ強力な解決策を提示して爽やかに去っていくtsuneo氏が
SEND_BREAKにもやはり言及されていました。私の中ではFatファイルシステムにChaN
氏が居ればUSBにはtsuneo氏が居るといった感じです。

そういう私は2014年の今でもUSBアレルギーが全く克服してないのでこれを機会に
今年はUSBを自分の物にすることをテーマに進めていきたいと思います！

Go to top of page