# USB session-recovery cross-check: USB03 and USB02

Status: complete
Type: evidence
Updated: 2026-08-01
Next Action: none; USB09 and the complete successor qualification sequence passed

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Workpackage: work/wp/completed/wp-restore-broad-usb-compatibility-baseline.md
Checklist: work/checklists/checklist-stage-1b-four-drive-usb-compatibility-baseline.md
Incident: work/incidents/incident-usb02-stage1b-post-open-session-failure.md

## Scope

The exact deployed recovery candidate was retained:

- Release S-record SHA-256:
  `0FE12FCE02C411378D1AF45EB11C1AC27694A5D69613830FD970865518C72B3F`.
- Controller A: `USB03_32G`.
- Controller B: `USB02_8G`.

The corrected candidate had already completed the full workflow with these
drives in the prior allocation, and the old Stage 1 candidate had completed a
full cross-controller round. This check therefore targeted fresh
cross-controller enumeration, FileX/application lifecycle publication, WAV
load/playback, and final live-session state without rewriting the drive
contents.

## First-insertion result

`USB02_8G` passed on Controller B immediately:

- mounted and physically attached;
- generation `2`, handoff acceptance mask `15`;
- application session state `2`, status `0`, valid `FX_MEDIA_ID`;
- zero pending storage, system errors, and USB application errors.

`USB03_32G` did not enumerate on Controller A on its first insertion. Two
captures approximately 55 seconds apart showed the same terminal boundary:

- electrical attachment present, but the port had not reached the configured
  device state (`DVSTCTR0=0x0200`);
- no new class/media generation; generation remained `1` from the prior
  session;
- mounted `0`, application state `5` (`DETACHED`), FileX pointer `0`, pending
  storage `0`;
- system errors `0`, USB application errors `0`.

This occurred below the application/FileX session correction because no fresh
USB storage class instance was published. It is recorded as a first-insertion
enumeration miss, not as a passing initial mount.

## One clean reseat

The checklist permits one clean powered USB removal/reinsertion after a proven
terminal request. The operator removed and reinserted only `USB03_32G` on
Controller A after a five-second interval. No controller power cycle, VBUS
diagnostic, per-drive delay, or identity rule was used.

After the reseat, Controller A reported:

- mounted `1`, attached `1`, configured device state;
- generation `2`, acceptance mask `15`;
- application session state `2`, status `0`, valid media ID and FileX pointer;
- zero pending storage, system errors, and USB application errors.

## Bounded workflow and controller/SD state

Both controllers enumerated `W00.WAV` and `W01.WAV`, accepted the WAV load,
accepted Sound 1 playback, and returned audio state `0`. Final captures
retained mounted state, generation `2`, acceptance mask `15`, application
state/status `2/0`, valid FileX pointers, and zero errors.

Controller A retained complete SD CID
`035344535330384780976F0084018559`; Controller B retained
`035344535330384780976F0085018507`. Both retained SD state `5`, CID-valid `1`,
representative-sector-read `1`, HPT state `5`, HPT status `0`, and
replace-media `0`.

## Disposition

The cross-controller lifecycle and read/playback smoke pass within the
checklist's one-reseat allowance. The USB03/A first-insertion enumeration miss
is a real reliability observation and remains visible in the evidence; it did
not exercise or contradict the application-session correction because USBX
never published a new storage instance on that attempt. No automatic power or
specimen-specific mitigation is authorized from this single occurrence.

USB09 incident regression remains the final Stage 1B recovery gate before a
decision on Stage 2.

## Raw evidence

- `work/evidence/hpt-log-store-circular-mirror/controller-a/usb-session-recovery-cross-usb03-20260731/`
- `work/evidence/hpt-log-store-circular-mirror/controller-b/usb-session-recovery-cross-usb02-20260731/`
