USBデバイス列挙失敗：ファームウェアエンジニアが最初に確保すべき証拠
USBデバイスが認識されない、列挙に失敗する、ディスクリプタ交渉中に消えるといった症状を診断する実践ガイド。Bus Scopeで「USBドライバが認識されない」「WindowsがUSBを認識しない」「PCがUSBを認識しない」に向き合います。
USBデバイスが認識されないとき、最初に問うべきは「どのUIボタンを押すべきか」ではありません。意味のある問いは、「列挙はどこまで進んで、どこで止まったことをどんな証拠が示しているか」です。
USB列挙は、ホストとデバイスとの「構造化された会話」です。ホストはポートをリセットし、ディスクリプタを要求し、アドレスを割り当て、コンフィギュレーションを選び、クラスとインターフェースの証拠に基づいてドライバをロードします。ファームウェアの問題、ディスクリプタの不一致、タイミング問題、ケーブル問題、ドライババインド問題がすべて、ユーザーの目には「デバイスが見えない」という同じ症状として現れます。
列挙タイムラインを最初に見る
良いUSBキャプチャは次を映し出します。
- デバイスのアタッチ／ポートリセット
- Setupパケット
GET_DESCRIPTORリクエスト- デバイスディスクリプタの応答
- アドレス割り当て
- コンフィギュレーションディスクリプタのリクエスト
- 文字列ディスクリプタのリクエスト（存在する場合）
SET_CONFIGURATION- コンフィギュレーション後のクラス固有リクエスト
デバイスディスクリプタ手前で止まるなら、電気・タイミング・ハブ・ケーブル・低レベル準備の問題かもしれません。コンフィギュレーション解析で止まるなら、ディスクリプタ長・エンドポイント定義・インターフェースクラス・トータル長フィールドを確認します。列挙は成功したのにアプリが失敗するなら、クラスプロトコル・エンドポイント挙動・ドライバ期待値が疑わしい。
ディスクリプタの証拠は推測に勝る
ファームウェアチームは「何を公開するつもりだったか」を知っています。HID、CDC、マスストレージ、ベンダー固有エンドポイント、複合レイアウト。しかしホストはディスクリプタしか見えません。ディスクリプタに矛盾があれば、ファームウェアロジックが他では正しくても、ホストはデバイスを拒否します。
重要なフィールド：
- Vendor ID、Product ID
- デバイスのclass、subclass、protocol
- コンフィギュレーションのトータル長
- インターフェース数
- エンドポイントのアドレスと方向
- エンドポイントの転送種別
- 最大パケットサイズ
- HIDレポートディスクリプタの有無
- CDC Functional Descriptor
小さなディスクリプタミスが大きな症状を生みます。トータル長の不一致やエンドポイントの欠落は、デバイス全体を見かけ上「壊れた」状態にします。
ドライバ追加の前にキャプチャする
ドライバのインストールは挙動を変える可能性があるうえ、元の失敗を覆い隠すこともあります。診断のためには、まず最初のクリーンな列挙試行をキャプチャしましょう。必要ならその後、ドライバ変更後の挙動をキャプチャし、比較します。
実用的なサポートワークフロー：
- アタッチと列挙をキャプチャ
- 最後に成功したホストリクエストを特定
- 失敗箇所の周辺のディスクリプタフィールドを観察
- 想定USBクラスと突き合わせる
- ファームウェア／ドライバ変更後に再試行
こうすれば、最終的なアプリエラーだけをデバッグする罠を避けられます。
LinuxとWindowsでキャプチャ経路が異なる
Linuxでは usbmon がカーネルレベルのUSBトラフィック証拠を提供します。WindowsではUSBPcapが一般的なキャプチャドライバ経路です。運用のセットアップは同一ではありませんが、エンジニアリング上のゴールは同じです。リクエスト、応答、エンドポイント、方向、クラスの証拠を保全すること。
両プラットフォームを併用するチームの場合、レポートにはキャプチャ元を明記しておきましょう。Linuxでは列挙できるがWindowsで失敗するなら、ドライババインドの問題かもしれません。ディスクリプタ取得以前の両プラットフォーム共通失敗なら、ファームウェア／ケーブル／ハブ／電気タイミングの可能性が高いです。
Bus Scopeが活きる場面
Bus Scopeは「広範なプロトコル対応」よりも「USBの証拠」に重心を置いています。転送・ディスクリプタ・エンドポイント・クラス観察を密集した作業台で確認できるため、ファームウェア／ハードウェアチームの助けになります。ゴールはあらゆるベンダアナライザを置換することではありません。日々のUSB証拠をキャプチャ・確認・保存・引き継ぎしやすくすることです。
列挙失敗に関するかぎり、価値ある成果物は「明確な境界線」です。
- ホストはここまでリクエストを出した
- デバイスはここまで応答した
- 列挙はここで止まった
- ディスクリプタ証拠はこのミスマッチを示唆している
- 次のアクションはファームウェア／ドライバ／ケーブル／ハブ／ホストポリシーのどれに属する
これが「USB device not recognized」をエンジニアリング案件に変換します。