Feat/stm32 rtc

[ndoo]

Implement LSE-backed hardware RTC using STM32RTC library:

Add a proper ARCH_STM32WL branch in readFromRTC() and perhapsSetRTC() backed by the STM32duino STM32RTC library (1.9.0), using the hardware RTC peripheral with LSE_CLOCK as the clock source. The branch is guarded by HAS_RTC, which should be set to 1 only in variant files for boards that have a 32.768kHz LSE crystal populated.

The LSE drive strength is configured per-board via RCC_LSEDRIVE_CONFIG (one of the RCC_LSEDRIVE_* values), set before begin() so it takes effect before the library starts the LSE oscillator. When HAS_RTC=0, the branch returns RTCSetResultNotSet immediately without touching zeroOffsetSecs, bypassing the broken gettimeofday() fallback.

Add STM32duino RTC to stm32.ini lib_deps and HAL_RTC_MODULE_ENABLED to build_flags. LTO strips the unused RTC code on HAS_RTC=0 boards.

Coincidentally this also fixes an issue for STM32 targets, where they previously fell through to a gettimeofday() fallback in readFromRTC() that returns millis()/1000 on STM32duino — not a Unix timestamp — silently corrupting zeroOffsetSecs on first boot.

Also changed incorrect include convention for RTC.h in src/graphics/draw/UIRenderer.cpp and src/mesh/PhoneAPI.cpp which caused clashing includes with STM32's rtc.h on case-insensitive file systems.

Implemented to Wio-E5, RAK3172 and Russell variant (Russell build will fail due to another bug, fix in #10097).

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)
    • RAK3172
    • Wio-E5

[ndoo]

Force-pushed with an additional comment in stm32.ini to explain this line,

-iquote src/gps ; Required due to overlap of src/gps/RTC.h and STM32 rtc.h on case-insensitive filesystems

[jp-bennett]

This looks very interesting.

[Copilot]

Pull request overview

Adds STM32WL hardware-RTC support backed by the STM32duino STM32RTC library (LSE clock source) and fixes RTC header include collisions on STM32 case-insensitive filesystems.

Changes:

• Implement STM32WL (ARCH_STM32WL) readFromRTC() / perhapsSetRTC() support using STM32RTC when HAS_RTC=1.
• Enable RTC usage on specific STM32 variants by defining HAS_RTC and per-board RCC_LSEDRIVE_CONFIG.
• Update STM32 build config and switch several includes from <RTC.h> to "RTC.h" to avoid clashing with STM32 rtc.h.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
variants/stm32/wio-e5/variant.h	Enables RTC via HAS_RTC and sets LSE drive strength for Wio-E5.
variants/stm32/rak3172/variant.h	Enables RTC via HAS_RTC and sets LSE drive strength for RAK3172.
variants/stm32/russell/variant.h	Enables RTC via HAS_RTC and sets LSE drive strength for Russell.
variants/stm32/stm32.ini	Adds STM32RTC dependency and adjusts include search path to prefer project RTC.h.
src/gps/RTC.cpp	Adds STM32WL RTC read/set logic using STM32RTC (guarded by HAS_RTC).
src/mqtt/MQTT.cpp	Switches to "RTC.h" include form.
src/mesh/PhoneAPI.cpp	Switches to "RTC.h" include form.
src/graphics/draw/UIRenderer.cpp	Switches to "RTC.h" include form.

[ndoo]

Review feedback addressed + build test ✅

Resolved both Copilot review threads:

• src/gps/RTC.cpp — added oldQuality capture and triggerNodeInfoCheckOnTimeSource(oldQuality, currentQuality) call in the STM32WL HAS_RTC branch (commit ad84594), matching the pattern used in all other RTC branches. Thread resolved.
• variants/stm32/stm32.ini — no code change needed; HAL_RTC_MODULE_ENABLED is already unconditionally defined in stm32wlxx_hal_conf_default.h line 56 (part of the Arduino STM32 framework). The -DHAL_DAC_MODULE_ONLY flag only gates DAC usage in analog.h and does not suppress any other HAL module. Thread resolved.

---

Build-tested the two variants with HAS_RTC=1 added in this PR (Russell excluded — blocked by separate issue being fixed in #10097):

Environment    Status    Duration
-------------  --------  ------------
wio-e5         SUCCESS   00:00:29.404
rak3172        SUCCESS   00:00:28.117
========================= 2 succeeded in 00:00:57.521 =========================

RAM: 33.0% (21640 / 65536 bytes)
Flash: 76.8% (179304 / 233472 bytes) ← rak3172 (smaller of the two targets)

[ndoo]

Do tag as ai-generated, sorry.

I use the RTC extensively at my day job for sleep of ~24 hours, the STM32 consumes vanishingly little power in deep sleeps like that (edit: usually over a year of battery life on 2x 19Ah Li-SOCl2 batteries if LoRa is used for just sensor rather than kept on for mesh). Not sure that particular use case is useful to Meshtastic in general but it may come in handy in future if STM32LowPower is implemented so that sensor roles can deep sleep.

For now, it’s just plugging a hole in feature support for STM32 (RTC).

Edit: That being said, the core implementation is CC generated:

• ddbeffe: feat(stm32): implement LSE-backed hardware RTC using STM32RTC library
• b76c7b5: fix(stm32): trigger NodeInfo recheck on STM32 RTC time acquisition

However, I did point CC to my existing repos from other projects that use STM32RTC and also provide the LSE drive level init sequencing and cut out some register writes I know from my other projects are not needed.

While these are added by myself for testing the implementation:

• ea136d3: feat(rak3172,russell): enable LSE hardware RTC
• 1ccf90a: feat(wio-e5): enable LSE hardware RTC

[ndoo]

I need to add another check to prevent the RTC readback from setting the clock to 1970, by checking against build time.

It looks like STM32RTC sometimes thinks it's set when it was set with epoch 0 somehow.

[ndoo]

I’ll re-open a new one once I have done some cleanup, working with time is always fraught with problems (and ironically, burns lots of time)