I have an STM32WBA data logging project loosely based on the BLE heart rate project. I sync the RTC via either a BLE message, or NTP from a serial modem. All good; works well and the RTC timestamp ticks along whilst the code is in stop2 sleep. The device is battery-powered, so power is always present. I initialise the RTC in RTC_BINARY_ONLY mode.
I track whether the device has received a time sync by stashing a value in one the the backup registers.
When the device is reset by a button on the reset line, the RTC gets set to zero. This is not a problem.
However, when the device resets by calling NVIC_SystemReset(), the RTC appears to be 4194304 seconds ahead of where it should be. This is 4096 x 1024 seconds. I set the RTC frequency to 1024, so I'm guessing this is something to do with it? My code can handle this after a reset by setting the RTC back by 4096x1024 seconds.
What is a more tricky problem is that if the device has been in stop2 mode, and is then woken and reset by NVIC_SystemReset(), the RTC is now less than 4096x1024 ahead of where it should be. I think the difference is equivalent to the total time spent in stop2 mode. Does anybody know why this is?
My current solution is to stash the current RTC timestamp in a backup register just before I call NVIC_SystemReset(), and then restore this to the RTC after the reset. Is there a better solution to this?
