# Ticket: Service 514 positive endpoint sticky setpoint state



Status: complete; corrected endpoints, Save, timeout, and safe calibration restoration passed
Type: ticket

Updated: 2026-09-23
Next Action: none; retained as history; any new execution requires a new explicit owner instruction
Parent: work/wp/completed/wp-bounded-temperature-calibration-and-drift-recovery.md


## Problem



On Controller A, service 514 presents the intended fixed
`[-10.0,+10.0] C` range, reaches `-10.0 C`, but stops incrementing at
`+9.9 C`. The bounded spinner makes attempted out-of-range values impossible,
so the earlier instruction to enter `+10.1 C` or `-10.1 C` through this screen
was not applicable.

Source review found that `adjustFloatOneDpVal()` applies a special positive
setpoint ceiling of `maxVal - 0.1F` whenever
`S_DataEntry.Cache.isSetpoint` is true. `appTwoBtnEnterNewOffset()` opens the
service-514 float editor without explicitly clearing that shared state. The
observed asymmetric endpoint is therefore consistent with stale setpoint state
leaking into the service editor.

This is separate from the operator reference-device workflow under
Temperature Setup -> Calibrate. That screen edits a temporary configuration
copy, clamps `MainTemp_Offset` directly at both shared endpoints, and saves only
when the operator confirms.


## Expected Behavior



Service 514 must reach both inclusive endpoints, never inherit behavior from a
previous data-entry screen, and never allow repeated entry to expand the fixed
absolute interval. The operator reference-device calibration behavior remains
unchanged.


## Acceptance Criteria



- [x] Opening service 514 initializes all endpoint-relevant editor state
  deterministically.
- [x] `+10.0 C` is reachable, bounded, and saveable.
- [x] `-10.0 C` is reachable and saveable on the exact replacement candidate.
- [x] Further increments at the positive endpoint leave the one-decimal editor
  at `+10.0 C`.
- [x] Opening service 514 with the former stale `isSetpoint=true` condition
  produces the same endpoint behavior as opening it from any other state.
- [x] Cancel does not mutate `gRamConfig.MainTemp_Offset`, VEEPROM, or request
  persistence.
- [x] Timeout does not mutate `gRamConfig.MainTemp_Offset` or request
  persistence.
- [x] Automated source/regression checks cover the state-leak sequence.
- [x] The exact rebuilt candidate passes the service-514 positive endpoint and
  stale-state checks on Controller A.


## Verification



Run the temperature-calibration checks and full firmware regression suite,
build the frozen candidate, then exercise service 514 from both a fresh boot
and immediately after setpoint entry. Capture the exact image hash and
read-only stored-offset evidence before and after cancel/save cases.

## Implementation evidence

`appTwoBtnEnterNewOffset()` now explicitly clears the shared setpoint-mode flag
before opening service 514. The calibration policy check covers this
initialization. All 17 PowerShell regression checks, both Python unit-test
suites, and direct managed-make Debug/Release rebuilds passed on 2026-07-24.
The exact replacement is frozen in source commit `23c6cc7f` and artifact
commit `2616e275`, and its hash-checked Debug S-record is running on Controller
A. Direct target review reaches displayed `+10.0 C`, remains there after three
extra increments, and reports `isSetpoint=false`; raw editor value
`9.9999952 C` is within five microdegrees of the exact endpoint due to binary
float accumulation. The positive Save was then verified in both redundant
VEEPROM copies with only generation, offset, and checksum changes. The owner
restored the displayed value to `+0.3 C`; J-Link readback found `0x3E99986D`
(`+0.2999910 C`), zero save request, zero system errors, identical redundant
copies, and only the expected generation/offset/checksum changes from the
temporary `+10.0 C` record. Exact-candidate negative-endpoint and timeout
verification remain open.

The direct endpoint editor was canceled and VEEPROM remained byte-identical.
The harness then armed only volatile
`S_DataEntry.Cache.isSetpoint=true` and verified the byte readback as `1`.
The target was then reviewed with that exact former stale condition. Service
514 cleared the flag to false and reached displayed `+10.0 C`, not `+9.9 C`;
the raw editor remained bounded at `9.9999952 C`, stored calibration and
VEEPROM were unchanged, and no save request or system error was present.

During exact-candidate negative testing, the owner deliberately decremented
from the saved positive endpoint. Service 514 stopped at displayed `-9.9 C`
and saved raw `0xC11E667E` (`-9.9000225 C`) in both redundant copies. The next
binary-float subtraction crossed slightly below `-10.0 C`, and the shared
editor returned the old value instead of the permitted minimum. The source now
clamps overshoot to the applicable endpoint while retaining the setpoint-only
positive ceiling. All 17 PowerShell checks, five Python suites, and clean
Debug/Release builds pass. The correction is frozen in source commit
`b76c6fb2` and artifact commit `044022ba`.
Controller A was subsequently restored to displayed `+0.3 C`; readback found
`0x3E999735` (`+0.2999817 C`), identical generation-216 VEEPROM copies, zero
save request, zero system errors, and unchanged SD identity.

After a Pi reboot and owner-authorized remote-route bounce recovered J-Link
`69664082`, the hash-locked Debug S-record was programmed and verified on
Controller A. The option/VEEPROM bank was unchanged. Post-flash readback found
the same `0x3E999735` offset, a byte-identical 4 KiB VEEPROM image with SHA-256
`BED1340CBE6E770F5F20F27F0D5BBAEEA816E06642076DC38735EEC9C63F82C5`,
zero save request and system errors, and unchanged ready SD/CID evidence.
At that post-flash checkpoint, the corrected lower endpoint still required
operator-witnessed UI and Save verification.

The operator-witnessed retest now passes. The live editor reached exactly
`0xC1200000` (`-10.0 C`), remained bounded after three additional decrement
attempts, and saved exactly. Both 2048-byte VEEPROM copies are byte-identical
at generation `218` with valid CRC `0x85C7A024`; the 4 KiB capture SHA-256 is
`4382FB49E9BF5D7CD73F570631397D9B7301663B60F4E296A6E217C35B7572A2`.
Save request and system errors are zero, and SD/CID evidence is unchanged.
At that checkpoint, Controller A required restoration to its intended
`+0.3 C` calibration.

The owner restored and saved displayed `+0.3 C`. Readback found
`0x3E999A27` (`+0.3000042 C`), identical generation-220 redundant copies,
valid CRC `0xB12077C2`, zero save request and system errors, and unchanged
ready SD/CID evidence. The 4 KiB VEEPROM SHA-256 is
`810C6916EDF0E16660D2F166DE572F638201DEA35738C4890BAEB643DC9D5294`.
Controller A is back at its intended calibration.

The final timeout-without-save case passed. The owner opened service 514,
changed the live editor from displayed `+0.3 C` to `+0.4 C`, and did not press
Save or Cancel. Read-only evidence while open showed `p2AttachedWidget`
pointing to `DataEntryScreen` (`0x20034828`), live editor
`0x3ECCCD5A` (approximately `+0.4 C`), stored calibration
`0x3E999A27` (`+0.3000042 C`), and zero save request/errors. After the normal
four-minute timeout, `p2AttachedWidget` pointed to `MainScreen`
(`0x200395F4`), stored calibration remained unchanged, and the complete 4 KiB
VEEPROM was byte-identical before/after with SHA-256
`810C6916EDF0E16660D2F166DE572F638201DEA35738C4890BAEB643DC9D5294`.
SD status and raw CID were unchanged. All acceptance criteria pass.

## Owner-directed reconciliation — 2026-09-23

Reconcile stale active lifecycle to the previously documented completed disposition; no new test or broader acceptance claim.

Authorization: Owner instruction in this conversation on 2026-09-23 to close/abandon the named work and mitigate older active records.

Previous header retained for evidence interpretation:

> Status: complete; corrected endpoints, Save, timeout, and safe calibration restoration passed
> Next Action: none

Earlier observations, unchecked historical criteria, and procedures below/above remain history. This administrative disposition does not qualify a new firmware candidate, physical card, thermal system, ECO, or release. Current 00.05.01 obligations in IDEA-0006, IDEA-0007, MAP-0009, and CAMP-0028 remain unchanged.
