2017-09-19 07:51 AM
Hi,
I'm using Nucleo STM32L476RG board and I have issue using specific configuration of RTC peripheral.
Our embedded software requires precise timing for real time application.
RTC is clocked by 32.768 kHz LSE and is configured with PREDIV_A: 0 and PREDIV_S: 32767 to get time resolution of 1/32768 s.
Then subseconds register will down count from PREDIV_S to 0 and Alarm A interrupt is used to get precise timer from milliseconds to minutes.
This configuration is valid according STM32L4 reference manual.
However we observed strange behavior:
- Timestamp retrieved from RTC are sometimes inconsistent: seconds register did not increment while subseconds register reached 0 and rolled over.
- RTC_OUT configured to output 1 Hz is 128 Hz. 1Hz output is observed only when PREDIV_A and PREDIV_S are set to default values (127 and 255).
I used Cube MX and last HAL drivers.
Did anyone already use this configuration and observe consistent results?
Thanks,
#rtc-time-and-date #rtc2017-09-19 02:30 PM
Hello!
For the first issue, DR,TR,SSR registers have shadow registers. The read from shadow registers controlled by BYPSHAD bit in CR register. This bit must be zero when you read the calendar, time and/or subseconds as unity.
The shadow registers updated every 2 RTC clock periods .(so your resolution will not be 1/32768)
To read the shadow registers must wait for RSF bit in RTC_ISR register to set.(must be cleared before wait) This indicates that shadow registers are ready for read.
HAL_RTC_WaitForSynchro(..) function waits for this RSF bit.
Note that RSF bit must be cleared by software.
So.. some pseudocode for reading RTC
Init RTC..(also clears the RSF)
BYPSHAD=0;
while(1)
{
wait for RSF;
Read SSR first (locks the higher order shadow registers)
Read Time
Read Date
Clear RSF
Use the calendar
}
For the second issue, RTC_OUT is not 1 HZ because the 1HZ freq taken from fRTCCLK/(256 * (PREDIV_A+1)) =128
The PREDIV_A=0.
Regards
vf
2017-09-20 05:00 AM
Thanks for your reply.
Results observed from RTC_OUT is then consistent, reference manual is confusing because RTC block diagram:
shows ck_spre is connected to RTC_CALIB and so I expect 1Hz for PREDIV_A: 0 and PREDIV_S: 32767.
Concerning shadow register read I enhanced my code with HAL_RTC_WaitForSynchro(). In my HAL RTC driver version (1.7.2) this function clears RSF bit and wait it to be set. Then my code is:
HAL_RTC_Init(...)
HAL_RTC_SetTime(...)
HAL_RTC_SetDate(...)
HAL_RTCEx_DisableBypassShadow(...)
onAlarmA()
HAL_RTC_AlarmAEventCallback()
{
onAlarmA()
}
onAlarmA:
HAL_RTC_WaitForSynchro(...)
HAL_RTC_GetTime(...)
HAL_RTC_GetDate(...)
Compute next alarm
HAL_RTC_SetAlarm_IT(...)
Next alarm is approximately 250ms later. I still see alarm A is sometimes not triggered. I saved Time and Date from RTC in Timestamp table and I see timestamp inconsistency as explained before.
What am I doing wrong?
2017-09-20 05:38 AM
Always get a current version of the RM you are working with:
It correctly depicts the RTC_CALIB to be outputs from the dividers - the ''512Hz'' is obviously a tap from the 6th bit of async divider and the ''1Hz'' is a tap from the 7th bit of the sync divider (ST: the narrative might say so, not just having described behaviour when mägic values are present in the prescaler regiters).
Timestamp retrieved from RTC are sometimes inconsistent: seconds register did not increment while subseconds register reached 0 and rolled over.
Errata to other families contain a RTC calendar registers are not locked properly erratum, I'd bet it applies to 'L4xx too, even if it is not in the current STM32L4x6xx Errata sheet, April 2017 DocID026121 Rev 5...
Quiting from the 'F40x errata:
Description
When reading the calendar registers with BYPSHAD=0, the RTC_TR and RTC_DRregisters may not be locked after reading the RTC_SSR register. This happens if the readoperation is initiated one APB clock period before the shadow registers are updated. Thiscan result in a non-consistency of the three registers. Similarly, RTC_DR register can beupdated after reading the RTC_TR register instead of being locked.Workaround1. Use BYPSHAD = 1 mode (Bypass shadow registers), or2. If BYPSHAD = 0, read SSR again after reading SSR/TR/DR to confirm that SSR is stillthe same, otherwise read the values again.JW
2017-10-02 10:48 AM
Errata to other families contain a RTC calendar registers are not locked properly erratum, I'd bet it applies to 'L4xx too, even if it is not in the current STM32L4x6xx Errata sheet, April 2017 DocID026121 Rev 5
It would be nice to get a confirmation from ST if this long-standing errata applies to any L4 or if it has been fixed.
Maybe the original poster just forget to read RTC_DR after RTC_SSR / RTC_TR?
2017-10-05 07:45 AM
If you look at sample code I provided before, RTC_DR is always read after RTC_SSR / RTC_TR.
Bypassing shadow registers (BYPSHAD = 1) solved the issue so I am convinced errata applies to any L4.
2017-10-10 07:51 AM
Hi
guillaume.ferlin
,I confirm that this RTC limitation described inSTM32F40x and STM32F41xerratasheet is also applied for STM32L4 product.
Please note that this documentation issue is reported internally to be fixed in next errata sheet version, sorry forany inconvenience it may bring.
-Nesrine-
2017-10-10 09:52 AM
+1