# HPT Embedded Log Store v0.4.0 Renesas integration Workpackage

Status: complete
Type: workpackage
Updated: 2026-07-24
Next Action: none

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md

## Current Context

The 7520553 SMI firmware targets controller assemblies 1751136 and 1751219 on
Renesas S7G2 part R7FS7G27H3A01CFC. The qualified Windows build is e2 studio
2024-01.1 with SSP 2.6.1 and GCC Arm Embedded 10.3.1. Runtime services are
ThreadX, FileX, USBX, and GuiX.

The application-owned SD thread (`src/Thread_SdCard_entry.c`) owns removable
media lifecycle and uses FileX `g_fx_media_sd` over `g_sf_el_fx` and
`g_sf_block_media_sdmmc`. The generated SD thread is priority 14 with a
4096-byte stack. The block-media configuration uses 512-byte blocks. Existing
SD changes and evidence are active and must be preserved.

Generated boundaries are `configuration.xml`, `synergy_cfg*`, and
`src/synergy_gen/**`. No regeneration is authorized for this workpackage.

## Recommendation

Vendor a verified immutable subset of upstream v0.4.0 under
`src/vendor/hpt_embedded_log_store/`. Keep the Renesas adapter product-owned in
`src/HptLogStoreRenesas.[ch]`, single-owner under the SD thread, heap-free, and
explicit about geometry, bounds, alignment, timeouts, removal, write protection,
I/O failure, and durability. Keep UI, scheduling, export policy, service codes,
and alarms outside the portable core. Do not import upstream Linux/Pi adapters,
tools, tests, media images, or build products.

## Current State

Completed:

- Repository/toolchain/storage/generated-boundary reconnaissance.
- Proposed vendoring and adapter boundaries recorded.
- Release assets verified; pristine portable subset and adoption manifest vendored.
- Product-owned bounded SSP adapter implemented with aligned caller-owned bounce buffer.
- Isolated qualified Debug and Release integration builds linked successfully.
- Pre-GC code size and S7G2 object-size evidence recorded.

Completed in the commissioning increment:

- Non-destructive startup classification and service-code 468 two-step commissioning UI.
- SD-thread-exclusive FileX-to-raw ownership transition, verified format/reopen,
  deterministic commissioning append, second reopen, and exact iterator proof.
- Automated commissioning and existing SD-safety invariant checks.
- Clean isolated Debug and Release builds with the activated core linked.

Incomplete:

- Behavioral adapter tests after a safe LBA window exists.
- Runtime stack high-water evidence after the core is connected.
- Controller and physical qualification.

## Goal

Integrate the pinned portable-core release with a reviewed Renesas/ThreadX
adapter and reproducible Windows builds while preserving existing behavior and
making no qualification claim beyond preserved controller evidence.

## Why It Matters

The existing FileX log path has demonstrated partial-export and media-failure
risks. A raw portable log store can improve structural recovery only if its
acknowledgment and flush semantics are honestly supported by this controller and
qualified independently on both controller variants.

## Major Outcomes

- Immutable, provenance-recorded upstream snapshot.
- Product-owned, heap-free SSP block adapter with explicit failure propagation.
- Qualified-toolchain build and memory evidence.
- Increasing-risk controller test evidence with operator gates.

## Delivery Stages

Use stages when sequencing, parity gates, or handoff cost matter.

| Stage | Outcome | Entry Evidence | Exit Evidence |
| --- | --- | --- | --- |
| 1 | Verify and vendor | pinned release identity and hashes | manifest and pristine subset match v0.4.0/media 1.0 |
| 2 | Design and implement adapter | reviewed upstream API and SSP contracts | bounded adapter and automated low-risk checks |
| 3 | Integrate and build | no generated changes required | clean Debug/Release builds and map evidence |
| 4 | Non-destructive controller validation | exact candidate and controller selected | geometry/error/reopen evidence |
| 5 | Destructive and interruption qualification | explicit media/hardware authority | both-controller evidence satisfying reliability contract |

## Related Artifacts

- Tickets:
- Checklists:
- Spikes:
- ADRs: work/adr/adr-commodity-retail-sd-media-policy.md
- Successor: work/wp/active/wp-triple-mirrored-circular-hpt-log-store.md
- Runbooks:
- Inventories: work/inventories/inventory-hpt-embedded-log-store-v0-4-0-integration-surfaces.md
- Decision matrices:

## Rough Sequence

1. Retrieve, verify, and vendor the pinned portable release. (complete)
2. Implement and build the bounded Renesas adapter/harness. (complete)
3. At startup classify a mounted FileX volume as FAT32/non-HPT without writes;
   if FileX cannot mount, probe HPT media read-only and distinguish ready,
   unsupported, corrupt/unknown, and I/O failure.
4. Add engineering service 468 to report classification. Offer destructive
   initialization only for confirmed FAT32 input, behind two explicit UI steps.
5. Execute commissioning only in the SD owner thread: stop normal SD work,
   close FileX, acquire raw block ownership, recheck geometry/classification,
   format media 1.0, close/reopen, append one deterministic commissioning
   record, close/reopen again, and iterate/compare it exactly.
6. Preserve first HPT/SSP error and sector; never auto-format blank, unknown,
   corrupt, unsupported, removed, write-protected, or I/O-failing media.
7. Add automated source/model checks, clean Debug/Release builds, and updated
   memory/map evidence.
8. Stop for explicit programming, whole-card initialization, and later
   interruption/power-cut authorization.

Steps 1 through 7 are complete. Step 8 is the current gate; no controller was
programmed and no card was written by this implementation work.

## Commissioning Acceptance Criteria

- [x] Boot and service-code probing are read-only.
- [x] FAT32 is reported as requiring initialization, not as generic corruption.
- [x] Valid HPT 1.0 opens without formatting.
- [x] Unsupported and corrupt/unknown media never expose a format action.
- [x] Only service-code 468 double confirmation can request whole-card format.
- [x] FileX and raw block access never overlap; the SD thread owns transition.
- [x] Format success requires close/reopen, commissioning append, second
  close/reopen, exact one-record iteration, and clean end-of-iteration.
- [x] Failure retains status, SSP code, and first physical sector.
- [x] Normal control continues; normal SD logging is inhibited during raw mode.
- [x] No generated Synergy configuration changes.
- [x] Qualified isolated Debug and Release builds pass.

## Milestones

### Milestone 1: Reproducible source adoption

Completion criteria:

- [x] Archive SHA-256 and upstream SHA256SUMS agree.
- [x] Version header reports library 0.4.0 and media format 1.0.
- [x] Manifest records repository, tag, commit, archive, checksum, and file ownership.

## Open Questions

- Does the SSP block-media write path synchronously wait for card completion, and
  is any stronger cache/barrier operation available for acknowledgment?
- What alignment and maximum transfer size does the portable core require?
- Can the 4096-byte SD stack absorb the adapter/core call depth, or must stack
  size change through a separately approved generated-configuration update?
- Which exact controller and expendable card will be authorized for the first whole-card qualification run?

## Completion Standard

This workpackage is complete when the pinned adoption is reproducible, the
product adapter is reviewed, qualified Debug/Release builds and memory evidence
pass, controller evidence satisfies the stated reliability contract, and the
adopting firmware version is named. Physical qualification is not complete until
authorized controller power-interruption tests pass on the required A/B set.

## Closeout Routing

The v0.4.0/media-1.0 source adoption, Renesas adapter, commissioning path, and
Controller A diagnostic evidence are preserved as the historical baseline.
Media-full behavior and Controller B qualification were not completed for
media 1.0 and are not claimed. Those gates were deliberately superseded,
rather than waived as passing evidence, when firmware 00.05.00 adopted the
product-owned triple-mirrored circular HPT media 2.0 format.

- Current truth promoted to: docs/sd-card-operation-and-recovery.md and an adoption record beside the vendored source
- Historical context remains in: this workpackage
- Runtime/status evidence: work/evidence/hpt-log-store-v0-4-0/
- Successor: work/wp/active/wp-triple-mirrored-circular-hpt-log-store.md
