# Incident: T00 USB image save transfer timeout

Status: complete
Result: contained; documented/no action
Type: incident
Updated: 2026-08-01
Next Action: none; preserve the unresolved T00 result as architecture evidence and retain the frozen Release baseline
Campaign: 003-complete-bounded-hpt-slow-export-firmware-ticket
Parent: work/maps/map-smi-firmware-stabilization-and-qualification.md
Related: work/checklists/checklist-additional-usb-drive-compatibility-sampling.md
Canonical Truth: docs/firmware-update-validation-and-recovery.md

## Impact

Additional compatibility specimen `T00_8GB` repeatedly failed the ordinary
controller image-save workflow on Controller B. The frozen Release baseline
has been restored. Rejected Debug-only diagnostic/recovery candidates did not
become production firmware. Chamber control, SD/HPT media, and controller
health remained available.

## Timeline

- Raspberry Pi intake: SanDisk Cruzer Blade serial
  `03025128041021125426`, FAT label `T00_8GB`, UUID `39EC-A5FE`; clean
  non-correcting FAT check and exact prepared WAV hashes.
- Controller B first insertion: configured high-speed mount, acceptance mask
  `15`, enumeration recovery count `0`, both WAV files visible, zero errors.
- WAV load: accepted and completed with zero errors.
- Image save: accepted; first capture showed 670 successful 1 KiB writes and
  685,312 requested bytes. A later capture showed 1,934 writes and 1,979,648
  bytes before terminal progress `900`.
- Terminal metrics: result `2`, raw status decimal `92` / `0x5C`, failure
  progress step `10`, failure percent `47`, one FileX-path error, two
  application-error increments, zero USBX system errors, and the device still
  attached/mounted.
- BOT telemetry identifies a successful 512-byte `WRITE(10)` data phase
  followed by a missing 13-byte CSW: semaphore status `13`, translated by
  USBX to `UX_TRANSFER_TIMEOUT`. The retry count and captured command context
  are retained in `work/evidence/t00-timeout-diagnosis-20260801.md`.
- Immediate BOT reset, delayed reset recovery, and a one-CSW retry candidate
  all failed on target. The last candidate retried the CSW once without
  replaying write data, then fail-closed on the second missing CSW.
- Read-only Pi inspection found the original published 8 MiB image intact,
  both WAV fixtures unchanged, a 673,024-byte `SMI_IMAGE.TMP`, differing FAT
  copies, and an incorrect free-cluster summary. No repair was performed.

## Exact HCD reproduction

T00 was re-prepared three times by verified serial with a fresh FAT32 `T00_8GB`
fixture containing only the two verified WAV files. The second exact-HCD
diagnostic run reproduced the normal image-save failure at 3,448 writes /
3,529,984 bytes. The 13-byte CSW wait followed a 512-byte data-in `READ(10)`.
At HCD abort entry, the request was still pending with zero received bytes;
Bulk IN pipe 1 (`0x81`) remained `PIDBUF`, and BRDY, NRDY, BEMP, and per-pipe
IRQ bits were clear. The drive remained attached and mounted.

## Cause

The controller receives raw USBX `UX_TRANSFER_TIMEOUT` (`0x5C`) after a
missing BOT CSW during normal traffic. The final captured command was
`READ(10)`, showing the fault is not write-data-only. The request remained
pending at HCD abort entry with no completion or transport error surfaced to
USBX. The event is below FileX and is not a valid SCSI/sense result. The
evidence rejects the tested generic reset/retry recovery candidates and does
not support a specimen-specific rule.

The official SSP 2.7.0 release note retains an HCD issue involving unexpected
host PING after ACK with no workaround. It is a plausible, but unproven,
explanation for a request that remains pending without an HCD completion. The
owner closed this investigation without a protocol trace, firmware correction,
or further target campaign; do not replace that missing classification with an
SSP migration or another firmware heuristic.

No USB protocol analyzer is currently available. The controller remains on its
frozen Release baseline; T00 is retained as contradictory evidence rather than
receiving a specimen-specific production exception.

## Recovery

Controller B is restored to the exact frozen Release image
`6907F88FB91D5DC58EBF15A918C3993FDE3A076AFAE9DAEFB099899F55932581`, with a
post-program capture confirming the expected SD identity, mounted USB session,
and zero system/application errors. T00 contains the failed diagnostic
workflow's partial image. It was then re-prepared again on the Raspberry Pi;
the final fixture is safely unmounted with only the verified WAV files and a
clean non-correcting filesystem check.

## Prevention

Reopen the standards-led USB architecture review only after the remaining
specimens establish breadth and this failure is independently classified.
Any correction must address the exact failing layer and generalize to unseen
standards-conforming devices; do not add model/serial-specific behavior.

## Follow-Up

- [x] Complete unchanged, unmounted Pi filesystem and content inspection.
- [x] Test the remaining owner-selected specimens under the same frozen path:
      T01_16GB, T02_8GB, and T03_32GB each passed end to end.
- [x] Compare this timeout with the earlier USB09 raw-`0x5C` evidence and the
      last broadly compatible image-save implementation before code selection.
- [x] Re-prepare T00_8GB, preserving its canonical label and fixture hashes,
      before another image-save run.
- [x] Capture HCD completion, pipe, and IRQ state at the first missing CSW.
- [x] Close the investigation as documented/no action; no Controller A
      cross-check or correction is selected without new wire-level evidence.
