Boot-time unlock loop never calls reset_activity — device flickers Enter-PIN/Locked forever and needs two unlocks (#713 fixed in only one of two paths)

[Nicola-Ceornea]

Summary

Observed on pq1 silicon (sealed EVT unit, interactive ui-lcd image, 2026-09-22): a device left at the boot PIN prompt flickers between "Enter PIN / to unlock" and "Locked" indefinitely, and the operator has to enter the PIN twice before reaching the main screen.

Operator, verbatim:

"now it flickers between enter pin and something else in a loop"
"I unlocked the first time, and then less than a second later it asked me again to unlock. Only then it went on the main screen."

No PIN attempts are consumed — GET_STATUS read locked=0 remaining=10 afterwards. The loop never submits a PIN, so it does not walk toward the 10-attempt wipe. That is the one piece of good news.

Cause

There are two unlock loops. #713's fix landed in one of them.

secure/src/main.rs:4295 — PendSV re-unlock, correct:

ui::show_status("Enter PIN", "to unlock");
timeout::reset_activity();          // <-- the #713 fix
let mut pin = match enter_pin() { ...

secure/src/main.rs:3938 — boot-time unlock, missing it:

loop {
    ui::show_status("Enter PIN", "to unlock");     // no reset_activity
    let mut pin = match enter_pin() {
        PinEntryResult::Cancelled | PinEntryResult::IdleWipe => {
            ui::show_status("Locked", "");
            continue;                               // re-prompt, timer STILL expired
        }

ui::pin_entry::enter_pin (pin_entry.rs:102) samples timeout::is_idle() before waiting and calls reset_activity() only after a button event (pin_entry.rs:112). So once the idle deadline has passed, wait_button returns None immediately, enter_pin returns IdleWipe, the loop shows "Locked" and re-prompts — forever, with nothing ever resetting the timer.

grep -rn 'timeout::reset_activity()' secure/src/ --include=*.rs (excluding tests) confirms the production call sites are main.rs:4297, main.rs:4323, pin_entry.rs:112 and the seed wizard. Nothing in the 3938 loop.

Why the operator sees a "double unlock"

The first entry is consumed by an idle cycle; once a button press lands, pin_entry.rs:112 resets the timer and the next entry succeeds. From the outside that reads as "it asked me twice".

Impact

• Any user who does not enter the PIN promptly on a cold boot sees a device apparently looping, and must enter the PIN twice.
• It is the first thing a user does with the device, on the trusted display, so it is squarely a shipping-quality defect.
• Adjacent to CMD_LOCK strands the device: REQUEST_UNLOCK returns IdleWipe instantly, no PIN prompt, power cycle required #713 (same root cause, other call site) and Confirm dialog shows 'R=Confirm' on page 6 of 13, where it does not confirm — the hint is hardcoded into a page renderer #714 (trusted-UI defects found on pq1). Not a duplicate of either: CMD_LOCK strands the device: REQUEST_UNLOCK returns IdleWipe instantly, no PIN prompt, power cycle required #713 was CMD_LOCK → REQUEST_UNLOCK stranding, fixed in the PendSV path, and that fix is confirmed still working (a re-unlock after an idle wipe succeeded in 28 s this session).

Fix

Call timeout::reset_activity() immediately before enter_pin() in the boot-time loop, matching 4297. Consider instead moving the reset inside enter_pin() at entry, so no future call site can reintroduce the asymmetry — the two loops have now diverged once already.

Whatever the fix, it wants a test that asserts BOTH loops reset activity, not just the one that was reported.

Evidence

• pq1 sealed EVT 003B0022 30465002 2033314C, non-e2e-test image dual-se,dev-testkey,ui-lcd,stm32u585,usb,board-pq1.
• GET_STATUS after the episode: locked=0 remaining=10.
• Found while instrumenting pq1: FSBL cannot light the panel (no I2C stage for the AW99703) — invariant #10's boot fingerprint is invisible on a sealed unit #705; the loop is reproducible by simply leaving the device at the boot prompt.

[Nicola-Ceornea]

Fixed — 1fccb33a (on master)

The boot-time unlock loop now calls timeout::reset_activity(), which is what the second of the two loops was missing. #713's fix had landed in only one of them; this closes the other.

+                timeout::reset_activity();

secure/src/main.rs now resets activity at all three unlock sites (:4161, :4551, :4577), so the boot prompt no longer re-arms the idle deadline against itself and flickers Enter PIN / Locked.

The commit was reviewed by GPT-6-Astra before landing; its review corrected my rationale on this defect and a safety claim on the backlight one, and both corrections are folded into the commit message.

Landed alongside the second defect from the same silicon session — the AW99703 backlight boost could enable after a failed OVP write (#705).

Not verified on silicon by me. This was found on the sealed EVT unit by the operator, and the fix is verified by source and by the test suite, not by a re-run on glass. If it recurs on the next EVT walk-through, reopen — the symptom is distinctive enough that a regression would be obvious.

The one piece of good news in the original report still holds: this loop never submitted a PIN, so it never walked toward the 10-attempt wipe. The related attempt-consumption problem is #715, which stays open — its verdictless-runaway half is mitigated (255a9554, capped at 3), but the original fault is still unidentified.