# HPT Embedded Log Store v0.4.0 software integration evidence

Status: commissioning software and clean builds passed; controller qualification not started
Type: evidence
Updated: 2026-07-22
Next Action: obtain explicit authorization to program the exact candidate and begin non-destructive controller validation
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
Parent: work/wp/completed/wp-hpt-embedded-log-store-v0-4-0-renesas-integration.md

## Source identity

- Repository: `Sheldon-Mfg-Inc/HPT-Embedded-Log-Store`
- Tag/commit: `v0.4.0` / `a1ffd6ccd2d0a1f9e2801cc9de2e04966458a14e`
- Tar SHA-256: `39ea5adcfcc503934fa5bfeddbc79e0e5ed84e277e16e73ff9e2b35b806549e0`
- Zip SHA-256: `347649a74caea57a07191615438ccf0ff6a74f91040aa85be76528e9feda803a`
- Header version: library 0.4.0, media 1.0
- Both archives matched the supplied values and release `SHA256SUMS`.
- Every pristine vendored file was hash-compared to the extracted tar archive.

## Qualified build identity

- Windows e2 studio: `2024-01.1`
- SSP/Synergy: `2.6.1`
- Compiler: GNU Arm Embedded `10.3.1 20210824 (release)`
- Target: Cortex-M4, Thumb, hard-float FPv4-SP-D16
- Product: SMI `00.04.13` development worktree; no new firmware version assigned

The checkout already contained user-modified Debug/Release binaries. Builds ran
from an isolated staging copy and did not overwrite them. e2 generated managed
makefiles that included `src/HptLogStoreRenesas.c` and all five portable core
sources. Debug and Release linked successfully. Both resulting staged ELFs
reported `text=2,850,476`, `data=0`, `bss=28,435,692` bytes. The staged Debug
ELF is 15,163,952 bytes and the staged Release ELF is 11,318,344 bytes. These full-image
numbers are build evidence, not a delta or qualification result.

## Memory evidence

Arm object text before link-time garbage collection:

| Object | Text bytes |
| --- | ---: |
| Product Renesas adapter | 634 |
| Dedicated-card qualification harness | 704 |
| `block_device.c` | 74 |
| `crc32.c` | 76 |
| `encoding.c` | 180 |
| `log_store.c` | 2,790 |
| `media_format.c` | 1,192 |
| Total potential code | 5,650 |

The product now calls the core through the commissioning state machine. The
final Release map contains the qualification, adapter, and portable-core
functions, and `gHptQualification` is statically allocated off the SD thread
stack. The 5,650-byte figure remains the pre-GC upper estimate from object files.

GDB/DWARF `sizeof` evidence on the S7G2 ABI:

- `hpt_log_store`: 4,184 bytes caller-owned RAM
- `hpt_log_iterator`: 4,108 bytes caller-owned RAM
- `hpt_log_store_renesas`: 536 bytes caller-owned RAM, including the aligned
  512-byte SSP/DTC bounce buffer
- `hpt_block_device`: 24 bytes
- `hpt_log_qualification`: 8,904 bytes caller-owned aggregate containing the
  adapter, store, iterator, device, and result state

The qualification context is now a static instance, not a stack allocation.
Target stack high-water remains a controller-test gate. The generated SD thread
still has a 4096-byte stack; no generated configuration was changed.

## Adapter/durability finding

SSP 2.6.1 block media has read, write, ioctl, and close but no distinct flush or
synchronize command. `SF_Block_Media_SDMMC_Write` waits for
`SDMMC_EVENT_TRANSFER_COMPLETE`; the lower driver documents successful return as
"Card write finished successfully." The adapter maps the portable flush to
confirmation of that synchronous completion. This is a reviewed integration
assumption, not physical durability proof. Controlled controller power-cut tests
must validate every acknowledgment boundary.

The compiler found that the upstream byte buffer is not 4-byte aligned on this
ABI. The pristine core was not changed. The product adapter copies each
single-sector transfer through its aligned caller-owned bounce buffer.

## Safety gate

The owner selected a dedicated whole-card raw qualification profile on
2026-07-22. `HptLogStoreQualification.[ch]` implements
an explicit session API: FileX must be closed and retry inhibited before begin;
format is separately named as whole-card destructive; raw ownership is released
explicitly at end. The harness has no automatic entry point. Debug and Release
clean integration builds passed after adding it.
The SD owner thread now classifies media read-only at startup. Mounted FAT32 is
reported as needing initialization; a failed FileX mount is probed read-only as
HPT ready, unsupported, corrupt/unknown, or I/O failure. Service 468 is the only
format entry and requires two confirmations. It is offered only for confirmed
FAT32 media. The SD thread closes FileX, reclassifies, formats the whole card as
media 1.0, reopens it, appends one deterministic commissioning record, reopens
again, and requires an exact one-record iteration plus clean end-of-iteration.

`script/check-hpt-commissioning.ps1` passed 19/19 invariants and
`script/check-sd-safety.ps1` passed 20/20 checks. Clean isolated Debug and
Release builds passed from
`E:\dev\high_point\e2_workspaces\7520553_hpt_complete_d0d9f45629814d51aa089d02edd1f1e0`.
No generated Synergy file changed. No hardware was programmed, no controller
format was requested, and no power interruption was performed.
