USB Mass Storage BOT Debugging: CBW, CSW, Sense Data, and Failed Transfers
How to debug USB Mass Storage Bulk-Only Transport failures using command block wrappers, command status wrappers, and sense data.
USB Mass Storage devices look simple from the user side: plug in a flash drive, data logger, firmware update device, or embedded storage gadget, and a disk appears. When it fails, the error can be vague: device not ready, I/O error, format prompt, mount failure, or disappearing disk.
Underneath, many devices use Bulk-Only Transport. BOT has a recognizable command flow: Command Block Wrapper, data phase, Command Status Wrapper. If that pattern breaks, the capture can usually show where.
Understand the BOT Flow
The normal pattern is:
- host sends CBW over bulk OUT
- optional data phase over bulk IN or OUT
- device sends CSW over bulk IN
The CBW carries a SCSI command. The CSW reports command status. If the command fails, the host may issue REQUEST SENSE to learn why.
Useful evidence:
- CBW signature
- command tag
- data transfer length
- direction flag
- SCSI command bytes
- data phase length
- CSW signature
- CSW status
- residue
- sense data after failure
If the tags do not match, the host cannot trust the status. If the data length does not match behavior, timeouts or stalls can follow.
Sense Data Explains Many Failures
A failed SCSI command is not the end of the diagnosis. Sense data often gives the real reason:
- not ready
- medium error
- illegal request
- write protected
- logical block address out of range
- unit attention after reset
Firmware teams should capture the command that failed and the sense response that followed. A host mount failure may be a valid response to a firmware-reported storage condition.
Endpoint STALL and Reset Recovery
BOT has defined recovery behavior. If an endpoint stalls or a command fails badly, the host may clear endpoint halt or issue mass storage reset. A device that does not recover correctly can appear to disappear or require unplugging.
Inspect:
- which endpoint stalled
- whether host sent clear feature
- whether BOT reset occurred
- whether subsequent CBW/CSW flow resumed
- whether tags remained consistent
This evidence is better than guessing at firmware state machines.
Where BusScope Fits
BusScope is a USB inspection workbench. For mass storage cases, raw bytes alone are not enough; decoded BOT structure and transfer status help engineers find the fault faster.
A useful BusScope report for BOT debugging should answer:
- which SCSI command failed?
- did the data phase match CBW direction and length?
- did CSW arrive?
- did CSW tag match CBW tag?
- what sense data followed?
- did reset recovery work?
For search queries like "USB mass storage BOT failed," "CBW CSW mismatch," or "USB flash drive I/O error firmware," this is the path from user symptom to bus evidence.