cancel
Showing results for 
Search instead for 
Did you mean: 

RTC read time with and without shadow register and reading twice

bm2
Associate III

Hello,

I've a spezial question about the reading of the RTC date/time. In my project are used the STM32G030F6 with SYSCLK=64MHz and RTCCLK=32768Hz. Per reset value the BYPSHAD=0.

Now I read the date/time with the follwoing consecutive two lines:

 

const uint32_t time_u32 = READ_BIT (RTC->TR, (RTC_TR_HT | RTC_TR_HU | RTC_TR_MNT | RTC_TR_MNU | RTC_TR_ST | RTC_TR_SU));
const uint32_t date_u32 = READ_BIT (RTC->DR, (RTC_DR_WDU | RTC_DR_MT | RTC_DR_MU | RTC_DR_DT | RTC_DR_DU | RTC_DR_YT | RTC_DR_YU));

 

I can change it to reduce the runtime to:

 

const uint32_t time_u32 = RTC->TR;
const uint32_t date_u32 = RTC->DR;

 

We have don't use any IRQ's during reading the date/time.

In the referenzmanual is describe that the shadow register are set every RTCCLK cycle. Also it is describe that when I have a verry fast SYSCLK than is not used a twice read of the date/time to check if it changed during the read.

It is not complete clear when the shadow register are refreshed. In the RM is describe that the read from the SSR or TR the shadow register refresh locks and the read from the DR this unlock. But what is the beahviour when I only read the TR or SSR register? If the RSF flag during normal operation of the RTC reset or allways set?

What happens to the date/time valies ​​if they are read at the exact time of the change? As excample: the date/time are changed after the 1st source code line bevore the 2nd source code line read the next value?

Thanks for clarify this, Bernd

1 ACCEPTED SOLUTION

Accepted Solutions

It is not complete clear when the shadow register are refreshed. In the RM is describe that the read from the SSR or TR the shadow register refresh locks and the read from the DR this unlock. But what is the beahviour when I only read the TR or SSR register?

Refresh locks and remains locked. From user point of view, if you read TR or SSR and don't read DR, then TR won't change anymore ie. the perception is that clock "stops".

 

What happens to the date/time values ​​if they are read at the exact time of the change? As example: the date/time are changed after the 1st source code line before the 2nd source code line read the next value?

The purpose of lock is exactly to prevent this sort of inconsistency.

In older STM, this lock did not work properly; in 'G0, the RTC is in version 3 which has this problem fixed. It means, if you read SSR-TR-DR in this order, you read them from the locked shadows and the result is guaranteed to be consistent, regardless of whether there was a seconds increment meantime in the core RTC registers.

However, you must follow exactly the description in the Reading the calendar subchapter of RTC chapter in RM. Namely, you must not read the RTC twice within one RTC clock, i.e. reads of RTC have to be  at least cca 1/32.786kHz=31us apart. Otherwise you'd need to perform the more complex operation of waiting for RSF (which at the end of the day results in that cca 31us delay) - the painful details of this issue are the same as in RTCv2 and discussed here; but you don't need to know them if you obey the "don't read too often" rule.

JW

View solution in original post

1 REPLY 1

It is not complete clear when the shadow register are refreshed. In the RM is describe that the read from the SSR or TR the shadow register refresh locks and the read from the DR this unlock. But what is the beahviour when I only read the TR or SSR register?

Refresh locks and remains locked. From user point of view, if you read TR or SSR and don't read DR, then TR won't change anymore ie. the perception is that clock "stops".

 

What happens to the date/time values ​​if they are read at the exact time of the change? As example: the date/time are changed after the 1st source code line before the 2nd source code line read the next value?

The purpose of lock is exactly to prevent this sort of inconsistency.

In older STM, this lock did not work properly; in 'G0, the RTC is in version 3 which has this problem fixed. It means, if you read SSR-TR-DR in this order, you read them from the locked shadows and the result is guaranteed to be consistent, regardless of whether there was a seconds increment meantime in the core RTC registers.

However, you must follow exactly the description in the Reading the calendar subchapter of RTC chapter in RM. Namely, you must not read the RTC twice within one RTC clock, i.e. reads of RTC have to be  at least cca 1/32.786kHz=31us apart. Otherwise you'd need to perform the more complex operation of waiting for RSF (which at the end of the day results in that cca 31us delay) - the painful details of this issue are the same as in RTCv2 and discussed here; but you don't need to know them if you obey the "don't read too often" rule.

JW