# USB BOT CSW validation and Controller B smoke

Status: complete
Result: complete; historical isolated BOT candidate and Controller B smoke evidence
Type: evidence
Updated: 2026-08-01
Next Action: none; representative cross-device regression passed in work/evidence/usb-bot-representative-delta-regression-20260801.md
Campaign: 003-complete-bounded-hpt-slow-export-firmware-ticket
Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Workpackage: work/wp/completed/wp-restore-broad-usb-compatibility-baseline.md

## Result

PASS for the requested isolated change and brief normal-drive smoke. The active
SSP 2.6.1 Bulk-Only Transport path now accepts a CSW only when all of the
following are valid:

- actual transfer length is exactly 13 bytes;
- dCSWSignature is `0x53425355`;
- dCSWTag matches the current CBW tag;
- dCSWDataResidue does not exceed dCBWDataTransferLength; and
- bCSWStatus is Passed, Failed, or Phase Error.

A malformed CSW fails closed with `UX_ERROR` after BOT reset recovery. A valid
Failed status remains a SCSI command failure handled by REQUEST SENSE; it is not
misclassified as malformed transport.

The linked blocking BOT path already performed reset recovery in USB-IF order:
Mass Storage Reset, clear Bulk-In HALT, clear Bulk-Out HALT. No reset-order code
change was required. No VID/PID, serial, capacity, manufacturer, model, timing,
or specimen rule was added.

## Active-path verification

An initial inspection targeted USBX's standalone `transport_run` source. Clean
builds changed ELF debug information but left both S-record hashes unchanged,
proving that source was not linked into this firmware. The edit was removed
before deployment.

The linker map identifies `_ux_host_class_storage_transport_bo` as the active
transport at Release address `0x000152ac`. The correction was applied to
`ux_host_class_storage_transport_bo.c`; subsequent Debug and Release S-record
hashes changed, proving the target firmware contains the correction.

## Deterministic error-path coverage

Host models and source-policy checks cover:

- valid Passed -> success;
- valid Failed -> REQUEST SENSE;
- valid Phase Error -> reset recovery;
- short and oversized CSW lengths -> reset recovery;
- invalid signature -> reset recovery;
- mismatched tag -> reset recovery;
- residue greater than the CBW request -> reset recovery;
- invalid status -> reset recovery; and
- reset sequence -> Mass Storage Reset, Bulk-In clear, Bulk-Out clear.

These are deterministic host-model/static-path tests, not malformed USB packet
injection on the physical target.

## Frozen candidate

- Source commit: `ca6f573a`
- Debug ELF SHA-256:
  `770B36ECF22421AFB057832C8E2C72A4D597B0CF90FD35357F8958D50143BCCD`
- Debug S-record SHA-256:
  `5F110413B65068D50623592EC0B36B155952722E7B26FC46B525A19CE2536F6E`
- Release ELF SHA-256:
  `68AC029578BE8EDB7CD3F5B39254C8A4B5351A5E9161E87DDE7A1D2DC6ECF0A9`
- Release S-record SHA-256:
  `6907F88FB91D5DC58EBF15A918C3993FDE3A076AFAE9DAEFB099899F55932581`

Canonical managed Debug and Release rebuilds passed with only established
workspace warnings. The focused USB workflow, transaction inventory, export,
code-review, SD-CID, Python syntax, and 12/12 host-model tests passed.

## Controller B deployment and smoke

- Setup: Controller B
- Controller serial: `1751219`
- J-Link serial: `69660123`
- Hardware variant: `1`
- Full 4 MiB post-program readback SHA-256:
  `23428A890890CA40172483A683F2B985C5BFC640650E7B33B977EAD15DB754CA`
- USB specimen: `USB03_32G`

Post-program no-drive capture passed HPT-ready, zero-error, hardware, complete
SD identity, and representative-sector gates. USB03 then mounted on its first
insertion at high speed with a configured USBX device, acceptance mask `15`, a
valid FileX/application session, media generation `1`, and zero USBX,
application, or system errors. Enumeration recovery correctly remained unused.

WAV enumeration found `W00.WAV` and `W01.WAV`. The normal WAV load and Sound 1
playback commands were accepted. The final attached-state capture retained the
same valid mount/session and zero-error state. No VBUS action, remount sequence,
optional SCSI lifecycle, or drive-specific recovery was used.

## SD identity

- Protocol card status: `5`
- CID-valid status: `1`
- Representative-sector-read status: `1`
- Manufacturer: MID `0x03` (SanDisk)
- OEM/application ID: `SD`
- Product name: `SS08G`
- Product revision: `8.0`
- Serial number: `2540634245`
- Manufacturing date: `2024-05`
- Raw 128-bit CID: `035344535330384780976F0085018507`

Identity was captured after programming and again with USB03 attached.

## Independent USB03 Pi closeout

USB03 returned to the Pi as unmounted model `USB 2.0 FD`, serial
`071C49DE25C08808`, label `USB03_32G`, size 31,042,043,904 bytes. Read-only
`fsck.fat -n -v` reached the last filesystem sector, found 18 files using 635
of 1,893,380 clusters, and explicitly left the filesystem unchanged. Exit `1`
was solely the already documented Windows convention of storing the label in
the root directory while leaving the boot-sector label blank.

The two 7,574,016-byte FAT copies are byte-identical. Each SHA-256 is
`A03BB7CA83EFDBA71BF7120A5C9078E48A00442334935E4EE0AB434C0CE5B725`.
The current Pi insertion shows normal attach/capacity/cache reporting and no
USB or SCSI error.

The final no-drive target capture confirmed normal removal, cleared FileX
ownership, zero USBX/application/system errors, unchanged SD CID and
representative-sector validity, and no enumeration-recovery or VBUS action.
Controller B remains on the BOT candidate with no USB drive attached. Raw
target captures are retained under the ignored path
`work/evidence/hpt-log-store-circular-mirror/controller-b/usb-bot-csw-validation-smoke-20260801/`.
