# T00 Missing-CSW Diagnosis Evidence

Status: complete
Result: complete; documented/no action
Type: evidence
Updated: 2026-08-01
Next Action: none; preserve this unresolved result without a production correction or further target campaign
Campaign: 003-complete-bounded-hpt-slow-export-firmware-ticket
Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Related: work/spikes/spike-diagnose-t00-usb-write-timeout.md; work/incidents/incident-t00-usb-image-save-transfer-timeout.md

## Target and specimen identity

- Controller B: J-Link `69660123`.
- SD CID: `035344535330384780976F0085018507`; protocol state `5`, CID valid,
  representative-sector read valid.
- T00: SanDisk Cruzer Blade 8 GB, physical model `SDCZ50-008G` (Made in
  Malaysia), serial `03025128041021125426`, FAT label `T00_8GB`, current UUID
  `8F43-ED42`, partition UUID `3bc73d8e-01`. The model is identified from the
  owner-provided specimen photograph in the linked Notion page; it is identity
  evidence only, not authorization for specimen-specific production behavior.
- Frozen Release restored after all candidate work:
  `6907F88FB91D5DC58EBF15A918C3993FDE3A076AFAE9DAEFB099899F55932581`.

## Observation

The normal image-save path uses 1 KiB FileX writes. The first recorded lower
failure is a missing 13-byte BOT CSW after a successful 512-byte SCSI
`WRITE(10)` data stage. `_ux_host_semaphore_get` returned status `13`; the
USBX transport maps that outcome to `UX_TRANSFER_TIMEOUT` (`0x5C`). No valid
CSW, SCSI sense status, USB disconnect, or controller system error was
observed at that boundary.

T01_16GB, T02_8GB, and T03_32GB previously passed the same normal workflow.
The T00 write-size diagnostic also passed its 32/64/96 KiB qualification-only
profiles, so neither result authorizes a production size exception.

## Rejected candidates

| Debug S-record SHA-256 | Candidate | On-target outcome |
|---|---|---|
| `9718A724EA6B980971CD6F023CE4F2BC5E0F9E66B6FE04CD3195AB529FF070AA` | Reset after transport semaphore timeout | Missing CSW persisted; image save failed at 1,316 writes. |
| `E9D22B6BB6FE22BB3D618346862E700DB5982CF9465EC29F1DC2229E4B4DECE2` | Reset with recovery interval before halt clearing | Missing CSW persisted; image save failed at 536 writes. |
| `581E3AF95D9192034EFFD3BED0BF3AF472CF9020552B9448C51B920EE1B26F7B` | One status-only CSW retry, then reset | Retry `0` and retry `1` both timed out; image save failed at 660 writes. |

All recovery changes were removed from source after the failures. Generic BOT
diagnostic telemetry remains available only for diagnosis.

## Re-prepared exact-abort reproduction

T00 was re-prepared three times on the Pi by verifying serial
`03025128041021125426` on `/dev/sda`, creating a fresh FAT32 volume labelled
`T00_8GB`, copying only `W00.wav` and `W01.wav` from the verified T02 fixture,
and running non-correcting `fsck.fat -n -v`. The final clean check reported
`3 files, 94/1900025 clusters`; the WAV SHA-256 values remained
`37a9dc665366f06d8081b23ecf88bdb30cf81546c3a10eda1be827de2d006b92` and
`e22fc8fff2cf68878c56ea87660ca2325e0fbf04cf091aaeb112a7f274b1b2f7`.

Controller B then ran Debug candidate
`E0827EF5615FC617C198B3D2D3A9E0129BC6747E39EC6A0937AAE46D87D96B49`, which
adds diagnostics only. Its baseline mounted T00 with the two WAV fixtures,
zero BOT failures, and zero HCD abort records. The normal 1 KiB image save
reproduced the terminal `FX`/USBX status `92` after 3,448 writes
(3,529,984 bytes, application progress 84%).

The terminal BOT event was a 13-byte CSW wait for a 512-byte, data-in SCSI
`READ(10)` (`0x28`), not a malformed CSW or sense result. The semaphore wait
returned `13`; transfer completion was still pending with zero bytes received.
The HCD snapshot was taken immediately on entry to abort, before it changes
the pipe: Bulk IN endpoint `0x81`, pipe `1`, `PIDBUF` (`pipe_control=1`), no
pending BRDY/NRDY/BEMP status bits, zero per-pipe IRQ bits, and unchanged
controller attachment/port state. Thus the HCD had not surfaced a completion
or a transport error to USBX at the timeout boundary. This rules out a
malformed-CSW correction and confirms that the previously rejected reset/retry
policies ran after the missing completion.

## Restored baseline

Controller B was restored after the exact-abort capture to the frozen Release
S-record `6907F88FB91D5DC58EBF15A918C3993FDE3A076AFAE9DAEFB099899F55932581`.
The post-program capture confirmed J-Link `69660123`, the expected SD CID and
healthy SD state, mounted T00, zero system/application errors, and idle USB
workflow flags. The diagnostic-only symbols are absent from this Release image.

After Release restoration, T00 was re-prepared one final time and left safely
unmounted on the Pi with UUID `8F43-ED42`, only the two verified WAV fixtures,
and the same clean non-correcting filesystem result.

## Raspberry Pi USB software-trace reference

With T00 still unmounted on `srv-rpi00.local`, Linux `usbmon` captured a
read-only `sg_dd` workload against the verified serial
`03025128041021125426`. The workload requested 4,096 raw 512-byte reads (2
MiB) using SCSI `READ(10)` and did not mount or write the filesystem.

- The Pi enumerated the same device as USB 2.10, high speed (480 Mb/s),
  VID:PID `0781:5567`, Mass Storage / SCSI / Bulk-Only, endpoint `0x81` IN and
  `0x02` OUT, each with a 512-byte maximum packet. This matches the endpoint
  shape active at the Controller B timeout.
- The 25,186-line trace contains 4,212 CBWs and 4,212 matching CSWs. All
  4,169 observed `READ(10)` commands, including the 512-byte shape involved in
  the controller failure, had a successful CSW; no READ(10) CSW was missing.
  CBW-to-CSW latency across those reads was 0.584 ms minimum, 0.745 ms median,
  0.887 ms p95, and 9.310 ms maximum.
- Linux also received a valid CSW status `1` for one optional `MODE SENSE(10)`
  request and continued with a `REQUEST SENSE` workflow. That is a valid
  unsupported-capability outcome, distinct from Controller B's missing CSW.

Raw trace and descriptor output are generated evidence under
`work/evidence/generated/t00-pi-usbmon-read-20260801/` (trace SHA-256
`375a14a97e644f1f6edf1e4e0abf1255e809b9422d0d0bf894093f0a9bdf8944`; descriptor
SHA-256 `236d4720373fddc5bc17c2199743a4fff99c9f0804755b69ba86a8fb53fc803e`).
The Pi trace verifies that T00 can satisfy the controller's endpoint and
single-block `READ(10)`/CSW contract under another standards-based host. It
does not reveal the controller's wire-level terminal transaction and does not
authorize importing Linux-specific scheduling or recovery behavior.

## Research disposition

The exact-abort result maps to an HCD completion-path question, not a BOT
command-policy or filesystem correction. The 2026-08-01 review of the
official SSP 2.7.0 release note confirms USBX 6.4.0 integration but retains
Renesas HCD issue 13481: an unexpected host PING after ACK, with no published
workaround, for all USBX Host MCUs. That issue is compatible with, but does
not prove, the observed pending Bulk-IN completion.

The next authorized experiment is one protocol-analyzer capture spanning the
last successful and the failing `READ(10)`/CSW transaction. It must show host
Bulk-IN token/PING behavior and device ACK/NAK/NYET/data response on endpoint
`0x81`, then correlate those wire events with the captured HCD registers. A
wire-visible device nonresponse and a wire-visible response lost by the HCD
require different general corrections. Do not migrate SSP, patch the HCD, add
a retry/delay, or create a drive rule before that distinction exists.

As of 2026-08-01, no USB protocol analyzer is available. The owner closed the
investigation as documented/no action rather than continue speculative
firmware or target work. This leaves wire-level classification unresolved; it
does not affect the frozen Release baseline, which remains the approved normal
controller firmware. T00 stays a contradictory specimen, not a production
exception. Reopen only with materially new wire-level evidence and separate
owner authorization.

## Pi read-only closeout

The final Pi check mounted `/dev/sda1` read-only and ran `fsck.fat -n -v`.
No repair, cleanup, or reformat was performed.

- `7520553_SMI_00_05_00.imx`: 8,388,864 bytes,
  SHA-256 `f6f40bb57434f0add72a55cd193465d30d5f81836def29ad29f63925802d85df`
  (the previously published Debug image remained intact).
- `W00.wav` and `W01.wav` retained their expected hashes.
- `SMI_IMAGE.TMP` remains at 673,024 bytes with SHA-256
  `e27f3b1c51e9e02b2c7359c0747da7d2972a0f989d93faa778be63f83c07e01e`.
- The non-correcting check reported differing FAT copies and a free-cluster
  summary mismatch; it left the filesystem unchanged.

T00 is quarantined pending owner re-preparation. Do not use its current media
state for further qualification or as evidence of a new production behavior.

## Raw evidence

Controller capture and programming logs are under
`work/evidence/hpt-log-store-circular-mirror/controller-b/t00-timeout-diagnosis-20260801/`,
`work/evidence/hpt-log-store-circular-mirror/controller-b/t00-hcd-capture-20260801/`,
and
`work/evidence/hpt-log-store-circular-mirror/controller-b/t00-hcd-abort-capture-20260801/`.
