# Controller A bounded-calibration matrix

Status: active; all corrected service-514 and reference-calibration interaction cases passed; reboot/update preservation remains
Type: evidence
Updated: 2026-07-24
Next Action: retain the completed interaction evidence and cover reboot/update preservation only after G-PWR or another approved non-power reset path is available
Campaign Reason: Historical record from campaign 010-qualify-firmware-negative-and-recovery-behavior; retained independently after campaign closure and requires no separate owner-queue execution.
Campaign: standalone
Parent: work/wp/completed/wp-bounded-temperature-calibration-and-drift-recovery.md

## Identity and baseline

- Controller A, assembly `1751136`, hardware version `0`.
- J-Link serial `69664082`.
- Frozen source commit `b76c6fb2`; artifact commit `044022ba`.
- S-record SHA-256:
  `1D047B144B6DFA88447212ED2670C3F7B636D24D29B5A20B100453A4806B2978`.
- RTD sensor path.
- Pre-test stored offset: `+0.3 C`.
- Pre-test system/configuration findings: zero.
- Same-run SD CID:
  `035344535330384780976F0084018559`.

## Results

| Case | Expected | Result |
| --- | --- | --- |
| Open service 514 | Fixed absolute interval `[-10.0,+10.0] C`; current `+0.3 C` | PASS — owner confirmed |
| Exit without a replacement | No configuration mutation; offset remains `+0.3 C` | PASS — owner confirmed |
| Service 514 decrement endpoint | Stops at inclusive `-10.0 C` from every valid starting value | PASS — corrected candidate reached raw `-10.0 C`, remained there after three extra decrements, and saved exactly |
| Service 514 increment endpoint | Reaches inclusive displayed `+10.0 C` and further increments do not change it | PASS — replacement candidate; raw editor `9.999995 C`, displayed `+10.0 C`, three extra taps bounded |
| Service 514 timeout without Save | Returns to Main without changing stored calibration or persistence | PASS — screen pointer returned to Main; stored `+0.3 C` and 4 KiB VEEPROM remained identical |
| Attempt `+10.1 C` / `-10.1 C` in service 514 | Spinner prevents values beyond its endpoints | N/A — direct invalid entry is not available on this screen |
| Open Temperature Setup -> Calibrate | Display adjusted temperature used to match the reference instrument | PASS — owner started at `22.5 C` |
| Short tap | Changes displayed reference value exactly `0.1 C` | PASS — owner confirmed on replacement candidate |
| Hold and release, both directions | Value auto-repeats while held and stops on release | PASS — owner confirmed on replacement candidate |
| Increment once, then cancel | Display rises `0.1 C`; stored offset and persistence remain unchanged | PASS — isolated retest; VEEPROM byte-identical and stored offset unchanged |
| Unsaved operator-calibration upper endpoint | Temporary total offset reaches exactly `+10.0 C`; further increments cannot exceed it | PASS — cache `0x41200000` after three extra taps; stored configuration and VEEPROM unchanged |
| Cancel from operator-calibration upper endpoint | Stored offset and persistence remain unchanged | PASS — VEEPROM byte-identical, stored offset unchanged, no save request |
| Unsaved operator-calibration lower endpoint | Temporary total offset reaches exactly `-10.0 C`; further decrements cannot exceed it | PASS — cache `0xC1200000` after held decrement plus three extra taps; stored configuration and VEEPROM unchanged |
| Save operator calibration at `+10.0 C` total offset | Accepted; another increment remains clamped at `+10.0 C` | PASS — service-514 save persisted bounded `9.999995 C`, displayed `+10.0 C` |
| Save operator calibration at `-10.0 C` total offset | Accepted; persisted value remains at the same total offset | PASS — exact `-10.0 C`, redundant CRC-valid generation-222 readback |
| Restore `+0.3 C` | Exact intended value saved and verified | PASS — exact one-decimal `+0.3 C`, redundant CRC-valid generation-224 readback |
| Reboot/update preservation | Exact valid correction preserved | pending |

No physical power interruption is part of this matrix while G-PWR is closed.

## Negative-bound repeated-save evidence

The owner opened Temperature Setup -> Calibrate at a displayed `22.5 C`,
decremented to the lowest available displayed value (reported as `14.x C`),
saved with the forward button, reopened the calibration screen, and attempted
to decrement again. The reopened displayed minimum was `12.3 C`.

Because the displayed value contains the live raw measurement, the different
screen minima alone were ambiguous. A same-run read-only J-Link capture from
Controller A / probe `69664082` resolved the result:

- `gRamConfig.MainTemp_Offset`: `0xC1200000` = exactly `-10.0 C`;
- `gRamConfigCache.MainTemp_Offset`: `0xC1200000` = exactly `-10.0 C`;
- `gCurrentMainRawTemp`: `0x41B26533` = approximately `22.3 C`;
- `gCurrentMainTemp`: `0x4144CA66` = approximately `12.3 C`; and
- `gIsSaveConfigToEeprom`: zero, confirming no save request remained pending.

Thus the second displayed value was lower because the raw sensor temperature
fell during the test. The saved total correction did not accumulate below
`-10.0 C`.

## Intended-offset restoration

The owner restored `+0.3 C` through service 514. A same-run read-only capture
through `srv-rpi00.local:19120` and J-Link `69664082` confirmed:

- `gRamConfig.MainTemp_Offset`: `0x3E999A26`, approximately `+0.300004 C`;
- `gIsSaveConfigToEeprom`: zero, so no save request remained pending;
- `gCurrentMainRawTemp`: approximately `22.6774 C`;
- `gCurrentMainTemp`: approximately `22.9774 C`, consistent with raw plus the
  restored correction; and
- hardware version `0`, confirming Controller A.

No reboot, power interruption, or new firmware load was performed.

## Scope correction and source diagnosis

The owner clarified that the safety-relevant customer workflow is the
reference-device calibration screen under Temperature Setup, not service 514's
direct-offset editor. Source inspection confirms that the operator screen:

- begins from a temporary copy of the current configuration;
- displays `raw temperature + temporary MainTemp_Offset`;
- clamps the temporary total offset directly to the shared inclusive
  `[-10.0,+10.0] C` interval; and
- mutates `gRamConfig` and requests persistence only when Save is pressed.

The service-514 `+9.9 C` ceiling is tracked separately in
`work/tickets/ticket-service-514-positive-endpoint-sticky-setpoint-state.md`.
Its generic float editor can inherit `S_DataEntry.Cache.isSetpoint`; when that
flag is true, the positive adjustment path deliberately caps at
`maxVal - 0.1F`. Service 514 does not explicitly clear the flag before opening
the editor, which is consistent with the observed asymmetric endpoint.

## Replacement calibration-UI candidate build

The follow-up source now:

- explicitly selects non-setpoint endpoint behavior before service 514 opens;
- enables GUIX press-and-hold repeat on both reference-calibration adjustment
  buttons in `GuiX/SMI_Gui.gxp`; and
- carries the same repeat style in generated `src/SMI_Gui_specifications.c`.

Single-click callbacks and the absolute endpoint clamps are unchanged. All 17
PowerShell regression checks and both four-test Python suites passed. Direct
managed-make clean rebuilds passed for Debug and Release. Packaging produced:

- Debug ELF SHA-256:
  `57C4802E3AA931233BD17CAB43F2ED0ECD82B62A41640856601D7D23F7CFD830`;
- Debug S-record SHA-256:
  `00F6430B7EDD65B222065807B4D8D95EA15DFA029F08DAFD8826103096ECB93A`;
- Release ELF SHA-256:
  `CAC42BA22DBB3B14AD587B932647838AD5F35F64A51351E0AFFBBEA2BEACCA46`;
- Release S-record SHA-256:
  `D4DCAB83777387341169064C3F8156A60C38FA4AF54C408C69B43A64B8FB0864`.

The source was frozen in commit `23c6cc7f` and the exact Debug/Release
artifacts were frozen in commit `2616e275`.

The isolated `headless-e2-build.ps1` path was attempted once and hit its bounded
420-second timeout. Its e2 log reported a missing Renesas
`buildSupportFileTarget` path. It was not retried. The established direct
managed-make wrapper completed both rebuilds successfully.

## Controller A replacement load

Only Controller A was programmed. `script/program-bench.ps1` selected J-Link
serial `69664082`, verified the exact Debug S-record SHA-256
`00F6430B7EDD65B222065807B4D8D95EA15DFA029F08DAFD8826103096ECB93A`,
and J-Link reported `O.K.` after flash program and verify. Controller B was not
accessed.

The pre-load and post-load configuration captures are byte-identical:

- VEEPROM SHA-256, before and after:
  `41D38533B876ED558F9C1E04C1AE720AE46F340B7FAA816F2AFF9B1F1A69BD62`;
- option-memory SHA-256, before and after:
  `80A76A18ACF8CB64FEC3A659FFC4BAB4A87CD9A6FDE4DAB2161A8751D136C9D2`;
- hardware version: `0`;
- `gRamConfig.MainTemp_Offset`: `0x3E999A26`, approximately
  `+0.300004 C`;
- `gIsSaveConfigToEeprom`: zero;
- `gMainSystemErrors`: zero; and
- SD state: ready (`5`), CID valid, representative-sector read valid.

The post-load adjusted temperature remained consistent with raw temperature
plus the restored offset. The target was resumed after the read-only capture.

Same-run post-load SD identity:

- manufacturer: code-reported `SanDisk`, MID `0x03`;
- OEM/application ID: `SD`;
- product name: `SS08G`;
- product revision: `8.0`;
- serial number: `0x976F0084`;
- manufacturing date: May 2024;
- raw 128-bit CID: `035344535330384780976F0084018559`.

This CID is identity evidence, not authenticity proof.

## Auto-repeat review and Cancel discrepancy

The owner confirmed on the replacement candidate that:

- a short tap changes the displayed reference value by exactly `0.1 C`;
- holding either adjustment button repeats; and
- releasing either button stops the repeat.

The requested sequence ended with Cancel, but read-only post-test evidence
cannot yet prove the non-mutation criterion:

- live `gRamConfig.MainTemp_Offset`:
  `0x3E9999D8`, approximately `+0.3000019 C`;
- pre-test value: `0x3E999A26`, approximately `+0.3000042 C`;
- persistence request: zero;
- post-test VEEPROM SHA-256:
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- pre-test VEEPROM SHA-256:
  `41D38533B876ED558F9C1E04C1AE720AE46F340B7FAA816F2AFF9B1F1A69BD62`.

The VEEPROM copies differ only in update count, the low-order bytes of
`MainTemp_Offset`, and their checksums. The result remains effectively
`+0.3 C`, system errors remain zero, and the card remains ready with the same
CID. Because the combined sequence did not isolate its final action, it remains
context rather than Cancel evidence.

The owner then ran the isolated sequence: open Temperature Setup -> Calibrate,
increment exactly once, and use the left Cancel button. Immediate read-only
evidence established:

- baseline and post-Cancel VEEPROM SHA-256 are identical:
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- byte comparison: zero differing bytes;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`,
  approximately `+0.3000019 C`;
- temporary `gRamConfigCache.MainTemp_Offset`: `0x3ECCCD0B`,
  approximately `+0.4000019 C`, proving the one-step edit occurred only in
  the temporary copy;
- persistence request and system errors: zero; and
- protocol card state remained ready with valid CID and representative-sector
  read, raw CID `035344535330384780976F0084018559`.

The isolated Cancel criterion therefore passes.

## Unsaved upper-boundary evidence

The owner held the reference-calibration increment button until the displayed
value stopped, released it, tapped increment three more times, and left the
screen open. Immediate read-only evidence established:

- temporary `gRamConfigCache.MainTemp_Offset`: `0x41200000`, exactly
  `+10.0 C`;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`,
  approximately `+0.3000019 C`;
- VEEPROM SHA-256: unchanged at
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- byte comparison against the isolated-Cancel baseline: zero differences;
- persistence request and system errors: zero; and
- protocol card state remained ready with valid CID and representative-sector
  read, raw CID `035344535330384780976F0084018559`.

The exact upper endpoint and outward-step clamp pass without a persistent
mutation.

After the owner selected the left Cancel button, a second immediate read-only
capture confirmed:

- VEEPROM SHA-256 remained
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- byte comparison against the open-upper-limit capture: zero differences;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`,
  approximately `+0.3000019 C`;
- persistence request and system errors: zero; and
- protocol card state and raw CID
  `035344535330384780976F0084018559` remained unchanged.

The unsaved upper-boundary sequence is fully passed.

## Repaired service-514 positive endpoint

The owner opened service 514 on the replacement candidate, increased the
direct-offset editor until it displayed `+10.0 C`, tapped increment three more
times, and left the editor open. Immediate read-only evidence established:

- editor value: `0x411FFFFB`, approximately `+9.9999952 C`, which rounds to
  the editor's one-decimal `+10.0 C` domain;
- editor minimum/maximum: exact `-10.0 C` / `+10.0 C`;
- shared `isSetpoint` mode: false;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`,
  approximately `+0.3000019 C`;
- VEEPROM SHA-256: unchanged at
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- persistence request and system errors: zero; and
- protocol card state remained ready with valid CID and representative-sector
  read, raw CID `035344535330384780976F0084018559`.

The five-microdegree internal difference is retained as raw evidence of binary
float accumulation. It is safely inside the approved limit and represents
exactly `+10.0 C` at the editor's specified one-decimal resolution. This
direct-entry case passes the observed `+9.9 C` regression.

After the owner selected the left Cancel button, immediate read-only evidence
confirmed:

- VEEPROM SHA-256 remained
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- byte comparison against the open-editor capture: zero differences;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`;
- persistence request and system errors: zero; and
- `isSetpoint` was false.

The Cancel criterion passes. The harness then wrote only the volatile
`S_DataEntry.Cache.isSetpoint` byte to `1` and read it back as `1`. No
persistent configuration or media was changed. Controller A was resumed with
the exact former stale state armed for the next service-514 entry.

The owner then reopened service 514, increased to displayed `+10.0 C`, and
confirmed it stopped there rather than at the former `+9.9 C` ceiling.
Immediate read-only evidence established:

- previously armed `isSetpoint`: cleared from `1` to `0` by service-514 entry;
- editor value: `0x411FFFFB`, approximately `+9.9999952 C`, displayed
  `+10.0 C`;
- editor bounds: exact `-10.0 C` / `+10.0 C`;
- stored `gRamConfig.MainTemp_Offset`: unchanged at `0x3E9999D8`;
- VEEPROM SHA-256: unchanged at
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`;
- persistence request and system errors: zero; and
- protocol card state and raw CID
  `035344535330384780976F0084018559` remained unchanged.

This directly reproduces the former precondition and proves the endpoint-state
leak is fixed on the replacement candidate.

The owner then used the right-arrow Save action. After the asynchronous
persistence request completed, read-only evidence established:

- stored `gRamConfig.MainTemp_Offset`: `0x411FFFFB`, approximately
  `+9.9999952 C`, displayed `+10.0 C`;
- persistence request and system errors: zero;
- VEEPROM SHA-256 changed from
  `1E2AACFAF79B65B1B806AE4B42F96805E4CB81DB423857B322BDA59F65091D50`
  to
  `936C939DFD6FDEEBC32F6AE0FA7D0EB6C6EA6453928CEB409C9D8B2DA0330DE7`;
- both redundant VEEPROM copies changed identically in generation, the
  `MainTemp_Offset` field, and checksum only; and
- protocol card state and raw CID
  `035344535330384780976F0084018559` remained unchanged.

The bounded positive Save case passes.

The owner then restored the displayed service-514 value to `+0.3 C` and used
the right-arrow Save action. Same-run read-only evidence established:

- stored `gRamConfig.MainTemp_Offset`: `0x3E99986D`, approximately
  `+0.2999910 C`, which is exactly `+0.3 C` in the service editor's one-decimal
  domain;
- persistence request and system errors: zero;
- both 2048-byte redundant VEEPROM copies are byte-identical, carry generation
  `210`, and contain the same `0x3E99986D` offset;
- VEEPROM SHA-256:
  `1010B47AB5E07E58F3389D7A1D6E0E0A4489DE2244FF23D711FBE71D2EEB157E`;
- compared with the temporary `+10.0 C` state, exactly 18 bytes changed:
  generation, four offset bytes, and four checksum bytes in each redundant
  copy; and
- protocol card state remained ready with valid CID and representative-sector
  read, raw CID `035344535330384780976F0084018559`.

Controller A is restored to its intended `+0.3 C` display-domain calibration.
No reboot, power interruption, firmware load, or Controller B access occurred.

## Inconclusive negative-endpoint Save attempt

The next requested sequence was to reach displayed `-10.0 C`, make three
additional decrement attempts, and Save. The owner reported only `saved`, so
the pre-Save display was not independently confirmed. Immediate J-Link
readback established:

- stored `gRamConfig.MainTemp_Offset`: `0x411FFFF0`, approximately
  `+9.999985 C`, not a negative value;
- both redundant VEEPROM copies are byte-identical at generation `212`;
- compared with the preceding restored `+0.3 C` record, exactly 18 bytes
  changed: generation, offset, and checksum in each redundant copy;
- VEEPROM SHA-256:
  `524D0FAA537B6FBCA0FC0747BF7C120F2AE29C19A3168E5A0191243EBF3A38FA`;
- persistence request and system errors: zero; and
- card state/CID remained unchanged.

This is a clean persisted positive-endpoint record, not a torn or
single-copy persistence failure. The negative-endpoint case is invalid until
the owner confirms what the screen displayed immediately before Save. Restore
the intended `+0.3 C` value before any unrelated testing.

The owner then stated that the first attempt may have used the wrong
direction and repeated the sequence deliberately. This time the display
decreased but stopped at `-9.9 C`; the owner saved that value. Immediate
readback established:

- stored `gRamConfig.MainTemp_Offset`: `0xC11E667E`, exactly
  `-9.9000225 C` as a binary float;
- both redundant VEEPROM copies are byte-identical at generation `214`;
- VEEPROM SHA-256:
  `9ED0AB60C79C7461AD0D912B47261820BCC518A0AD96294C2302C03FC50265FE`;
- only generation, offset, and checksum bytes changed from the preceding
  positive-endpoint record;
- persistence request and system errors: zero; and
- card state/CID remained unchanged.

This is a confirmed service-514 endpoint defect. Repeated binary-float
subtraction from the positive endpoint produced a next candidate just below
`-10.0 C`; `adjustFloatOneDpVal()` rejected that candidate by returning the
old `-9.9000225 C` value instead of landing on the permitted endpoint.

The source correction now clamps a decrement overshoot to `minVal` and a
non-setpoint increment overshoot to `maxVal`. The existing setpoint-specific
positive ceiling remains unchanged. Verification passed:

- all 17 PowerShell invariant checks;
- all five Python model/negative-corpus suites;
- clean Debug and Release managed-make rebuilds; and
- versioned artifact packaging.

Corrected artifact hashes:

- Debug ELF:
  `8E9794000359289755ED0D8B46DF615E43796E0FD319F5621059E7859ECEF155`;
- Debug S-record:
  `1D047B144B6DFA88447212ED2670C3F7B636D24D29B5A20B100453A4806B2978`;
- Release ELF:
  `AC1C1E5A83EBF6B7DAAF643F12C5A80272C7EC4263F1A301A39F4C3F956D5898`;
- Release S-record:
  `133591CBFF1EC3F8C9398D1EF3373F42E729DCEA54D93DBE78C9787999AE1DF5`.

The correction was frozen in source commit `b76c6fb2` and artifact commit
`044022ba`. The owner restored displayed
`+0.3 C` before any new image load. Same-run readback established:

- stored `gRamConfig.MainTemp_Offset`: `0x3E999735`, approximately
  `+0.2999817 C`, which is `+0.3 C` at the editor's one-decimal resolution;
- both redundant copies are byte-identical at generation `216`;
- VEEPROM SHA-256:
  `BED1340CBE6E770F5F20F27F0D5BBAEEA816E06642076DC38735EEC9C63F82C5`;
- exactly 18 bytes changed from the `-9.9 C` test record: generation, offset,
  and checksum in each copy;
- persistence request and system errors are zero; and
- card state/CID remains unchanged.

Controller A was safe at its intended display-domain calibration. Controller B
was not accessed. Three initial authorized programming attempts failed before
`loadfile` because the Pi remote server could not acquire J-Link `69664082`;
therefore no firmware write began. At the owner's direction, `srv-rpi00.local`
was rebooted. The owner then authorized bouncing the Windows remote route.
After the exact Disable/Enable shortcut sequence, SSH recovered and the Pi
reported a fresh boot at `2026-07-24 15:04:19 PDT`. The serial-bound service
for J-Link `69664082` passed its health check on port `19120`.

The hash-locked programming retry then loaded and verified Debug S-record
`1D047B144B6DFA88447212ED2670C3F7B636D24D29B5A20B100453A4806B2978`
on Controller A. The separate option/VEEPROM bank was skipped because its
contents already matched. Post-flash readback established:

- stored `gRamConfig.MainTemp_Offset`: `0x3E999735`, approximately
  `+0.2999817 C`;
- the full 4 KiB VEEPROM SHA-256 remains
  `BED1340CBE6E770F5F20F27F0D5BBAEEA816E06642076DC38735EEC9C63F82C5`,
  byte-identical to the safe pre-flash capture;
- save request and system errors are zero;
- protocol status is ready (`5`), CID-valid and representative-sector-read
  status are both true; and
- raw CID remains `035344535330384780976F0084018559`.

Evidence:
`work/evidence/integrated-00-05-00-target-qualification-20260724/setup-a/post-endpoint-clamp-flash-read.log`
and
`work/evidence/integrated-00-05-00-target-qualification-20260724/setup-a/post-endpoint-clamp-flash-veeprom.bin`.
Controller B was not operated.

## Corrected service-514 lower endpoint and Save

The owner opened service 514 on the corrected candidate, decremented to
displayed `-10.0 C`, made three further decrement attempts, and left the
screen open. Read-only J-Link evidence established:

- live editor, minimum, and displayed-domain endpoint:
  `0xC1200000` = exactly `-10.0 C`;
- stored calibration remained `0x3E999735`, approximately `+0.2999817 C`,
  before Save;
- VEEPROM remained byte-identical to the safe pre-test capture, SHA-256
  `BED1340CBE6E770F5F20F27F0D5BBAEEA816E06642076DC38735EEC9C63F82C5`;
- save request and system errors were zero; and
- SD protocol status and raw CID remained unchanged.

After the owner pressed Save, readback established:

- stored `gRamConfig.MainTemp_Offset`: `0xC1200000`, exactly `-10.0 C`;
- both 2048-byte redundant VEEPROM copies are byte-identical at generation
  `218`;
- both stored CRCs are valid and identical (`0x85C7A024`);
- VEEPROM SHA-256:
  `4382FB49E9BF5D7CD73F570631397D9B7301663B60F4E296A6E217C35B7572A2`;
- save request and system errors are zero; and
- SD remains ready with valid CID and representative read, raw CID
  `035344535330384780976F0084018559`.

The corrected lower-endpoint and bounded Save case passes. At that checkpoint,
Controller A was deliberately at the temporary test value `-10.0 C` and
required restoration before unrelated testing.

The owner then restored displayed `+0.3 C` through service 514 and saved it.
Read-only evidence established:

- stored `gRamConfig.MainTemp_Offset`: `0x3E999A27`, approximately
  `+0.3000042 C`, exactly `+0.3 C` at one-decimal display resolution;
- both 2048-byte redundant VEEPROM copies are byte-identical at generation
  `220`;
- both CRCs are valid and identical (`0xB12077C2`);
- VEEPROM SHA-256:
  `810C6916EDF0E16660D2F166DE572F638201DEA35738C4890BAEB643DC9D5294`;
- save request and system errors are zero; and
- SD remains ready with valid CID and representative read, raw CID
  `035344535330384780976F0084018559`.

Controller A is restored to its intended safe calibration. No Controller B
operation or physical power interruption occurred.

## Service-514 timeout-without-save evidence

The owner opened service 514, changed the live editor to displayed `+0.4 C`,
and left the screen untouched until its normal four-minute timeout. While the
screen was open, read-only evidence established:

- `p2AttachedWidget=0x20034828`, the linked `DataEntryScreen`;
- live editor `0x3ECCCD5A`, approximately `+0.4 C`;
- stored `gRamConfig.MainTemp_Offset=0x3E999A27`, approximately
  `+0.3000042 C`;
- save request and system errors: zero.

After timeout:

- `p2AttachedWidget=0x200395F4`, the linked `MainScreen`;
- stored calibration remained `0x3E999A27`;
- the complete 4 KiB VEEPROM remained byte-identical, SHA-256
  `810C6916EDF0E16660D2F166DE572F638201DEA35738C4890BAEB643DC9D5294`;
- save request and system errors remained zero; and
- SD remained ready with valid CID and representative read, raw CID
  `035344535330384780976F0084018559`.

The timeout-without-save case passes.

## Reference-calibration lower endpoint, bounded Save, and restoration

The owner opened Temperature Setup -> Calibrate, held decrement until it
stopped, continued holding for two seconds, released, made three further
decrement taps, and left the screen open without saving. Same-run read-only
J-Link evidence established:

- `p2AttachedWidget=0x20040C34`, the linked
  `SelectWarningMsgScreen`;
- temporary `gRamConfigCache.MainTemp_Offset=0xC1200000`, exactly
  `-10.0 C`;
- stored `gRamConfig.MainTemp_Offset=0x3E999A27`, approximately
  `+0.3000042 C`;
- the complete 4 KiB VEEPROM remained byte-identical to the safe baseline,
  SHA-256
  `810C6916EDF0E16660D2F166DE572F638201DEA35738C4890BAEB643DC9D5294`;
- save request and system errors were zero; and
- SD status remained ready with valid CID and representative read, raw CID
  `035344535330384780976F0084018559`.

After the owner pressed Save, readback established:

- stored and temporary offsets were both `0xC1200000`, exactly `-10.0 C`;
- both 2048-byte VEEPROM copies were byte-identical at generation `222`;
- both stored CRCs were valid and identical (`0xA42D7157`);
- VEEPROM SHA-256:
  `4D7BCC0F6B3647040072F4182F1A1165ECA1444F5CD7FF5F666F660FA9D773AB`;
- save request and system errors were zero; and
- the same ready SD status and raw CID were retained.

The owner then used service 514 to restore displayed `+0.3 C` and saved it.
Final readback established:

- stored `gRamConfig.MainTemp_Offset=0x3E999A27`, approximately
  `+0.3000042 C`, exactly `+0.3 C` at display precision;
- `gCurrentMainTemp` remained consistent with raw temperature plus the restored
  correction;
- both 2048-byte VEEPROM copies were byte-identical at generation `224`;
- both stored CRCs were valid and identical (`0x5F23D7B4`);
- VEEPROM SHA-256:
  `D455DE6F843FFB5FB6F3095AADE83D053D6B2FE35B98D956FECBE4A77A0FA1CD`;
- save request and system errors were zero; and
- SD remained ready with valid CID and representative read, raw CID
  `035344535330384780976F0084018559`.

The reference-calibration auto-repeat, lower clamp, and bounded Save ticket
passes. Controller A is restored to its intended safe calibration. No
Controller B operation or physical power interruption occurred.
