# Service 510 configuration-save fault diagnosis and verification

Date: 2026-07-15  
Target: R7FS7G27H via J-Link serial 69664082  
Firmware artifact: `Debug/7520553_SMI_FW.srec`  
SHA-256: `70CA38269672AAA433F567FCCDA39B36FBE430410B58E72F61156AEF00B88EBC`

## Observed failure

Service code 510 accepted a model selection and displayed the Part ID prompt,
but the control subsequently returned to Not Configured. Debug tracing proved
that the model callback ran and the Misc thread consumed the save request, while
both VEEPROM blocks remained at generation 1/model 0.

A live NMI capture stopped in `NMI_Handler` with the MPU stack-error source
(`SPEST`, bit `0x1000`). `Thread_Misc` has a 1,024-byte stack, while
`SaveConfigToEeprom()` allocated two `S_Config` objects of 1,436 bytes each.
The stack monitor therefore fired in the function prologue before the commit
diagnostic or any flash operation could run.

## Mitigation

- Moved the immutable save snapshot and semantic-validation copy to two
  module-owned `S_Config` workspaces.
- Reused those workspaces in runtime save, startup validation, and factory-reset
  validation so all affected paths avoid full-record stack allocations.
- Retained the existing non-reentrant VEEPROM ownership model (`mSaveBlock`).
- Added a source-contract check that rejects full `S_Config` locals in
  `SaveConfigToEeprom()`.

## Verification

- All 16 configuration safety/source checks passed.
- All 14 fingerprint-policy fixtures passed.
- Isolated clean Debug build and versioned packaging passed.
- Loaded and verified the exact SREC above.
- Automated the firmware-side equivalent of selecting SMI6 and accepting the
  Part ID prompt: model 3 and Part ID `SLM622`, followed by the normal save flag.
- Armed NMI and reset catches for 45 seconds. Neither catch fired.
- Commit diagnostic reached stage `0xFFFF` with zero flash error and 256 watchdog
  refreshes across the two redundant block commits.
- Both VEEPROM blocks read back generation 3/model 3 and Part ID `SLM622`.
- Performed a controlled reset, waited 15 seconds, and confirmed RAM reloaded
  generation 3/model 3/`SLM622`; both flash blocks remained identical.
- Controller was resumed and left running.

Result: PASS for the reproduced service-510 persistence failure and controlled
reboot readback. Physical touchscreen traversal should still be repeated once as
a UI regression check, but the failing persistence path is proven corrected.

## Physical UI and power-cycle follow-up

The operator subsequently ran service code 510 through the touchscreen, selected
SMI7, accepted the Part ID update, and observed SMI7 on the HMI. A read-only
J-Link check showed RAM and both VEEPROM blocks at generation 5/model 5 with Part
ID `SLM722`; the last commit diagnostic remained successful (`0xFFFF`).

The operator then physically power-cycled the controller and confirmed the HMI
still displayed SMI7. Post-cycle readback confirmed:

- RAM and both VEEPROM copies remained generation 5/model 5/`SLM722`.
- Configuration operational flag was 1; all semantic findings/events were zero.
- RTD/effective temperature was 37.21 C with a 37.0 C setpoint.
- Main temperature enable and control-enable were both 1; heater control demand
  was active.
- Startup status was complete (`0xC00000FF`) and main system errors were zero.
- SD was available and READY, with last status 0, I/O failures 0, mirror failures
  0, and dropped records 0.
- Reset-status register `RSTSR1` read zero.

Final result: PASS. The physical service-510 UI, persistence commit, physical
power cycle, redundant readback, and immediate post-cycle health checks all pass.
