# 7520553 temperature issue diagnosis

Captured: 2026-07-13 14:55:57 -07:00
Firmware: `7520553_SMI_FW_00_04_12.srec`
Controller probe: J-Link serial 69664082
Notion source: https://app.notion.com/p/39c10e2686d880c5a64efe3c7fe7cd62

## Reported behavior

The Notion page `553 issues` says that changing the setpoint to 37 degrees does
not cause heating to start. Its photo shows:

- header: `Not Configured`
- measured temperature: 19.7 C
- setpoint: 37.0 C

Preserved attachments:

- `work/evidence/notion-553-issues-photo-20260713.heic`
  - SHA-256: `C4DD35D9FCDE6C75C5C32497FC3C9791284EE23E99FD2F4FF597F5FA0680B375`
- `work/evidence/generated/notion-553-issues-photo-20260713.png`
  - SHA-256: `DC14FCA5CAD122BBA3B642D6AC95F868009C165812F7A9F04B819DC626E6C310`
  - Review conversion of the unchanged HEIC original.

## Live J-Link observations

The controller was read without resetting, programming, setting breakpoints, or
forcing outputs. The CPU remained running.

| Signal | Live value | Interpretation |
| --- | ---: | --- |
| `gRamConfig.Sys_ConfigVersion` | 1 | Accepted by current firmware |
| `gRamConfig.Sys_UpdateCount` | 1 | Stored configuration record |
| `gRamConfig.Sys_MachineType` | 1 | SMI |
| `gRamConfig.Sys_ModelNumber` | 0 | `Not Configured` |
| `gRamConfig.PartId` | empty | Unit configuration is incomplete |
| `gRamConfig.MainTemp_IsEnabled` | 0 | Temperature operation disabled |
| `gRamConfig.MainTemp_IsControlEnabled` | 0 | PID control disabled |
| `gRamConfig.MainTemp_SetPoint` | about 37.0 C | Setpoint is present |
| `gRamConfig.MainTemp_K_P` | 0.0 | PID configuration absent |
| `gRamConfig.MainTemp_K_I` | 0.0 | PID configuration absent |
| `gRamConfig.MainTemp_K_D` | 0.0 | PID configuration absent |
| `gCurrentMainTemp` | about 19.76 C | RTD measurement is updating |
| `gCurrentMainTemp_RTD` | about 19.76 C | Temperature input is plausible |
| `gCurrentMainTemp_LM73` | 0.0 C | RTD is the active source |
| `main_PidErrValue` | 0.0 | PID branch is not executing |
| `gMainHeaterOnTicks` | 0 | No heater demand |
| `gSmiMainHeaterOnTicks` | 0 | ISR has no heater demand |
| P2.03 output | low | Heater output is not asserted |
| Cortex fault registers | 0 | No processor fault recorded |
| `gMainSystemErrors` | 0 | No system-wide error bit recorded |

P2.03 is configured as a GPIO output and is the pin driven by the millisecond
heater ISR. The low pin agrees with the zero heater demand; there is no evidence
in this snapshot of a stuck-high output or a failed attempt to assert the pin.

## Diagnosis

The immediate cause is the persisted configuration. `Thread_Controller_entry()`
only executes temperature PID control when `MainTemp_IsControlEnabled == true`.
The live value is zero, so the firmware intentionally leaves heater demand at
zero even though measured temperature is below the displayed setpoint.

This is not presently evidence of a heater, RTD, PID calculation, scheduler, or
GPIO failure. The unit is internally consistent with an incomplete/unconfigured
state. The current power-on validation accepts a record when its configuration
version and CRC are valid, but it does not reject the semantically incomplete
combination observed here.

## Recommended attended recovery

Do not force P2.03 or bypass the PID.

1. Make the bench hardware safe for heater operation and have an operator present.
2. Record the intended model, part ID, serial number, temperature calibration,
   door calibration, and 4-20 mA calibration before changing configuration.
3. Use service function 524 (soft factory reset). The implementation restores
   temperature enable/control and default PID values while preserving the model,
   serial number, part ID, setpoint, temperature calibration/alarm settings,
   door calibration, and 4-20 mA calibration.
4. Because this unit currently has model 0 and an empty part ID, use service
   function 510 to select the correct model and confirm/update its part ID. Verify
   the serial number and other preserved identity/calibration values as well.
5. Reboot and verify these expected live values before accepting the repair:
   `MainTemp_IsEnabled = 1`, `MainTemp_IsControlEnabled = 1`, `K_P = 350.0`,
   `K_I = 0.75`, and `K_D = 5000.0` unless an approved product-specific setup
   requires different values.
6. With the chamber safe and attended, confirm nonzero heater demand, P2.03 PWM,
   physical heater current, temperature rise, and eventual regulation at setpoint.

## Firmware follow-up

Define and implement semantic configuration validation at startup. At minimum,
the policy should explicitly handle model 0/empty identity, disabled temperature
control, zero PID gains, and other impossible or incomplete combinations rather
than treating CRC plus `APP_CONFIG_VERSION == 1` as sufficient proof that the
configuration is operational. The intended safety behavior for an unconfigured
unit must be explicit: either remain inhibited with a clear blocking message or
run only after a complete commissioning flow.

## Limitations

No persistent settings were changed and the heater was not energized during this
diagnosis. Physical heater current, relay/wiring continuity, and closed-loop heat
rise remain to be checked after configuration is restored on an attended bench.

## Follow-up after model selection

The controller was re-read after the operator selected a model:

- `Sys_ModelNumber` changed from 0 to 3 (`SMI6`).
- `PartId` changed from empty to `SLM622`.
- Startup remained complete at `0xC00000FF`.
- `MainTemp_IsEnabled` remained 0.
- `MainTemp_IsControlEnabled` remained 0.
- `MainTemp_K_P`, `MainTemp_K_I`, and `MainTemp_K_D` remained 0.0.
- Actual RTD temperature was about 19.8 C and the setpoint remained about 37.0 C.
- PID terms, heater demand, and P2.03 output remained zero/low.
- Cortex fault registers and `gMainSystemErrors` remained clear.

This confirms that service function 510 updates model identity and part ID only;
it does not initialize temperature-control parameters. The next appropriate
recovery action remains service function 524 on an attended, heater-safe bench.

## USB IMX versus J-Flash assessment

There is no evidence that the disabled configuration was introduced only by the
J-Link load:

- The programmed S-record contains code flash at `0x00000000-0x002AFCC3` and
  option-setting data at `0x40120050-0x4012005F`. It contains no records in the
  internal data-flash configuration region beginning at `0x40100000`.
- The USB IMX path stages application data in QSPI and `finalUpdateCode()` erases
  and programs internal code-flash blocks beginning at `0x00000000`. It does not
  erase or program the VEEPROM blocks at `0x40100000` and `0x40100800`.
- J-Flash production programming used affected-image sector erase, program, and
  verify. The persistent serial/configuration content observed after programming
  is not the factory-default record that firmware would create if both data-flash
  blocks had been erased.
- The model-range check added in 00.04.12 runs during firmware boot regardless of
  whether code arrived through USB or J-Link. It is not update-path-specific.

The J-Flash project nevertheless has the internal data-flash bank enabled in its
sector-selection configuration. It was not affected by this S-record, but that
selection is unnecessary and creates avoidable risk for a future manual
`Erase selected sectors` or chip-erase operation. Disable the internal data-flash
bank in the programming project as a defensive tooling change.

## Later recovered live state

A later non-halting read showed that the repaired configuration had reached both
RAM and both persistent VEEPROM copies:

- Model 3 (`SMI6`) and part ID `SLM622`.
- `MainTemp_IsEnabled = 1` and `MainTemp_IsControlEnabled = 1`.
- PID defaults: loop 300 seconds, `K_P = 350.0`, `K_I = 0.75`, `K_D = 5000.0`.
- Actual RTD temperature about 36.6 C with a 37.0 C setpoint.
- Heater demand about 110 of 1000 millisecond ticks (approximately 11%).
- No Cortex fault or system error bits.

The instantaneous P2.03 read was low, which is expected during the off portion of
an approximately 11% PWM cycle. The large rise from the earlier 19.8 C reading to
about 36.6 C, together with nonzero PID demand, confirms that heating started.

Later correction: extended live sampling showed that 36.6 C was a steady-state
offset, not merely approach to setpoint. Service 524 preserved five zero
integral-limit fields from the incomplete pre-reset profile, so the otherwise
valid `K_I` term is clamped to zero. See
`work/evidence/temperature-steady-state-offset-diagnosis-20260714.md`.
