USB Mass Storage BOTデバッグ：CBW、CSW、Senseデータ、転送失敗

USB Mass Storageデバイスはユーザー側からは単純です。フラッシュドライブ、データロガー、ファームウェア更新デバイス、組み込みストレージガジェットを差し込むと、ディスクが出る。失敗すると、エラーはあいまいです。「device not ready」「I/O error」「format prompt」「mount failure」「消えるディスク」など。

その裏側で、多くのデバイスはBulk-Only Transport（BOT）を使っています。BOTには見分けやすいコマンドフローがあります。Command Block Wrapper（CBW）、データフェーズ、Command Status Wrapper（CSW）。このパターンが崩れたら、キャプチャでたいてい場所が分かります。

BOTフローを理解する

正常なパターンは次のとおり。

• ホストがCBWをバルクOUTで送る
• （任意の）データフェーズをバルクINまたはバルクOUTで
• デバイスがCSWをバルクINで送る

CBWはSCSIコマンドを運び、CSWはコマンドステータスを返します。コマンドが失敗した場合、ホストは REQUEST SENSE を発行して理由を知ることがあります。

有用な証拠：

• CBWシグネチャ
• コマンドタグ
• データ転送長
• 方向フラグ
• SCSIコマンドバイト
• データフェーズ長
• CSWシグネチャ
• CSWステータス
• residue
• 失敗後のSenseデータ

タグが一致しなければ、ホストはステータスを信用できません。データ長が挙動と噛み合わなければ、タイムアウトやストールに発展します。

Senseデータは多くの失敗を説明する

SCSIコマンドの失敗は診断の終点ではありません。Senseデータにはたいてい本当の原因が入っています。

• not ready
• medium error
• illegal request
• write protected
• logical block address out of range
• リセット後の unit attention

ファームウェアチームは、失敗したコマンドと続くSense応答をキャプチャすべきです。ホストのマウント失敗が、ファームウェア報告のストレージ状態への正しい反応であることもあります。

エンドポイントSTALLとリセット復旧

BOTには決められた復旧手順があります。エンドポイントがストールした／コマンドが酷く失敗した場合、ホストはエンドポイントHALTのクリアまたはマスストレージリセットを発行することがあります。正しく復旧できないデバイスは、消えたように見えたり、抜き差しが必要になったりします。

確認ポイント：

• どのエンドポイントがストールしたか
• ホストがClear Featureを送ったか
• BOTリセットが起きたか
• その後のCBW／CSWフローが再開したか
• タグが一貫したままであったか

ファームウェアのステートマシンに対する推測より、この証拠のほうがはるかに価値があります。

Bus Scopeが活きる場面

Bus ScopeはUSB検査の作業台です。マスストレージの場合、生バイトだけでは足りません。デコード済みのBOT構造と転送ステータスが、エンジニアの故障解析を加速します。

BOTデバッグ向けの良いBus Scopeレポートは次の問いに答えます。

• どのSCSIコマンドが失敗したか？
• データフェーズはCBWの方向と長さに一致していたか？
• CSWは届いたか？
• CSWタグはCBWタグと一致していたか？
• どんなSenseデータが続いたか？
• リセット復旧は機能したか？

「USB mass storage BOT failed」「CBW CSW mismatch」「USB flash drive I/O error firmware」といった検索クエリに対し、これが「ユーザー症状からバスの証拠」へ至る経路です。