Repository navigation
RAK4631 never uses a fitted RAK12002 RTC #4
Description
Found while building the hw command (#1).
Problem
boards/nrf52840/rak4631/board.overlay includes sensors-i2c.dtsi but not rtc-i2c.dtsi, so ZephCore declares zero RTC candidates on this board. A fitted RAK12002 (RV3028 at 0x52) is invisible: the firmware runs the soft clock and loses time on every power-off, with nothing to indicate why.
Why it is safe to add here
rtc-i2c.dtsi is opt-in per board because its fixed addresses can collide. On this board specifically they do not:
- RTC descriptors: 0x68, 0x51, 0x52, 0x32
- WisBlock sensor slots: 0x38, 0x40, 0x44, 0x5c, 0x70, 0x76, 0x77
- OLED: 0x3c
0x68 is shared with MPU-class IMUs including the RAK1905, but nothing declares 0x68 here so there is no devicetree clash, and the discovery probe already rejects a chip whose time registers are not valid BCD — which is the exact case that check exists for.
The descriptors are data-only and probed by raw I2C, so a board with no RTC module fitted simply fails the probe and is skipped.
Status
Fixed on work/hw-cli as d84acfb. Costs +1576 B flash on a repeater build, because the discovery code was previously compiling to its no-RTC-declared stubs on this board.
Verified on hardware: the RV3028 is now found and adopted as the write-back target.
Activity
Merge dev into work/hw-cli
ptr727 commentedon Oct 2, 2026
Correction, and a changed fix (2026-10-02).
The "Why it is safe to add here" section above is wrong on one point. It says the discovery probe rejects a chip at 0x68 whose time registers are not valid BCD. It doesn't:
rtc_probe()accepts a candidate whose time is valid BCD or whose power-loss bit reads set. For the DS3231 descriptor that bit is bit 7 of register 0x0F, read on whatever chip answers at 0x68. On a WisBlock IMU with that bit set, the probe would adopt the IMU as the clock. Every later time sync would then write seven bytes over its registers and clear that bit, and a RAK12002 fitted alongside would never be written.So
work/hw-cli(#1) no longer includes the whole ofrtc-i2c.dtsion this board. Commit 1dd6dc8 declares only the candidate a WisBlock actually carries: the RAK12002's RV3028 at 0x52, with the same descriptor the shared file uses. The original change, d84acfb, is superseded. It builds clean for rak4631 companion and repeater. It has not been re-run on hardware since the change; the earlier hardware result (the RV3028 found and adopted) was with the full include.Move the upstream defect fixes out of the hw CLI iteration branch
ptr727 commentedon Oct 10, 2026
Fixed upstream by liquidraver#98, merged 2026-10-05: the RAK4631 overlay now declares the RAK12002's RV3028 at 0x52 (one candidate, not all of rtc-i2c.dtsi, because of the 0x68 IMU clash).