# Spike: Explore USB drive workflow compatibility across controllers A and B

Status: complete
Type: spike
Updated: 2026-08-01
Next Action: none; the successor ticket and standards-led broad-baseline work are complete
Parent: work/maps/map-smi-firmware-stabilization-and-qualification.md
Disposition: planned
Produces: work/tickets/ticket-investigate-usb-drive-enumeration-and-post-save-workflow-compatibility.md

## Question

Do four varied, readily available FAT32 USB specimens complete every current
customer USB workflow on both Controller A and Controller B, and does each
controller-visible success remain intact under independent read-only Pi
inspection?

This is exploratory characterization, not USB-drive qualification. Four
specimens and eight controller/drive observations cannot establish model,
brand, capacity, population, lifecycle, release, or supplier qualification.
Record `observed pass`, `observed fail`, or `inconclusive` for each case. Do
not publish an approved-drive list from this spike.

## Timebox

One four-round bench session plus bounded evidence reconciliation. Stop after
the eight planned controller/drive combinations and their Pi checks. A failure
may receive one clean reinsertion/retry only when the request-specific status
shows that the first request terminated; do not expand into debugging,
firmware changes, repair, reformatting, endurance, electrical qualification,
or SSP/HCD work without a new decision.

## Specimens

| USB label | Nominal size | Starting layout | Starting content |
| --- | ---: | --- | --- |
| `USB05_4G` | 4 GB | single MBR/FAT32 volume | verified `W00.wav`, `W01.wav` |
| `USB06_1G` | 1 GB | FAT32 superfloppy; relabeled only | verified `W00.wav`, `W01.wav` |
| `USB07_32G` | 32 GB | single MBR/FAT32 volume | verified `W00.wav`, `W01.wav` |
| `USB08_8G` | 8 GB | single MBR/FAT32 volume | verified `W00.wav`, `W01.wav` |

All four passed a non-repairing FAT check after preparation. Reconfirm label,
filesystem, free space, WAV hashes, and unmounted state immediately before
execution.

## Parallel Matrix

| Round | Controller A | Controller B | Pi validation |
| --- | --- | --- | --- |
| 1 | `USB05_4G` | `USB06_1G` | validate both after removal |
| 2 | `USB06_1G` | `USB05_4G` | validate both after removal |
| 3 | `USB07_32G` | `USB08_8G` | validate both after removal |
| 4 | `USB08_8G` | `USB07_32G` | validate both after removal |

This covers all eight drive/controller combinations in four paired rounds.
Run controller automation concurrently through the two serial-bound J-Link
paths, but keep both cases at the same workflow stage so operator movement and
evidence attribution remain clear.

## Customer-Use Lifecycle

USB media is removable while the controller is powered. Do not power down for
ordinary USB insertion or removal:

1. Keep both controllers powered and in their known safe operating state.
2. Insert the round's USB drive into each controller.
3. Require fresh enumeration, a valid FileX media session, and adequate free
   space before the first operation.
4. Run the complete workflow bundle.
5. Require request-specific terminal state and removal-ready completion.
6. Remove the USB drive while the controller remains powered.
7. Attach both drives to the Pi and validate them read-only in parallel.
8. Unmount both drives before the next physical move.

Controller power cycling or reset is allowed only where the workflow itself
requires reboot/persistence proof. The powered-removal prohibition applies to
internal SD cards, which are out of scope and must not be moved.

## Workflow Bundle

For each controller/drive combination:

1. Capture controller identity, running-image identity, SD CID/status, USB
   label/session baseline, free space, and pre-existing USB files.
2. Load `W00.wav`, verify validation/programming status, and play it.
3. Load `W01.wav`, verify validation/programming status, and play it.
4. Reboot only as required to prove selected-audio persistence; verify normal
   control recovery and unchanged SD CID.
5. Save the current firmware image to USB and verify terminal status and exact
   expected size.
6. Perform the established self-update round trip using the pinned current
   image; verify programmed flash against the expected image and restore the
   intended audio state.
7. Capture the PID file and verify its expected content.
8. Export retained HPT data and record selected/published records, gaps,
   FileX write count/bytes/maximum, HPT status, USB status, terminal phase, and
   timing.
9. Require the controller's removal-ready state before physical removal.

Do not treat shared progress state as terminal authority. Every operation must
be attributed to its own request and current USB session.

## Pi Validation

After each paired round:

- identify both specimens by USB label and stable hardware identity;
- keep them unmounted except for a temporary read-only mount;
- run non-repairing FAT checks and record clean, dirty, divergent-FAT,
  orphan/lost-chain, or summary findings exactly;
- verify expected filenames, exact sizes, hashes, and absence of unexpected
  temporary files;
- verify `W00.wav` and `W01.wav` hashes;
- verify firmware-image and PID outputs against controller-specific expected
  values;
- verify the HPT CSV `COMPLETE` trailer and published record count;
- unmount both drives and confirm no mountpoints remain.

Archive compact results by round and controller. If fixed-name outputs must be
removed before the specimen's second controller, first copy and hash them in
the ignored generated-evidence area, then restore the drive to the documented
input-only baseline. That cleanup is part of later execution authorization;
the plan itself changes no media.

## Concurrency Controls

- Bind every J-Link command to the known Controller A or B serial number.
- Use distinct controller/round evidence directories and output names wherever
  firmware permits.
- Never let one controller's completion satisfy the other controller's poll.
- Do not share a writable Pi mount between concurrent validators.
- Stop both sides of the round if physical drive identity becomes ambiguous;
  one controller's functional failure alone does not require stopping the
  other safe case.
- Preserve controller-specific SD CID capture at baseline and after any reboot.

## Stop Conditions

- Unexpected USB label, serial, filesystem, partition layout, or mount state.
- Running firmware identity differs from the accepted 32 KiB candidate or the
  two controllers do not have a reviewed equivalent baseline.
- USB drive lacks required free space.
- Stale request/session state, ambiguous terminal result, or controller
  responsiveness loss.
- Any USB filesystem corruption, missing durable output, unexpected temporary
  file, FAT divergence, or host read error.
- Any proposal to remove or insert an internal SD card while powered.
- Any need to repair/reformat media, alter firmware, patch middleware, or
  exceed the one bounded retry.

## Findings

- Round 1 began on 2026-07-29 with the accepted 32 KiB Debug image and matching
  A/B SD CIDs.
- Controller B did not mount `USB06_1G` on initial insertion or the one
  permitted powered reinsertion. Controller and SD status remained healthy;
  classify B/`USB06_1G` as an observed enumeration failure.
- Controller A mounted `USB05_4G`, enumerated both WAVs, and completed WAV
  load/playback with zero system errors.
- A/`USB05_4G` image save wrote the exact 8,388,864-byte image in 257 calls
  capped at 32 KiB, but the test operator was incorrectly directed to remove
  the drive while IMX and durability telemetry still reported in-progress.
  Classify the case as inconclusive, not a drive failure.
- Pi inspection found `USB05_4G` FAT clean and the full-size image readable
  with SHA-256
  `F471A5E4A0FB86BC408883458F9532C22EF3278E1DE7B2D97707060241A656DA`.
  The file was archived under the Pi backup tree and the drive was restored to
  its clean input-only baseline. `USB06_1G` also remained FAT-clean with both
  WAV hashes intact.
- In round 2, Controller A did not mount `USB06_1G` on initial insertion or
  the one permitted powered reinsertion. Together with round 1, classify
  `USB06_1G` as an observed enumeration failure on both controllers and stop
  further controller testing of that specimen.
- Controller B mounted `USB05_4G`. WAV load/playback, the exact
  8,388,864-byte image save, and the 225-byte PID capture completed with
  request-specific durable verification and zero system errors.
- The B/`USB05_4G` self-update was inconclusive because the update selector
  did not expose the newly saved image before the bounded reseat; no update
  was forced or retried.
- The B/`USB05_4G` retained HPT scan completed across 5,631 selected records
  with no range gaps, but USB publication terminated with USB status 17 and
  no CSV was published. Classify the HPT-export workflow as an observed
  failure for this case.
- Round 2 Pi inspection found both filesystems clean and both WAV pairs
  unchanged. `USB05_4G` contained the exact image and PID output, but no HPT
  CSV, consistent with controller telemetry. The image and PID file were
  archived under
  `/home/jong/usb-backups/20260729/exploratory-round2/USB05_4G/`, then removed
  from the specimen; a final non-repairing FAT check passed and both specimens
  were left unmounted.
- In round 3, Controller B did not mount `USB08_8G` on initial insertion or
  the one permitted powered reseat. Classify B/`USB08_8G` as an observed
  enumeration failure and stop that case.
- Controller A mounted `USB07_32G`. WAV load/playback, the exact
  8,388,864-byte image save, and the 225-byte PID capture completed with
  request-specific durable verification and zero system errors. The image
  selector did not expose the newly saved image, so self-update remained
  inconclusive and was not forced.
- A/`USB07_32G` HPT export scanned 5,662 records, selected and published 5,661
  records with no gaps, and wrote the 284,885-byte `R3A07.csv` in nine calls
  capped at 32 KiB. The CSV ended with the matching `COMPLETE` trailer.
- Round 3 Pi inspection found both filesystems clean and both WAV pairs
  unchanged. `USB07_32G` contained the expected image, PID, and complete HPT
  CSV; all three outputs were archived under
  `/home/jong/usb-backups/20260729/exploratory-round3/USB07_32G/`, then removed
  from the specimen. A final non-repairing FAT check passed and both specimens
  were left unmounted.
- In round 4, Controller A did not mount `USB08_8G` on initial insertion or
  the one permitted powered reseat. Together with round 3, classify
  `USB08_8G` as an observed enumeration failure on both controllers and stop
  further controller testing of that specimen.
- Controller B mounted `USB07_32G`. WAV load/playback, the exact
  8,388,864-byte image save, and the 225-byte PID capture completed with
  request-specific durable verification and zero system errors. The image
  selector again did not expose the newly saved image, so self-update remained
  inconclusive and was not forced.
- B/`USB07_32G` HPT export scanned 5,670 records, selected and published 5,665
  records with no requested-range gaps, and wrote the 284,978-byte
  `R4B07.csv` in nine calls capped at 32 KiB. The CSV ended with the matching
  `COMPLETE` trailer.
- Round 4 Pi inspection found both filesystems clean and both WAV pairs
  unchanged. `USB07_32G` contained the expected image, PID, and complete HPT
  CSV; all three outputs were archived under
  `/home/jong/usb-backups/20260729/exploratory-round4/USB07_32G/`, then removed
  from the specimen. A final non-repairing FAT check passed and both specimens
  were left unmounted.
- The clean Controller A/`USB05_4G` repeat mounted and passed WAV load/playback
  and exact 8,388,864-byte image-save durability. Two accepted PID triggers
  never changed the request-specific operation from the prior image save and
  produced no PID file; classify PID as inconclusive. The saved image was not
  exposed by the update selector, so self-update was also inconclusive.
- The repeat A/`USB05_4G` HPT scan completed with 5,700 selected records and
  no requested-range gaps, but publication terminated at USB phase 1 with
  status 17 and produced no CSV. Pi inspection matched that telemetry, found
  the filesystem clean and WAVs unchanged, and verified the exact image hash.
  The image was archived under
  `/home/jong/usb-backups/20260729/exploratory-repeat/USB05_4G/`, removed from
  the specimen, and the clean baseline was restored.

## Final Matrix

| USB label | Controller A | Controller B | Exploratory interpretation |
| --- | --- | --- | --- |
| `USB05_4G` | enumerated; WAV/image pass; PID and update inconclusive; HPT status-17 failure | enumerated; WAV/image/PID pass; update inconclusive; HPT status-17 failure | compatible enough for several workflows, but not a full-workflow pass |
| `USB06_1G` | enumeration failure | enumeration failure | owner-dispositioned as incompatible with this controller platform; no further attempts |
| `USB07_32G` | WAV/image/PID/HPT pass; update inconclusive | WAV/image/PID/HPT pass; update inconclusive | strongest specimen, but not qualified and not a complete full-workflow pass |
| `USB08_8G` | enumeration failure | mounted after focused MBR-classification correction | compatible; original failure was a firmware MBR/FAT misclassification |

No specimen achieved an observed pass across every planned workflow because
self-update remained inconclusive in every enumerated case. This spike does
not establish an approved-drive list.

On 2026-07-29, after additional guarded VBUS, host-port telemetry,
full-speed, and bounded reset diagnosis showed persistent pre-attach SE1, the
owner accepted the reasonable-effort result and dispositioned `USB06_1G` as
incompatible with this controller platform. Do not retry that specimen. This
does not establish a model-family exclusion or approved-drive list.

## Recommendation

Investigate the repeatable enumeration and HPT-publication failure classes in
the produced ticket. Retain `USB07_32G` as the strongest exploratory specimen,
but do not call it qualified or publish an approved-drive list. Defer broader
drive qualification until the update-list behavior has an attributable
terminal test and the compatibility defects are understood.

### USB08_8G follow-up resolution — 2026-07-29

Focused Controller B telemetry isolated the original `USB08_8G` failure to
USBX media classification, not USB enumeration or SCSI transport. Its MBR
bootstrap starts `EB 63 90`, which the legacy jump-only heuristic treated as a
FAT VBR. FileX then decoded bootstrap bytes `90 90` as a 37,008-byte logical
sector and returned `FX_BUFFER_ERROR`. Requiring valid FAT BPB
bytes-per-sector or the exact exFAT OEM signature before treating sector zero
as a direct filesystem corrected the path. Controller B then mounted the
existing unmodified media and listed `W00.wav` and `W01.wav`.

## Follow-Up

- [x] Confirm exact running-image and rollback identities on both controllers.
- [x] Reconfirm all four starting media baselines.
- [x] Execute rounds 1 through 4 with paired controller and Pi evidence.
- [x] Classify every controller/drive case as observed pass, observed fail, or
  inconclusive.
- [x] Record whether broader qualification, a focused defect ticket, or no
  action is warranted.

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:`.
