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.

[waclawek.jan]

Consequence of shift (through RTC_SHIFTR)?

JW

[APort]

Probably not; Always set to zero.

[waclawek.jan]

AFAIK there's no other mechanism of SSR to change abruptly by a relatively large value.

Try with a minimal application, which does nothing just reads the RTC.

Read out and check/post RTC registers content.

JW

[APort]

Well, with minimal configuration, just a tight loop after minimal init, it happens even faster.

Below is the block registers when it happens (all look pretty normal to me).

I would understand issue with the clock or faulty read value, but this thing is very consistent, and I can't imagine oscillator issue causing it (we did check just to be sure, it looks alright).

I have a feeling it has something to do with reading it in a tight loop, but with no shadow registers enabled, it should not be a problem.

[waclawek.jan]

With BYPSHAD=1 you *must* read twice and accept only if results match.

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

I can imagine that with extreme PREDIV_A (here == 0) the readout may get trickier. [EDIT] What's the related APB frequency? [/EDIT]

JW

[APort]

Well, I did mention it happens with or without shadow registers used (BYPSHAD), the minimal sample code just sets the BYPSHAD=1 while the original actually waits for a sync.

Now, If I understand this correctly, you must read the value twice to make sure the TR and SSR in sync (as they can change in between) and since we are reading only SSR it makes no difference. Besides, when I do it in a loop, I do read it "twice".

The values are the same, its not like I get one bad read then its ok, it shifts and is consistent afterwards.

I setup the entire system and all the buses to run on HSE @ 32MHz with no PLL in between.

Changing PREDIV_A to say 0xF (RTC->PRER = 0x7FFF | (0xF << 16U)), made no difference either.

I was looking at errata, but besides some pins interfering with the LSE clock, I did not found anything relevant (I don't use those pins either).

[waclawek.jan]

> I did mention it happens with or without shadow registers used (

Yes I read that; I've commented on the code you've posted.

> Now, If I understand this correctly, you must read the value twice to make sure the TR and SSR in sync

No. With BYPSHAD=1, read of asynchronous counters of the RTC may read them in inconsistent state, i.e. part of the counter has been updated and part not. Found experimentally, but the RM confirms, see the BYPSHAD=1 part of the writeup I've given above link to.

> RTC->PRER = 0x7FFF | (0xF << 16U)

PRER register has to be written in two steps, at least that's what RM says. Interestingly, RM0434 does say so in description of RTC_PRER register, but the linked description in Calendar initialization and configuration subchapter fails to give details... In RM0090 for 'F4 this section reads in the relevant point:

To generate a 1 Hz clock for the calendar counter, program first the synchronous

prescaler factor in RTC_PRER register, and then program the asynchronous prescaler

factor. Even if only one of the two fields needs to be changed, 2 separate write

accesses must be performed to the RTC_PRER register.

What hardware is this? Can you try on some "known good" board such as Nucleo or Disco or similar?

JW

[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).

[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]

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​

​

​