Session Handoff [hw-cli]: #35 to a 3.15.6 RV3028 EEPROM procedure; Zephyr change next #37

Next steps, in priority order

1. rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's next iteration: close its "Open, for the next iteration" list (ten failure-path items in the PR body, none reached on a healthy chip and bus). Take 1-6 together: fail fast in rv3028_eeprom_idle() on an I2C error; an idle wait before the fallback re-enables switchover; apply the configured RAM 37h after any failed step, not only when the Refresh did not complete; read 37h back on every boot; check the fallback and EERD writes; retry from a periodic path rather than only on save. MeshCore's fix (Store RV3028 backup switchover and trickle charger config in EEPROM (iteration branch) meshcore-dev-MeshCore#11, 6faac3bc and later) already does each of these and is the reference. Done means: those items fixed through local-strict-review (two edit rounds, then push with the remainder listed), the TCR = 01 round-trip and a reboot on the RAK4631, pushed, Copilot and CodeRabbit answered.
2. Zephyr upstream: hold backup switchover off for RV3028 EEPROM access. The maintainer decided "3.15.6 everywhere" (MeshCore, ZephCore, Zephyr). Zephyr's drivers/mfd/mfd_rv3028.c (boot Refresh, update_cfg with Update) and drivers/eeprom/eeprom_rv3028.c (single-byte 21h/22h) all access the EEPROM with BSM live. No upstream issue or PR covers it (searched 2026-10-03). Work in a new worktree of the Zephyr fork, not the CH390 session's checkout; validate with a Zephyr sample on the RAK4631 + RAK12002. Done means: a fork iteration PR on ptr727's Zephyr fork, hardware-tested, with proposed upstream text. Opening the upstream PR needs the maintainer's go-ahead naming it.
3. Upstream ZephCore PRs, one at a time, only on the maintainer's go-ahead naming each (companion: mark a CLI reply cut to the app frame (iteration branch) #27 to companion: never treat an over-the-air CLI command as local (iteration branch) #32, then rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35 once step 1 lands), per hub upstream-contribution-workflow. Fetch upstream/dev first.
4. hw CLI on hardware (Add hw hardware-report CLI command (iteration branch) #1, Add the hw hardware-report CLI command (rebased, hw CLI only) #16), still not re-run since the separation.

External blockers

• Maintainer go-ahead for every upstream PR (ZephCore and Zephyr), and for any write to meshcore-dev/MeshCore.
• MeshCore Capture the reset cause at boot instead of consuming it (iteration branch) #11 belongs to the MeshCore session (meshcore-dev-meshcore-1e on this host); coordinate through it rather than editing that branch.

Internal dependencies

• rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's upstream squash waits on step 1, so it carries no listed defect.
• rtc: do not adopt a chip whose status read failed (iteration branch) #30 (fork issue RTC probe adopts a chip whose status-register read failed, then writes time into it #23) and rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35 both edit rtc_probe(); whichever goes upstream second rebases. Add the hw hardware-report CLI command (rebased, hw CLI only) #16's hw CLI touches the same file.
• The Zephyr change (step 2) is independent of ZephCore, but its argument and test plan reuse rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's: 3.15.6, the BSF data, and the TCR round-trip.

State (re-derive at resume: git worktree list, gh pr list)

• Fork dev = upstream/dev = f9d01cf.
• rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35 work/rak4631-rak12002-rtc at cd5b5e3, pushed; local passes recorded through cd5b5e3; Copilot and CodeRabbit rounds on cd5b5e3 all answered, threads resolved. companion: mark a CLI reply cut to the app frame (iteration branch) #27-companion: never treat an over-the-air CLI command as local (iteration branch) #32 unchanged. Add hw hardware-report CLI command (iteration branch) #1 at ad70d15 and Add the hw hardware-report CLI command (rebased, hw CLI only) #16 at cc54670: CodeRabbit reviewed both heads; Add hw hardware-report CLI command (iteration branch) #1's one thread (the RTC probe adopts a chip whose status-register read failed, then writes time into it #23 defect) answered and resolved.
• Hardware: the RAK4631 26B95495C1040CFD (USB only, no battery) runs rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's cd5b5e3 debug repeater build, SoCal, tx 1, handle lpxz, repeat off, adverts off. Its RV3028 EEPROM holds 37h = 0x34 under mask 0x3F (TCE, FEDE, BSM 01, TCR 00) and 35h CLKOE 0. A second RAK4631, 1CAB516AE4885AB2, belongs to the MeshCore session: never touch it.
• The throwaway test/rv3028-bsf-monitor worktree and branch were removed.

The parked decision queue

0 issues carry decision on this fork. Open maintainer questions, ranked:

1. Upstream go-ahead per fork PR (companion: mark a CLI reply cut to the app frame (iteration branch) #27-companion: never treat an over-the-air CLI command as local (iteration branch) #32; rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35 after step 1).
2. Go-ahead for the Zephyr upstream PR once step 2's fork PR is clean.

What the last round did

• rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35, from four documentation points to a 3.15.6 EEPROM procedure. Header contract and "restored" log (d2615c3); FEDE kept set, 37h mask 0x3F value 0x34 (041ec79); EEPROM read and written one byte at a time with BSM held at 00, then a closing Refresh (7b6a82a); the retry and fallback reworked over three more rounds (46bfd7c, e5a8d0a, cd5b5e3) with the maintainer approving each extra round; pushed with the remainder listed as open.
• Hardware, RAK4631 + RAK12002: TCR round-trip committed and verified at 7b6a82a and at cd5b5e3; reboots write nothing; a 31 s USB-unplug kept the time.
• BSF test, jointly with the MeshCore session, decided by the maintainer: both boards ran about 50-55 min with DSM and trickle charge on, through reboots and DFU flashes: zero spurious backup switchovers; a real cut set BSF and kept the time on both. The joint report weighed both sequences' costs and the backup-above-VDD case; the maintainer chose "3.15.6 everywhere".
• Cross-review with MeshCore Capture the reset cause at boot instead of consuming it (iteration branch) #11: each side checked the other's bot and local findings. It surfaced an EEPROM-impostor wear path and an unmasked-value latent bug in Capture the reset cause at boot instead of consuming it (iteration branch) #11 (fixed there), and rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's open items 1-6.
• Add hw hardware-report CLI command (iteration branch) #1: CodeRabbit's thread on the RTC probe answered as RTC probe adopts a chip whose status-register read failed, then writes time into it #23, fixed in rtc: do not adopt a chip whose status read failed (iteration branch) #30.

What not to repeat

• A retry that writes back a saved register value goes stale. 46bfd7c restored a pre-step 37h; once the EEPROM write had landed and a Refresh loaded it, the retry put the old value back. Re-run the procedure that reads the source of truth, or write the configured value, never a snapshot.
• Self-review rounds on failure paths did not converge. Five passes each found defects in the previous round's failure handling. Stop at the edit budget, push, and list the rest; bot review and a cross-review found the same items faster.
• Two datasheet slips from recall again: 3.17 for what is 3.15.6, and "about 70 ms" for a cost that was never computed. Grep the extracted manual (pdftotext is absent; uv run --with pypdf works) before writing a section number or a timing.
• Never state a hardware fact the maintainer has not given. "USB plus a LiPo" went into a commit message and a peer report; both RAKs are USB only.
• A logger started with $! from the platformio uv Python left a child running when the saved PID was killed; two readers then split the console and a boot line was lost. Read the real PID from ps before killing.

New learnings

• RV3028 BSM during EEPROM access, the BSF data and the decision are recorded in rak4631: use a fitted RAK12002 RTC, and keep its backup switchover enabled (iteration branch) #35's body and its commits; MeshCore's side is in Store RV3028 backup switchover and trickle charger config in EEPROM (iteration branch) meshcore-dev-MeshCore#11.
• The RAK boards being USB only, the second RAK's owner, and the launcher-PID gotcha are in this host's project memory.