# Spike: Diagnose T00 USB write timeout

Status: complete
Result: complete; documented/no action
Type: spike
Research Depth: deep
Updated: 2026-08-01
Next Action: none; retain the T00 missing-CSW result as unresolved architecture evidence and preserve 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/incidents/incident-t00-usb-image-save-transfer-timeout.md; work/spikes/spike-ingest-external-usb-host-compatibility-research.md
Disposition: documented
Produces:

## Question

Whether T00_8GB's image-save `UX_TRANSFER_TIMEOUT` arises in a general USBX,
Bulk-Only Transport, SCSI, HCD/DMA, FileX, or application lifecycle defect that
affects standards-conforming Mass Storage Class devices, or instead from a
device behavior outside the supported class contract.

## Timebox

One frozen-baseline reproduction; read-only source and prior-evidence audit;
then, only if the failure recurs without a visible lower-layer cause, one
diagnostic-only telemetry candidate. No production behavior change, VID/PID
rule, added normal-path retry, fixed delay, optional SCSI requirement, VBUS
cycle, or remount is in scope without a separately evidenced decision.

## Findings

- The original Controller B failure occurred during normal 1 KiB FileX writes:
  1,934 calls / 1,979,648 requested bytes, progress step 10 / 47%, raw `0x5C`
  (`UX_TRANSFER_TIMEOUT`), device still mounted, and no USBX system error.
- T01_16GB, T02_8GB, and T03_32GB passed the same ordinary workflow on the
  same hash-locked Controller B baseline. The issue is therefore neither a
  universal failure nor proof of a T00-specific exception.
- `saveUpdateImageToUSB` currently calls `imxWriteRegion`, which issues 1 KiB
  `fx_file_write` requests through FileX. Existing metrics identify the FileX
  boundary but do not record the active BOT command, CSW fields, or SCSI sense
  for a transport timeout.
- Existing `gUsbWriteSizeDiagnostic*` is a qualification-only profile with
  16/32/64/96 KiB writes. It is not production behavior and must be used only
  after normal-path reproduction has established the failing layer.
- T00's normal 1 KiB image save has now reproduced repeatedly on Controller B
  while T01, T02, and T03 remain passing representatives. BOT telemetry
  identifies the first lower event as a missing 13-byte CSW after a successful
  512-byte `WRITE(10)` data phase; the semaphore wait returns status `13`,
  which USBX translates to `UX_TRANSFER_TIMEOUT` (`0x5C`).
- Two general BOT recovery candidates were rejected on target: immediate
  reset-recovery (failure at 1,316 writes), reset plus an interval before
  halt clearing (536 writes), and one CSW-only retry followed by reset on a
  second missing CSW (660 writes). No candidate was promoted. The source
  retains diagnostic telemetry only; the controller has been restored to the
  frozen Release baseline.
- Read-only Pi inspection after the rejected candidates preserved the prior
  8 MiB published image and both WAV hashes, but found a 673,024-byte
  `SMI_IMAGE.TMP`, differing FAT copies, and an incorrect free-cluster
  summary. T00 is quarantined pending owner re-preparation.
- Three Pi re-preparations verified T00 by stable serial, created fresh FAT32
  `T00_8GB` volumes, copied only verified T02 WAV fixtures, and passed a
  non-correcting filesystem check. The second exact-HCD diagnostic run again
  failed normally at 3,448 1 KiB writes / 3,529,984 bytes. The final
  re-preparation left T00 safely unmounted on the Pi.
- At HCD abort entry, before the HCD changes pipe state, the failing 13-byte
  Bulk-IN CSW transfer for a 512-byte SCSI `READ(10)` was still pending with
  zero received bytes. Pipe 1 (`0x81`) was `PIDBUF`; no BRDY, NRDY, BEMP, or
  per-pipe IRQ bit was pending. The device remained attached and mounted.
  This records a missing completion at the Renesas HCD/USBX boundary, not a
  malformed CSW, sense result, FileX error origin, or timing policy decision.
- The official SSP 2.7.0 release note still lists HCD issue 13481 (unexpected
  host PING after ACK) with no workaround, despite USBX 6.4.0 integration.
  This is a plausible HCD-path hypothesis, not proof. Migration alone is not
  an evidence-backed correction; only a protocol trace can distinguish a
  missing device response from an HCD-lost completion.
- Internet research identifies the physical T00 model as a documented USB 2.0
  product, not an unusual protocol class. A U-Boot regression report describes
  the Cruzer Blade at VID:PID `0781:5567` as Mass Storage / SCSI Bulk-Only with
  512-byte bulk endpoints, then shows a later host release timing out during
  descriptor fetch after an earlier release had enumerated it. The author
  bisected that host-side regression to a generic descriptor-size change. This
  is relevant independent evidence that this device family can expose host
  implementation defects; it is a different failure phase and does not prove
  the current missing-CSW fault or authorize a device exception.
  Sources: [SanDisk data sheet](https://documents.sandisk.com/content/dam/asset-library/en_us/assets/public/sandisk/product/usb-flash/cruzer-blade-usb-2-0/data-sheet-cruzer-blade-usb-2-0.pdf);
  [U-Boot report](https://lists.denx.de/pipermail/u-boot/2018-May/329305.html).
- No vendor advisory, recall, model firmware update, or reproducible
  manufacturer-documented post-`READ(10)` missing-CSW issue was found for
  `SDCZ50-008G`. Reports of format, mounting, or unsafe-removal corruption are
  generic flash-media symptoms and do not identify the controller fault.
- A Pi `usbmon` software trace of the verified T00 completed 4,169
  `READ(10)` commands with matching successful CSWs, including repeated
  512-byte transfers to the same `0x81` Bulk-IN endpoint that was pending on
  Controller B. The Pi also accepted a valid non-success CSW for optional
  `MODE SENSE(10)` and continued. This confirms a standards-based reference
  host can complete the relevant command shape; it does not expose the
  controller wire event or select a controller correction.

## Recommendation

The repeated missing-CSW event is below FileX and is not corrected by the
tested BOT reset or status-retry policies. The exact HCD snapshot narrows the
remaining uncertainty to device-wire response versus HCD completion handling.
Capture the terminal Bulk-IN CSW phase on a USB protocol analyzer before
selecting another correction. Do not add another timing, retry, reset, SSP
migration, HCD patch, or specimen-specific production rule before that trace.
Any eventual correction must be general and regress the representative matrix.

No USB protocol analyzer is currently available. By owner decision, this spike
is closed without a firmware correction or further target campaign. Preserve the
frozen Release baseline and do not replace the missing trace with a retry,
delay, reset, SSP migration, HCD patch, or specimen-specific heuristic.

## Closeout

The investigation established a missing HCD-visible completion but cannot, in
the absence of an inline trace, classify it as a wire-level device
nonresponse or a lost HCD completion. No standards-based general correction
follows from the available evidence. T00 remains a contradictory specimen and
is not a production exception. Reopen this closed spike only if a materially
new source of wire-level evidence becomes available and the owner authorizes a
new, separately scoped investigation.

## Follow-Up

- [x] Compare current image-save metrics and source path with the preserved
      T00 failure and passing additional-drive matrix.
- [x] Capture fresh normal-path T00_8GB terminal results on Controller B.
- [x] Determine that the first non-successful lower-layer event is a missing
      BOT CSW after WRITE(10), not a valid SCSI failure or FileX-originated
      condition.
- [x] Add diagnostic-only generic command/transport telemetry without changing
      the normal production path.
- [x] Reject two unproven general BOT recovery candidates on target and restore
      the frozen Release baseline.
- [x] Re-prepare T00_8GB before further destructive image-save qualification.
- [x] Instrument and classify the HCD completion/pipe/IRQ boundary for the
      missing CSW before selecting another production correction.
- [x] Close the investigation as documented/no action; no evidence-backed
      general correction was selected.

## Continuation Handoff — 2026-08-01

### Current safe state

- Controller B is restored to frozen Release S-record SHA-256
  `6907F88FB91D5DC58EBF15A918C3993FDE3A076AFAE9DAEFB099899F55932581`;
  its restoration capture was healthy. Do not program a target merely to
  resume this investigation.
- T00 is the owner-labelled `T00_8GB`: SanDisk Cruzer Blade
  `SDCZ50-008G`, serial `03025128041021125426`, currently clean and unmounted
  on `srv-rpi00.local` as `/dev/sda1`. Its final fixture has only `W00.wav`
  and `W01.wav` with the hashes recorded in
  `work/evidence/t00-timeout-diagnosis-20260801.md`.
- No inline USB protocol analyzer is available. The Pi's `usbmon` software
  trace is available as a behavior reference but cannot expose a wire response
  lost by the Controller B HCD.

### Established facts to preserve

- T00 repeatedly fails the normal Controller B 1 KiB image-save workflow;
  the final observed failure was at 3,448 writes / 3,529,984 bytes. The
  terminal command was 512-byte data-in `READ(10)`, whose 13-byte Bulk-IN CSW
  remained pending with no HCD completion or error event.
- T01_16GB, T02_8GB, and T03_32GB passed the same normal workflow. This is an
  unresolved contradictory specimen, not evidence that all USB functionality
  is broken and not authorization for a T00 exception.
- Three generic BOT recovery candidates (immediate reset, delayed reset, and
  one CSW retry) failed and were removed. The production baseline contains no
  recovery change from those trials.
- The Pi trace confirms T00 at 480 Mb/s, VID:PID `0781:5567`, BOT endpoints
  `0x81`/`0x02`, and successful CSWs for every observed `READ(10)`, including
  512-byte reads. Its 9.310 ms maximum CSW latency rules out copying a large
  Linux-derived wait as a justified controller fix.

### Next-session guardrails

- Preserve broad Mass Storage compatibility: no VID/PID, manufacturer, model,
  serial, capacity, timing, or specimen-specific production behavior.
- Do not add a timeout, retry, reset, remount, VBUS cycle, optional-SCSI
  requirement, SSP migration, or HCD patch without a general, evidence-backed
  rationale and representative regression plan.
- If an inline analyzer becomes available, capture the last successful and
  failing Controller B Bulk-IN `READ(10)` CSW phase and correlate it with the
  HCD diagnostic registers. This distinguishes device nonresponse from an HCD
  lost completion.
- If the owner explicitly elects to continue without an analyzer, the only
  defensible firmware step is a separately scoped, diagnostic-only rolling
  BOT/HCD ledger (CBWs, CSWs, endpoint completion results, IRQ state, and
  timestamps). It is not a production fix and must not start a new target
  campaign without a fresh-handoff preflight.

### Start prompt for a new chat

```text
Continue the broad USB Mass Storage compatibility investigation in
E:\dev\high_point\7520553_SMI_FW. Read AGENTS.md, then
work/spikes/spike-diagnose-t00-usb-write-timeout.md and
work/evidence/t00-timeout-diagnosis-20260801.md before acting.

Preserve the frozen Controller B Release baseline. T00_8GB is a SanDisk Cruzer
Blade SDCZ50-008G that repeatedly reaches a missing Bulk-IN CSW after
READ(10); it is unresolved evidence, not a device-specific exception. The Pi
usbmon trace shows valid timely CSWs for the same 512-byte READ(10) shape, but
there is no inline USB protocol analyzer. Do not add retries, delays, resets,
SSP migration, HCD patches, or device rules without a standards-based,
general rationale and representative regression plan. First report the
highest-information next action and proceed only within these guardrails.
```

When the spike finishes, set `Disposition:` to `planned`, `documented`, `no-action`, or
`superseded`. A `planned` disposition must name the follow-up `work/*.md` artifact in `Produces:`.
