STM32WB55 RTC SRR register sometimes not monotonical

[APort]

Hello,

We are running STM32WB RTC block from LSE.

Usually it works as expected (hours at a time).

One in a while, the RTC->SSR resister jumps back (up as it is a countdown reg) couple of ticks (~100 ticks) and continues from the same point as normal.

It happens with or without the RTC_CR_BYPSHAD flag (its just slightly harder to catch while using shadow registers as they require sync).

Reading the SSR value twice does not change this behavior.

It looks for example, like this if I read it in a loop:

7406

7405

7404

7494

7493

7492

...

RTC clock div is 16, prescaler is 7FFF.

It is probably not an issue with the crystal as the time itself is accurate.

Thanks in advance.

[Terry Greeniaus]

I didn't look at your code too closely; could there be an interrupt that is triggered and delaying you for almost a full wrap of the counter so that it looks like it jumped up by 100 but it actually counted down, wrapped and then nearly counted back down to its first value?

Seems unlikely but just a possibility...

TG

[APort]

1) You are right about the PRER, tried writing RTC->PRER in two stages; it made no change (for the issue).

2) This morning I run the minimal code on PNucleo-WB55 with exactly the same result. so its not our board or even chip package as we use the WLCSP100 package and the eval board is VFQFPN68.

3) BYPSHAD=1 and inconsistent state:

I would understand that, if I'd get a junk value on read/s and then it would go back to normal next read. But the actual value changes and is consistent afterwards (it counts down from the the same value as expected).

4) Tried configuring the LSI instead of LSE as clock source for RTC - same result (on nucleo board).

[APort]

I explicitly disabled all interrupts in the test code, so probably not.

[waclawek.jan]

Can't it be the second core? I know nothing of how the do as dualcore wireless​ STM32 work...

At this point to may want to contact ST directly, through FAE or the web support form.

JW​