Session Handoff [rv3028-eeprom]: RV3028 EEPROM config fix ready for upstream go-ahead #12

Next steps, in priority order

1. Get the maintainer's go-ahead to take the fix upstream, then open it. The clean branch fix/rv3028-eeprom-config (one signed commit, f64cfc2c) is pushed to this fork only. Ask him:

   • Draft or ready?
   • Add the 🤖🤖 title marker? CONTRIBUTING.md invites it for agent PRs, and he approved it on earlier PRs.
   • File an issue too? CONTRIBUTING.md treats this as a small fix, so a PR alone suffices. His usual pattern for opinion-laden fixes is issue plus PR.

   Then open the PR against upstream dev. Its body can draw on Store RV3028 backup switchover and trickle charger config in EEPROM (iteration branch) #11's description, which already has the defect, the procedure, review notes and hardware tables. Done when the upstream PR exists and Store RV3028 backup switchover and trickle charger config in EEPROM (iteration branch) #11 links it.

2. Before opening upstream, re-check that upstream dev hasn't moved. If it has: sync the fork's dev mirror, merge it into work/rv3028-eeprom-config, build, re-squash onto a fresh fix/ tip, and push with --force-with-lease. Then confirm the clean and work diffs are byte-identical. That is the upstream-contribution-workflow skill's step 5.

3. Clean up the hardware leftovers once the maintainer is done with the board.

   • Four throwaway probe worktrees: branches local/rv3028-probe-old, local/rv3028-probe-new, local/rv3028-probe-3156 and local/rv3028-probe-final.
   • The session's own hub worktree of ProjectTemplate (detached at origin/main).
   • Optionally, reflash the second RAK4631 with a clean build. It runs the probe-final diagnostic build: the fix, plus an rv dump|factory|clr|set serial CLI, adverts off, SoCal 927.875/62.5/SF7/CR5 at 1 dBm, name q7v.

4. Keep Store RV3028 backup switchover and trickle charger config in EEPROM (iteration branch) #11 open and unmerged until upstream merges or declines. Review feedback goes to work/rv3028-eeprom-config first, then gets re-squashed onto fix/.

External blockers

• Maintainer: the go-ahead and the shape of the upstream PR (step 1). Nothing upstream until then. Safe meanwhile: steps 2-3 prep, and keeping the branches current.
• Upstream (meshcore-dev): no CI on fork PRs. Copilot is the only bot reviewer there, and a force-push re-triggers it in about 15 minutes. See project memory "upstream PR state".

Internal dependencies

• Step 2 comes before step 1's PR, because the upstream PR has to come from a clean branch on the current upstream dev.
• Step 3's reflash waits on the maintainer releasing the board, since hardware may be needed again if upstream review asks for changes.

State

• Fork PR #11: work/rv3028-eeprom-config into dev, head 037d493b. Iteration record, never merged. Five Copilot rounds:
  • The last two found nothing.
  • The last round states no file coverage. Its table predates the 2-line .h comment, so coverage of that file can't be proven. The tooling's remedy (adding fleet review instructions to the branch) doesn't fit a third-party fork.
  • Every thread is resolved. Every local strict-review pass is recorded except one: a mid-batch pass whose content moved before recording. The final passes on 037d493b are recorded and clean.
• Clean branch: fix/rv3028-eeprom-config at f64cfc2c, pushed to the fork, byte-identical to 037d493b, based on fork dev = upstream dev = fad0ffb7 as of 2026-10-03.
• Write-up: fork issue #10, the original defect report from the ZephCore session.
• Worktrees: the work branch, the clean branch, and four local/rv3028-probe-* throwaways, all under the fleet worktree directory. Re-derive with git worktree list. The primary checkout is clean on main.
• Hardware: two RAK4631 + RAK12002 boards, split by the maintainer's instruction. The MeshCore session uses the second board only, the ZephCore session the first. Project memory has the by-id serials. Always address a board by its by-id path, never /dev/ttyACM*.
• Sibling work: ZephCore fork PR Serial Communication Changed? meshcore-dev/MeshCore#35 (ptr727/liquidraver-ZephCore, head cd5b5e3) carries the same fix with the same 3.15.6 sequence. Its body lists 6 cross-review items as "Open, for the next iteration", and this branch is the reference implementation for them.

The parked decision queue

0 parked. This fork has no decision label and no open decision issues. Next step 1 is the one question pending, and it is recorded as an external blocker.

What the last round did

• Confirmed the defect on hardware, on a factory-fresh RAK12002:
  • On dev, RAM 37h was B4 (calibration LSB forced) and reverted to 10 (BSM=00, TCE=0) at RTC midnight. A ~60 s power cut lost the time (PORF=1).
  • With the fix, the EEPROM holds 35h=40 and 37h=34 (trim kept), a reboot writes nothing, it survives midnight, and the same cut keeps the time to the second (BSF=1, PORF=0).
• BSM question: settled jointly with the ZephCore session by testing, then decided by the maintainer as "3.15.6 everywhere". Both boards showed zero spurious BSF over about 50-65 minutes each on USB, so the call rests on the manual, not on an observed failure.
• Ported the sequence: BSM parked during EEPROM access, single-byte reads and writes of differing bytes only, closing Refresh.
• Local review caught: unchecked reads feeding EEPROM, FEDE dropped, EERD ordering, a stale Control1 write-back, delay() returning early, a comment overclaim, and a misidentified impostor.
• Copilot caught: no store retry after a failed boot store, and the stale Control1 copy on a failed re-read. One note was declined with evidence (the fallback write result is unchecked by design).
• Cross-review against ZephCore (maintainer's request) added to MeshCore: an identity check (always-zero time bits, two agreeing reads), read-back on every boot, a best-effort idle wait before re-enabling the switchover, retries every 10 min capped at 3 per boot, MESH_DEBUG logs, and failing the EEbusy wait on the first failed read. It sent 6 items to ZephCore, all recorded on Serial Communication Changed? meshcore-dev/MeshCore#35.

What not to repeat

• Don't re-litigate BSM. Neither board showed a spurious switchover, so a BSF monitor won't add evidence. The decision is the maintainer's and is made.
• Don't loop EEPROM writes to catch a power cut mid-write. Endurance is 10,000 cycles at 25 °C (datasheet). Monitoring the BSF flag was the non-destructive test.
• Set up test state after flashing, never before. Each missed 1200-baud touch reboots the running build, and a store-on-boot build then re-stores from factory before the new build runs. That cost one invalid test round.
• Record the local-review pass before committing its fixes. Otherwise the engine refuses the digest and the pass goes unrecorded. That happened once.
• Don't trust MESH_DEBUG_PRINTLN to be compiled. It vanishes in release builds, so build with PLATFORMIO_BUILD_FLAGS="-D MESH_DEBUG=1" to compile new log lines.

New learnings

• 1200-baud touch on a RAK4631 running MeshCore: misses are common and the hold time is irrelevant, so retry in a loop. Recorded in the maintainer's RAK4631 flashing runbook, which is host-local.
• Arduino delay() can return up to about a tick early on the nRF52 (1024 Hz), ESP32 and STM32 cores, while Zephyr's k_msleep guarantees the minimum. Recorded in the fix's code comment.