Depuración USB Mass Storage BOT: CBW, CSW, sense data y transferencias fallidas

Los dispositivos USB Mass Storage parecen simples para el usuario: "enchufas un pendrive, un data logger, un dispositivo de actualización de firmware o un gadget de almacenamiento embebido, y aparece un disco. Cuando falla, el error puede ser vago: device not ready, I/O error, prompt de formateo, fallo de mount o disco que desaparece." Por debajo, muchos dispositivos usan Bulk-Only Transport. BOT tiene un flujo reconocible: "Command Block Wrapper, fase de datos, Command Status Wrapper. Si ese patrón se rompe, la captura suele enseñar dónde."

Entiende el flujo BOT

El patrón normal es:

• El host manda CBW por bulk OUT.
• Fase opcional de datos por bulk IN o OUT.
• El dispositivo manda CSW por bulk IN.

El CBW lleva un comando SCSI. El CSW reporta el estado del comando. Si el comando falla, el host puede emitir REQUEST SENSE para saber por qué.

Evidencia útil:

• Signature del CBW.
• Command tag.
• Data transfer length.
• Flag de dirección.
• Bytes del comando SCSI.
• Longitud de la fase de datos.
• Signature del CSW.
• Status del CSW.
• Residue.
• Sense data tras un fallo.

Si los tags no coinciden, el host no puede fiarse del status. Si la longitud de datos no coincide con el comportamiento, pueden aparecer timeouts o stalls.

Sense data explica muchos fallos

Un comando SCSI fallido no es el final del diagnóstico. El sense data suele dar la razón real:

• Not ready.
• Medium error.
• Illegal request.
• Write protected.
• Logical block address fuera de rango.
• Unit attention tras un reset.

Los equipos de firmware deberían capturar el comando que falló y la respuesta de sense que siguió. Un fallo de mount del host puede ser una respuesta válida a una condición de almacenamiento reportada por el firmware.

STALL en endpoint y recuperación por reset

BOT tiene un comportamiento de recuperación definido. Si un endpoint hace STALL o un comando falla de forma grave, el host puede limpiar el halt del endpoint o emitir un mass storage reset. Un dispositivo que no se recupera correctamente puede parecer que desaparece o requerir desconexión.

Inspecciona:

• Qué endpoint hizo STALL.
• Si el host mandó clear feature.
• Si ocurrió un BOT reset.
• Si el flujo CBW/CSW posterior se reanudó.
• Si los tags siguieron siendo consistentes.

Esta evidencia es mejor que adivinar el state machine del firmware.

Dónde encaja Bus Scope

Bus Scope es un banco de trabajo de inspección USB. Para casos de mass storage, los bytes en crudo no bastan; una estructura BOT decodificada y el estado de la transferencia ayudan a los ingenieros a encontrar el fallo antes.

Un informe útil de Bus Scope para depuración BOT debería responder:

• ¿Qué comando SCSI falló?
• ¿La fase de datos encajó con la dirección y longitud del CBW?
• ¿Llegó el CSW?
• ¿El tag del CSW coincidió con el del CBW?
• ¿Qué sense data llegó después?
• ¿La recuperación por reset funcionó?

Para búsquedas como "USB mass storage BOT failed", "CBW CSW mismatch" o "USB flash drive I/O error firmware", este es el camino del síntoma de usuario a la evidencia del bus.