You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RV3028 loses the time on a power cut: ZephCore never enables its backup switchover #33
Found while hardware-testing work/rak4631-rak12002-rtc (fork issue #4) on a RAK4631 with a RAK12002 fitted, 2026-10-03.
What happens
With the RV3028 declared, the time survives a reset or reboot: after a CLI time set and a soft reboot, the boot log shows RTC rtc-rv3028@52: restored <time>. It does not survive a power cut. After removing USB and battery for about 30 s, the boot log shows:
<wrn> zephcore_rtc: rtc-rv3028@52 present, power-loss flag set — clock will be set on the next GPS/app/CLI sync
So the chip lost power, came back through a power-on reset with PORF set, and holds no time until the next sync.
Why
ZephCore's discovery (adapters/clock/ZephyrRTCDiscover.c) only reads and writes the time block and clears the power-loss flag. It never configures the RV3028's backup-supply switchover, the EEPROM Backup register at 0x37. Other code that drives this chip does:
Zephyr's own RV3028 driver writes 0x37 at init (drivers/mfd/mfd_rv3028.c), and its binding makes backup-switch-mode required.
MeshCore writes 0x37 = 0xB4 on every boot (src/helpers/AutoDiscoverRTCClock.cpp), which is direct switching plus trickle charging (1 kΩ).
What a fix needs to decide
Whether to write 0x37 at all from the generic, data-only discovery, or add an optional per-descriptor init write (for example init-reg / init-val in the zephcore,rtc-i2c binding) that only the RV3028 descriptors set.
Trickle charging is the hazard. It is right for a supercapacitor or a rechargeable cell, and wrong for a primary cell. What backs the RAK12002, and any other board using the RV3028 descriptor, must be established from its schematic before a fix enables it. Switchover without trickle charging is the conservative choice.
Writing the RAM copy of 0x37 every boot, as MeshCore does, avoids EEPROM wear but is reloaded from EEPROM on reset. Writing the EEPROM copy persists it but is a one-time configuration change to the module.
Hardware to verify a fix: the same RAK4631 + RAK12002, sync, power cut, boot, expect restored.
Fixed upstream by liquidraver#98, merged 2026-10-05: the RV3028 descriptor's EEPROM configuration (0x37 backup switchover with trickle charging, for the RAK12002's supercapacitor) is applied at discovery, writing only bytes that differ.
Activity
ptr727 commentedon Oct 10, 2026
Fixed upstream by liquidraver#98, merged 2026-10-05: the RV3028 descriptor's EEPROM configuration (0x37 backup switchover with trickle charging, for the RAK12002's supercapacitor) is applied at discovery, writing only bytes that differ.