Fenrir's BLog

年度が替わりまして、オートパイロットシステムSuper Sylphideの開発が別案件に組み込まれたせいもあり、開発スピードをあげる必要が出ています。できれば夏頃に完成させたい予定ですが、予定は未…、いや、がんばらせていただきます。

今回の記事は以前からこのサイトでもとりあげているUSBの複合デバイス(composite device)の話をとりあげてみようと思います。Super Sylphideには計算を担当するDSP以外に、SDカードへのログの記録、そしてセンサ情報の取得など、基本的な処理を担当するマイコンSilicon Laboratories C8051F340が搭載されていますが、これにはUSBの機能が搭載されています。ならばSuper SylphideをUSBでパソコンに繋げて、USBのメモリスティックよろしくログの送受信が簡単にできたり、あるいは通信機能を備えてHIL(Hardware in the loop)試験を簡単に行えたら、どんなに素晴らしいだろうという結論に至りました。そういう理由からUSBには2つの機能、記憶装置として認識させるMSD(Mass Storage Device class)と、通信環境を備えていることを示すCDC(Communication Device Class)、2つの規格に準拠させることにしました。

実はこの部分はGPSロガーと共通の実装であり、今までの開発履歴、『USBでMSD+CDC (Composite Device)』や『WindowsでMSD+CDC (USB Composite Device)』、『USB Composite DeviceでCDCが動作しない』を見ていただくと現状が把握していただけると思います。過去の記事の表題からもわかるとおり、この実装がうまくいっていませんでした。

そこで最近、久しぶりにコードや規格書のおさらいをしてみたところ、規格標準を無視している箇所がいくつか発見されて、これ以上バグがでないだろうという状態まで改善することができました。主な修正点としては以下のものがあげられます。

• MSDにおいて、実装されなければならないSCSIコマンド(今回はRequest Sense)を見落としていた。それでもM$で動作していたのは不思議。
• MSDで回避しなければならないエラーとその対処方法(usb.orgにある仕様書『Mass Storage Bulk Only 1.0』 (PDF)でいうと6章)の実装が不完全だった。特にscsiコマンドを格納しているCBWが不完全だった場合、Standard RequestのClear FeatureによってEndpointのHalt状態を解除してはならないことが盲点だった。
• デバイスドライバusbser.sysの不具合のために、CDCの転送において64byteの倍数のパケットを送る際は最後にzero length packet(ZLP)を送る必要がある。この問題を通信単位を32byteに落とすことで回避した。
• ディスクリプタでProduct Stringを特定していなかった等々。

現在の状態はGPSロガーのファーム、特にMSDの実装とその内部コマンドであるSCSIの実装を見ていただけるとよいと思います。問題の発見にあたっては、USB.orgが提供している準拠度をはかるプログラム USBCV R1.3、並びにSilicon LaboratoriesのUser Forum(特にTsuneoさんという方の情報が的確)やusb.orgのDeveloper Forumが参考になりました。

さて、この状態で意気込んでWindows XPのPCに接続を試みたところ、従来どおり認識はされました。お次はデータのやり取りはできるか、というとことでファイルの読み書きをしてみると、これも従前どおりできました。MSDの機能は正常に動作しています。
最後はCDCの機能、これを調べるためにハイパーターミナルを立ち上げて通信を試みます。なんと数十秒間、データが受信できているではないですか(かなり狂喜乱舞しました、笑)、が、その後MSDの機能と同時使用しようとエクスプローラを立ち上げたところ、CDCによるデータの転送が止まってしまいました。再度ハイパーターミナルを立ち上げるも通信は回復しません。この状態でもエクスプローラからファイルの読み書きはできています。

残念ながら、今回の実装でも問題を解決するには至りませんでした。USB解析ツールのSnoopyProを使って取得したUSBパケットの流れは以下のとおりです。

赤丸が問題の箇所。

CDCのCommunication InterfaceのInterrupt IN Endpoint 0x81とData InterfaceのBulk IN Endpoint 0x82がMSDのBulk IN Endpoint 0x83と心中している様子が伺えます。0x83はその後回復するのですが、0x81と0x82はその後復調していませんでした。これはWindowsのドライバ側の問題であると思うのですが、物理的にプロトコルアナライザによる計測はしてはいない為、真実はわかりません。新たに出たHotfixも色々と試してみてはいるのですが、状況は改善しませんでした。そろそろWindows XP SP3の提供がはじまるそうなので、現在はそれに期待しております。

※その後、I/O拡張基板の動作確認がとれました。
※※さらにその後、ある方法でこの機能を実現することができました。