With CR_BYPSHAD=1 on STM32L4R5xx, is the RTC (RTCv2) SSR counter reset to RTC_PRER_PREDIV_S when calendar time is updated (HAL_RTC_SetTime)?

[FLott.1]

My testing appears to consistently show that whenever I update the calendar time and date, the RTC_SSR I read straight after the set operation is the RTC_PRER_PREDIV_S value.

However, I fail to find this explicitly stated anywhere? Maybe its obvious, but I need to know if I could rely on this.

(1) Is the RTC_SSR (direct mode - not shadow) reset when exiting INIT mode?

(2) RTC examples update date and time sequentially, explicitly exiting INIT mode between HAL_RTC_SetTime and HAL_RTC_SetDate. Is this safe? Does it rely on the fact that INIT mode exit takes 4 RTC CLK ticket to start counting?

[waclawek.jan]

1. Yes. This is documented in Calendar initialization and configuration subchapter, although not in the clearest way.
2. Cube/HAL is not famous for being brilliant. Nonetheless, it takes one second for the subsecond counter to underflow.

JW

[FLott.1]

Understood, thank you. In summary, Setting time first resets the SSR, which means you will less likely end up on a second edge between setting the time and date (assuming no RTOS task scheduling / interrupt interference).

However with all the external factors mentioned, it is probably best updating time in a way that prevents interference (maybe scheduling the update on a high priority RTC second interrupt). I have a PPS edge (PC13 pin) I use with the Timestamp feature to correct the second edges, and GNSS time source which will regularly update the time / date.

Thanks for your quick feedback.

[waclawek.jan]

> it is probably best updating time in a way that prevents interference (maybe scheduling the update on a high priority RTC second interrupt).

Or just simply don't use the Cube/HAL functions, write your own.

JW