# Controller A A-2 USB 96 KiB Write-Size Qualification — 2026-07-28

Status: complete
Type: evidence
Updated: 2026-08-01
Next Action: none; the owner retained the qualified 32 KiB baseline and dispositioned 64/96 KiB pursuit as no action
Parent: work/wp/completed/wp-characterize-usb-filex-write-size-durability.md

## Identity and Build

- Controller A assembly/J-Link: `1751136 / 69664082`
- Controller SD raw CID:
  `035344535330384780976F0084018559`
- USB specimen: PNY A-2, serial `071C49DE246A1F97`
- FAT32 label/UUID: `A-CTRL-2 / EFA2-EFED`
- Four-size diagnostic S-record SHA-256:
  `F2FEA7E5457E854D104BB79BD9F263DCBCCEFBFDD0EA67154DA27EE26218F942`
- ELF SHA-256:
  `406360F059403A3688CE748424DDAC2CF2B1B3C9EB0A72E62A5FD3ABF0E330DE`
- map SHA-256:
  `6F7E622EEB9B63F714DF871A4919EFCA12FF7C5A41567E3C0F3D59245AE3D48A`
- Correct isolated managed e2 Debug build and all 23 repository check suites:
  passed.

The previous three-size diagnostic was captured before deployment as a full
4 MiB rollback image:

`work/evidence/hpt-log-store-circular-mirror/controller-a/usb-write-size-96k-diagnostic-20260728/rollback-pre-deploy/internal-flash.bin`

SHA-256:
`4E74BA19573BB993542B2760267F242CA03A6F3F00024983590A8F0F88CFB37B`

## Controller Results

| Tier | FileX limit | Exact bytes | Rows | Calls | File-write ticks | FileX status |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| 1 MiB | 16 KiB | 1,048,576 | 16,384 | 64 | 419 | 0 |
| 1 MiB | 32 KiB | 1,048,576 | 16,384 | 32 | 179 | 0 |
| 1 MiB | 64 KiB | 1,048,576 | 16,384 | 16 | 104 | 0 |
| 1 MiB | 96 KiB | 1,048,576 | 16,384 | 11 | 95 | 0 |
| 7 MiB | 16 KiB | 7,340,032 | 114,688 | 448 | 1,667 | 0 |
| 7 MiB | 32 KiB | 7,340,032 | 114,688 | 224 | 735 | 0 |
| 7 MiB | 64 KiB | 7,340,032 | 114,688 | 112 | 415 | 0 |
| 7 MiB | 96 KiB | 7,340,032 | 114,688 | 75 | 321 | 0 |

Every result was complete with successful close, flush, rename, and
controller first/last-row and exact-size verification.

At 7 MiB, 96 KiB used about 80.7% fewer file-write ticks than 16 KiB and
about 22.7% fewer than 64 KiB. The 1 MiB improvement over 64 KiB was only
about 8.7%, showing workload-dependent diminishing returns.

## Independent Pi Verification

- All four 1 MiB files were byte-for-byte identical:
  `6ab78b4dde26efd91a20aa003198a13d794b1cd7276f3cc05880f944f56966b3`
- All four 7 MiB files were byte-for-byte identical:
  `885418a583a8ebf3d9e0c0f0811ca821fb82ee99a25ef6573a0a49f01fc82b1d`
- Exact sizes and row counts matched the controller contract.
- Unmounted `fsck.vfat -n -v` passed after the 1 MiB and 7 MiB tiers.
- A-2 was safely unmounted at closeout.

## Independent Windows Verification

After the final Pi verification, Windows mounted the same PNY specimen as
`L:` with label/serial `A-CTRL-2 / EFA2-EFED`. Windows Storage reported:

- disk health/operation: `Healthy / Online`;
- volume health/operation: `Healthy / OK`;
- filesystem: FAT32;
- read-only `chkdsk`: file and folder verification complete, no problems
  found, no action required.

Windows opened every 1 MiB and 7 MiB output, read both 64-byte endpoints, and
reproduced the exact Pi SHA-256 values for all eight files. The mounted-volume
lock notice preceding `chkdsk` was not a media error; the read-only scan
continued and completed successfully.

## Disposition

The bounded 96 KiB FileX request is proven functional and physically
persistent for the clean A-2 specimen through the 1 MiB screen and 7 MiB
sustained tier. It is below the fixed 128 KiB BOT and SDRAM bounds but uses
75% of each, compared with 50% for 64 KiB and 25% for 32 KiB.

This single-specimen result does not reproduce the lifecycle, media diversity,
or removal/reboot conditions associated with prior unreliable large-write
observations. It therefore qualifies 96 KiB as a performance candidate, not
as the production cap. The conservative recommendation remains 32 KiB until
additional qualification explicitly trades margin for the measured gain.
