Back to back reads of RTC registers sometimes show increasing SubSeconds

[matkSENS]

I think I may have found a bug with the STM32G4 RTC that I am not seeing in the errata.

I am using the RTC on STM32G4 with a 32.768 KHz LSE oscillator. I am having a issue where I would read the RTC twice fairly close together in code. I observed that occasionally on the 2nd read of the RTC the SSR value would increase without a change to either the TR or DR. I tested with shadow bypass both enabled and disable and I observed the same behavior.

I tried to profile the SSR values that I would get which triggered this condition and I noticed that the 2nd read was often 3 more than the 1st read (ex. 22492 and 22495) but sometimes the 2nd read was even more. It also seemed that multiple least significate bits of the 1st read were 0; I suspect that this could be explained by the fact the RTC is not on the same clock domain and I happen to be reading the SSR in the middle of a decrement before the bits are stable.

I seem to be able to work around this by reading the RTC registers 2 times until they match. I saw this is needed on older processors with a RTC shadow register bug.

Is this a known issue, a new issue, or am I doing something wrong?

[Andrew Neil · Accepted solution]

I think this is a known issue:

https://community.st.com/t5/stm32-mcus-products/stm32f4-stm32h7-rtc-hw-bug-shadow-registers-for-seconds-and/td-p/102958/page/2

http://efton.sk/STM32/gotcha/g95.html

[matkSENS]

Thanks! Those do seem to be the same issue. It almost seems like shadow RTC registers just don't work. I was surprised that "bits within registers were inconsistent" but I could not find that documented in the G4 RM. It makes sense why as they are in different clock domains. Reading the registers twice until the values are consistent seems to be the best way to go.

[waclawek.jan]

As I wrote in the article @Andrew Neil linked to above, I've observed this only when BYPSHAD=1. I would be surprised to see it when BYPSHAD=0 as one of the purposes of the shadow registers readout mechanism is exactly to eliminate problems stemming from reading asynchronously clocked counters (the other is to provide consistent readout of multiple registers i.e. SSR+TR+DR through the locking mechanism).

Btw. 'G4 has RTCv3, which does not suffer from the "sometimes shadow registers won't lock" erratum.

JW

[matkSENS]

Thank you for pointing that out!

I guess my biggest issue is with the SSR. My best understanding is that it can be read in an unstable state no matter if BYPSHAD is 1 or 0. So for example, if someone is relying on the RTC with sub seconds as a monotonically increasing timer, a single read to the SSR can be inconstant. Also from your article, the code to get a constant RTC reading with BYPSHAD=0 is more complex and takes longer than the double read solution when BYPSHAD=1.

Again I am still new to this microcontroller and my expectation was that using BYPSHAD=0 would be less complicated to ensure consistent clock readings, but it seems to come with more caveats and complexities.

[waclawek.jan]

> My best understanding is that it can be read in an unstable state no matter if BYPSHAD is 1 or 0.

This shouldn't be the case. If BYPSHAD=0, hardware should work so that SSR is read into its shadow in a way that reading from shadow is always consistent. Can you please confirm that your finding is with BYPHSHAD=0?

> Also from your article, the code to get a constant RTC reading with BYPSHAD=0 is more complex and takes longer than the double read solution when BYPSHAD=1.

This is because of the "RTC shadow lock sometimes fails" erratum (the exact name of erratum is different, I am lazy to look it up at the moment). That erratum is for RTCv2, whereas in 'G4 there is RTCv3, which should not have this problem (btw. I say so in the small print at the beginning of the article, easy to overlook I admit).

JW

[matkSENS]

I just reran my tests and yes, I am only seeing the the truly unstable SSR register values with BYPSHAD=1. However, with BYPSHAD=0, I was seeing the "early reading after an unlock" from http://efton.sk/STM32/gotcha/g95.html where the SSR would be reset to its max value but the TR had not yet updated. As far as I can tell this is still present on the RTCv3.

It looks like the only bullet proof way around that is to use the RSF method which looks like it requires 2 extra RTC clock cycles to complete. That method still requires 2 reads of the SSR, TR, and DR plus the overhead of unlocking the RTC and waiting for the RSF bit. So for me I would just rather set BYPSHAD=1 and read the registers twice.

[waclawek.jan]

Thanks for coming back with your findings. 

> the only bullet proof way

This is just another case of "there's no perfect solution in mcu programming". There's a plethora of applications where using the shadows makes perfect sense (e.g. where there's an implicit guarantee that requires are far enough apart, or where subseconds are not used at all); and then there are applications like yours where the shadows mechanism gets into way more than it helps... And the most important thing is to have enough precise information to make an adequate decision. 

JW