RTC jumps to year 2042 on every power cycle and cannot be corrected

[Chameleon560]

Hardware:

• Board: Seeed Studio XIAO ESP32S3 + Wio-SX1262 (Meshcore kit)
• Power: USB-C (no external RTC / backup battery)

Firmware:

• Firmware: Meshcore (Web Flasher build) Version: 1.16.0 (latest available from the Web Flasher at the time of writing) Bluetooth Companion

Environment:

• OS used for CLI: Debian 12
• Meshcore CLI version: v1.5.7
• Web Flasher: latest as of July 2026 Version: 1.16.0
• Node role: Bluetooth Companion

Description:

• On my XIAO ESP32S3 + Wio-SX1262 node, the device clock consistently jumps into the future after a hard power cycle.
• After each power cycle (USB power removed and reconnected), the device reports a “Current time” of: 2042-04-27 10:20:18 (Unix epoch 2282199618)
• Once this incorrect time has been set, it cannot be brought back to the real current time using normal means (Android App, CLI). The node keeps thinking it is in the year 2042.
• This looks like a persistent RTC / time-handling bug specific to the ESP32-S3/XIAO hardware combination, and it is reproducible on my device.

Steps to reproduce:

• Flash firmware 1.16 onto a XIAO ESP32S3 + Wio-SX1262 using the Web Flasher.
• Set the correct time (e.g. via CLI: meshcore clock sync)
• Verify that the time is correct.
• Perform a hard power cycle:
• Disconnect USB power completely.
• Wait a few seconds.
• Reconnect USB power and let the node boot.
• Check the reported device time (CLI or App UI).

Observed behavior:

• After the hard power cycle, the device clock is no longer at the previously set time.
• Instead, it consistently jumps to: Current time : 2042-04-27 10:20:18 (2282199618)
• Any attempt to set the time back:
  • clock sync: No time sync needed
  • clkreboot: ERROR:meshcore:Unknown command : clkreboot, ['clkreboot'] not executed ...
• The node continues to use this future time for logs / packets, which breaks “last heard” timestamps and time-related features in the App.

Expected behavior:

• After a power cycle, the device should either:
  • retain the previously set time (if hardware/RTC supports it), or
  • start at the Unix epoch (1970-01-01) or some neutral baseline, and then accept new time values from BLE, CLI or GPS.
  • Time sources with a valid current timestamp (phone, GPS, CLI) should always be able to override a clearly invalid future time.

Additional observations / hypotheses:

• The timestamp 2282199618 consistently corresponds to 2042-04-27 10:20:18, suggesting a deterministic misinterpretation of RTC memory, not random garbage.
• This may be related to ESP32-S3 RTC / RTC_SLOW_CLK behavior after losing power on the RTC domain (XIAO ESP32S3 does not have a backup battery for RTC), combined with how Meshcore interprets internal time on boot.

Questions / requested changes:

• Can the firmware detect obviously invalid times (e.g. far in the future compared to build date or phone time) and reset to a safe baseline?
• Always accept a new time value from App / CLI / GPS if the current device time differs by more than a configurable threshold?
• Is there any known ESP32-S3/XIAO-specific workaround (e.g. different RTC init path) that should be applied at boot for this hardware?
• If this is a hardware limitation (no backed-up RTC), could the firmware treat “uninitialized” RTC time more defensively on this platform?

Thank you very much!