# Spike: Version 5 FAT32 datalogging retirement and HPT media standardization

Status: complete; production-routing dispositions implemented
Type: spike
Updated: 2026-07-23
Next Action: none in this completed spike; any remaining service 467/468 or retired-service target verification is imported and coordinated by the ready srv-rpi00.local qualification app
Campaign Reason: Historical record from campaign 013-close-hpt-media-2-initial-release-qualification; retained independently after campaign closure and requires no separate owner-queue execution.
Campaign: standalone
Canonical Truth: docs/firmware-00-05-00-development-notes.md and docs/sd-card-operation-and-recovery.md

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Related Workpackage: work/wp/active/wp-triple-mirrored-circular-hpt-log-store.md

## Why this is a spike

The required surface inventory was completed on 2026-07-24 at
`work/inventories/inventory-version-5-fat32-to-hpt-transition-surfaces.md`.

The owner direction is settled: firmware version 5 will retire FAT32 as the
controller's SD-card datalogging system, and the HPT whole-card storage system
will become the standard. The remaining uncertainty is how to complete that
transition safely and consistently across startup, service operations, legacy
controls, field upgrades, graphing, export, qualification, and documentation.

This artifact records the required investigation and the provisional product
contract. It does not authorize source changes, card initialization, controller
programming, destructive testing, or edits to work currently in progress in
another session.

Although operators may call it the new "file system," HPT media 2.0 is a
product-owned whole-card raw storage format rather than FAT32/FileX. Final
requirements and service text should use language operators understand while
keeping that architectural distinction explicit for engineering.

## Owner direction to preserve

- Firmware `00.05.xx` and later must use HPT media as the standard SD-card
  datalogging system.
- FAT32/FileX datalogging is a version-4 compatibility surface and must not
  remain a parallel production logger in version 5.
- FAT32-oriented service actions, including SD format behavior, must be retired,
  replaced, or redefined for HPT media. They must not silently create a FAT32
  volume that version 5 will not use for logging.
- Installing version 5 on an older control with a legacy SD card must require an
  explicit card-preparation/initialization operation before logging can begin.
- Startup diagnostics and the power-on test must distinguish at least a missing
  card from a present card that is not prepared for the HPT system.
- Migration and initialization remain explicit and destructive. Version 5 must
  never automatically erase, convert, initialize, or reformat inserted media.
- Chamber control, monitoring, alarms, UI, USB firmware update, and
  communications must continue when media is missing, legacy-formatted,
  unsupported, corrupt, or unavailable.

## Provisional version-5 media-state contract

The power-on test and service UI should classify the inserted-card state before
offering an action. The final names and codes may change, but the states must
not collapse into one generic "SD error."

| Observed state | Required version-5 meaning | Required operator behavior |
| --- | --- | --- |
| No card detected | `MISSING` | Report logging unavailable; do not offer a misleading format failure |
| Card present and valid HPT media 2.x | `HPT_READY` | Open without formatting and resume/continue logging |
| Card present with recognized HPT media 1.0 | `HPT_LEGACY_REQUIRES_UPGRADE` | Preserve read-only classification; offer only an explicit supported upgrade/reinitialization path |
| Card present with mountable FAT32 | `FAT32_REQUIRES_HPT_INITIALIZATION` | Explain that the old datalogging format is no longer supported; require explicit destructive HPT preparation |
| Blank/uninitialized card with valid geometry | `BLANK_REQUIRES_HPT_INITIALIZATION` | Offer explicit HPT preparation after warnings and confirmation |
| Recognized unsupported future HPT version | `HPT_UNSUPPORTED` | Do not format automatically; report unsupported media version |
| Corrupt or ambiguous content | `CORRUPT_OR_UNKNOWN` | Do not guess or format automatically; preserve for diagnosis |
| Card present but transport/read probe fails | `MEDIA_IO_ERROR` | Report hardware/media I/O failure separately from formatting state |
| Card write-protected | `WRITE_PROTECTED` | Permit any safe read/diagnostic behavior; prohibit preparation and logging writes |
| HPT media readable but degraded | `HPT_DEGRADED` or `REPLACE_MEDIA` | Continue bounded operation where permitted and make replacement need visible |

Classification must be based on bounded, ordered probes with retained first
failure status. A FileX mount failure alone is not proof that a card is missing,
blank, corrupt, or suitable for HPT initialization.

## Legacy-control upgrade experience

When version 5 is installed on a control previously running FAT32 logging:

1. Boot must remain operational even when the old FAT32 card cannot be used for
   version-5 logging.
2. The UI must identify the card as present but requiring HPT initialization,
   not as missing.
3. The operator must be warned that HPT initialization erases the entire card
   and that any required FAT32 history must be exported or backed up first.
4. Initialization must require deliberate service access and at least two
   explicit confirmations of permanent data loss.
5. The controller must re-probe geometry and identity immediately before the
   destructive action so removal or card replacement cannot redirect consent
   to different media.
6. Preparation must write, reopen, and verify the HPT superblock/media identity
   and a commissioning record before reporting success.
7. Logging must remain disabled until the prepared media reopens as the exact
   supported HPT format.
8. Failure must retain the first HPT/SSP/media error and return to a classified
   non-ready state without pretending that initialization succeeded.

The spike must determine whether any legacy records require a supported
pre-upgrade export workflow. In-place FAT32-to-HPT conversion is not assumed
and must not be introduced merely to avoid explicit preparation.

## Service-code transition inventory

Every SD-related service code and UI entry must be classified as retain,
redesign, replace, or retire for version 5. At minimum investigate:

| Current surface | Version-4 purpose | Version-5 question |
| --- | --- | --- |
| Service 468 | HPT whole-card initialization/commissioning | Should this become the single standard Prepare SD Card action and production service entry? |
| Service 471 | FAT32 full-capacity format | Retire or redirect; it must not create a FAT32 datalogging volume in version 5 |
| Service 469 | FAT32 normal-log history/export fixture | Replace with HPT-range/export qualification or retire if no equivalent product need remains |
| Service 470 | FAT32 bounded background A/B endurance | Replace with HPT lane/wrap/retirement/endurance qualification; do not report legacy FileX coverage as HPT coverage |
| Service 472 | Destructive FAT32 accelerated evaluator | Replace with whole-card HPT qualification or retire after its evidence obligations are transferred |
| Service 474 | FAT32 production-log monitor | Redefine around HPT append/readback/gap/redundancy health or retire if native HPT diagnostics supersede it |
| Settings/UI Format SD Drive | FAT32 formatting action | Rename and redesign as Prepare/Initialize HPT Media with HPT-specific state, warnings, and verification |
| Graph/history reads | FileX FAT32 trees | Verify all customer history comes from HPT iteration across wrap and degraded records |
| USB log export | FileX FAT32 traversal | Keep USB destination semantics separate; source customer records from a bounded HPT snapshot and fail closed |

The audit must also search for service help text, strings, tests, scripts,
operator checklists, release notes, and manufacturing/service procedures that
still describe FAT32 formatting or FAT32 logging as the version-5 standard.

## Investigation questions

### Product and migration

- Is the supported field-upgrade policy "export first, then destructively
  initialize," or is preserving old FAT32 history outside the controller enough?
- Must version 5 offer read-only FAT32 export before initialization, or can that
  remain a version-4/service-tool responsibility?
- What exact version boundary disables FAT32 logging: all `00.05.xx` builds or
  only the production release after a transition build?
- Can downgrade to version 4 be supported after HPT initialization, and what
  warning or recovery procedure is required?

### State detection

- What bounded probe order reliably separates electrical absence, transport
  failure, blank media, FAT32, HPT 1.0, supported HPT 2.x, unsupported HPT, and
  corruption without writing to the card?
- Which detected states are safe to offer for initialization, and which require
  preservation/diagnosis instead?
- How are card removal and replacement detected between classification,
  confirmation, initialization, and verification?

### Service and UI contract

- Which service code becomes the one canonical HPT preparation action?
- Are old numeric codes retained with a clear "not available on version 5"
  result, redirected with explicit new text, or removed from dispatch?
- Which HPT diagnostics replace the intent of services 469, 470, 472, and 474?
- What user-facing terms best distinguish missing, needs preparation,
  unsupported, corrupt, I/O failure, degraded, and replace-media states?

### Architecture boundary

- Which FileX components remain required solely for USB media or firmware
  update, and how will SD-card FileX ownership be removed without breaking USB?
- How are exclusive raw SD ownership and any remaining FileX paths proven not
  to overlap?
- Which version-4 FAT32 code, configuration, buffers, service fixtures, and
  tests should be deleted, retained behind a version boundary, or archived?

## Required discovery output

The spike is complete when it produces:

1. A code/document inventory of every FAT32 SD dependency and affected service
   code, separated from USB-only FileX use.
2. An approved version-5 media-state machine and bounded read-only probe order.
3. A service-code disposition table naming the canonical HPT preparation path
   and the fate of 469/470/471/472/474 and Format SD Drive.
4. A field-upgrade flow for legacy FAT32 cards, including backup/export,
   destructive consent, identity recheck, verification, failure recovery, and
   downgrade implications.
5. Acceptance criteria for missing-card versus improperly prepared/legacy,
   unsupported, corrupt, write-protected, I/O-failing, degraded, and ready media.
6. A migration plan identifying which settled decisions belong in version-5
   product requirements, the HPT media contract, service documentation, an ADR,
   and the active implementation workpackage.

## Provisional acceptance requirements to validate

- [x] Version 5 never writes new production datalog records through FAT32/FileX.
- [x] A FAT32 card is reported as present but requiring HPT initialization.
- [x] A missing card is reported separately from every present-card failure or
  format state.
- [x] No boot, probe, logging, service, graph, or export path automatically
  formats or converts media.
- [x] Only CID-valid, sector-readable states expose destructive HPT preparation.
- [x] Preparation requires repeated consent, identity/geometry recheck,
  complete-media initialization, reopen, and commissioning-record verification.
- [ ] HPT ready, degraded, replace-media, unsupported, corrupt/unknown,
  write-protected, I/O-error, legacy HPT, legacy FAT32, blank, and missing states
  have unambiguous diagnostics and operator text.
- [x] Graphing and customer export read HPT history across wrap and surface gaps
  or degraded provenance; incomplete exports fail closed.
- [x] FAT32-specific service codes cannot create evidence that is incorrectly
  presented as HPT qualification.
- [x] Essential control functions remain independent of media readiness.
- [ ] Controller A and Controller B pass the final state/migration/service matrix
  using the identical frozen version-5 image.

## Boundaries for the current session

- Documentation only.
- Do not edit firmware, generated Synergy files, build outputs, service dispatch,
  GUI resources, or active qualification evidence.
- Do not initialize, format, remove, program, reset, or otherwise mutate a
  controller or SD card.
- Do not mark the active HPT workpackage complete from this spike.
- Coordinate later implementation with the session currently changing the
  version-5/HPT path; reconcile overlapping changes before editing shared files.

## Related artifacts

- `docs/firmware-00-05-00-development-notes.md`
- `docs/hpt-triple-circular-media-contract.md`
- `docs/sd-card-operation-and-recovery.md`
- `docs/sd-full-capacity-format-plan.md`
- `work/wp/active/wp-triple-mirrored-circular-hpt-log-store.md`
- `work/wp/completed/wp-hpt-embedded-log-store-v0-4-0-renesas-integration.md`
