> Using HAL to set the time and date takes around 112 us when using both the data and time functions which provides plenty of opportunity for loss of time/data sync especially if there are other processes that can extend this out.
The RTC is stopped during initialization. Initialization is started in HAL_RTC_SetDate and exited in HAL_RTC_SetTime. As long as you're calling them with a consistent date/time, there's no chance for desync.
The documentation should be improved to note that they must be called in the correct order (first HAL_RTC_SetDate then HAL_RTC_SetTime).
Look at the RTC_ISR_INIT bit to see how this is handled.
Hi TDK,
Thank you for your prompt reply.
I don't understand your following sentence:
"The RTC is stopped during initialization. Initialization is started in HAL_RTC_SetDate and exited in HAL_RTC_SetTime."
Looking at HAL, as far as I can see the clock counter is started and stopped in each of the HAL RTC functions; setData..,
setTime...,
See code below.
If this doesn't happen than setting the time and not setting the calendar when the calendar isn't used will stop the RTC without restarting it.
HAL RTC Set Date
status = RTC_EnterInitMode(hrtc); /* Clock stopped here */
if (status == HAL_OK)
{
/* Set the RTC_DR register */
hrtc->Instance->DR = (uint32_t)(datetmpreg & RTC_DR_RESERVED_MASK);
/* Exit Initialization mode */
status = RTC_ExitInitMode(hrtc); /* Clock restarted here */
}
HAL RTC Set Time:
HAL_StatusTypeDef HAL_RTC_SetTime(RTC_HandleTypeDef *hrtc, RTC_TimeTypeDef *sTime, uint32_t Format)
{
uint32_t tmpreg;...
/* Enter Initialization mode */
status = RTC_EnterInitMode(hrtc); /* Clock stopped here */
if (status == HAL_OK)...
/* Set the RTC_TR register */
hrtc->Instance->TR = (uint32_t)(tmpreg & RTC_TR_RESERVED_MASK);
/* Clear the bits to be configured */
hrtc->Instance->CR &= ((uint32_t)~RTC_CR_BKP);
/* Configure the RTC_CR register */
hrtc->Instance->CR |= (uint32_t)(sTime->DayLightSaving | sTime->StoreOperation);
/* Exit Initialization mode */
status = RTC_ExitInitMode(hrtc); /* Clock restarted here */
}HAL_StatusTypeDef RTC_EnterInitMode(RTC_HandleTypeDef *hrtc)
{
uint32_t tickstart;
HAL_StatusTypeDef status = HAL_OK;
/* Check if the Initialization mode is set */
#if defined(RTC_ICSR_INITF)
if((hrtc->Instance->ICSR & RTC_ICSR_INITF) == 0U)
{
/* Set the Initialization mode */
SET_BIT(hrtc->Instance->ICSR, RTC_ICSR_INIT); /* Clock stopped here */ ...
HAL_StatusTypeDef RTC_ExitInitMode(RTC_HandleTypeDef *hrtc)
{
HAL_StatusTypeDef status = HAL_OK;
/* Check if the Initialization mode is set */
#if defined(RTC_ICSR_INITF)
/* Exit Initialization mode */
CLEAR_BIT(RTC->ICSR, RTC_ICSR_INIT);... /* Clock started here */
I know that the books say (somewhere) that you should set the time THEN the data, but I cannot see why.
The HAL_RTC idea that you should call the functions in the "correct order" not good programming practice when dealing with hardware drivers, especially when there is no mention of this in the HAL driver documentation. (I remember reading it somewhere, but I can't find it now). I found the problem when I noticed the date time got out of sync on the annual rollover from 2023 to 2024. I then went back through our databases and found similar desynchs on the 24 hour boundary. Luckily the de-synchs were corrected by routine RTC clock setting, so they didn't accumulate. I worked out what the problem was immediately and did my fix in under an hour. Works fine now. I was setting the date before the time. It was easy to fix the date & times in the database as they are in unix epoch milliseconds.
What happens if you are trying to set the clock and a high priority task delays the implementation of the second function. That could cause stopping the RTC for a long time. milliseconds or more. The sensible way of doing it which doesn't waste programmers time with obtuse programming requirements is to have functions which are optimised to set and get the time and data as a single package. This does two things, it forces the correct order (if required) and reduces housekeeping overheads, function parameter checking etc. All of the standard date formats such as microsoft, Julian data and unix epochs all combine the data and time in a single data entity and that is how HAL should handle them. Of course not all apps require both data and time the existing functions are fine for those cases. In my case I am taking a a unix time from the network converting it into the date and time fields of the RTC registers and then setting the registers using the HAL functions.
This is what RM0455 Rev 10 says about clock and calendar initialisation:
"To program the initial time and date calendar values, including the time format and the
prescaler configuration, the following sequence is required:
1. Set INIT bit to 1 in the RTC_ICSR register to enter initialization mode. In this mode, the
calendar counter is stopped and its value can be updated.
2. Poll INITF bit of in the RTC_ICSR register. The initialization phase mode is entered
when INITF is set to 1. It takes around 2 RTCCLK clock cycles (due to clock
synchronization).
3. To generate a 1 Hz clock for the calendar counter, program both the prescaler factors
in RTC_PRER register.
4. Load the initial time and date values in the shadow registers (RTC_TR and RTC_DR
and configure the time format (12 or 24 hours) through the FMT bit in the RTC_CR
register.
5. Exit the initialization mode by clearing the INIT bit. The actual calendar counter value is
then automatically loaded and the counting restarts after 4 RTCCLK clock cycles."
This is very good advice, it's a pity the HAL programmers didn't take it.
I can understand the need for use of the calendar and time on their own, but I would have thought most non-trivial apps would use both, so why not have functions that handle both at the same time. I don't think I have ever used the time or date of the RTC individually.
It took me about thirty minutes to combine the functions into one and I'm not the brightest star in the constellation of embedded programmers.
Best regards
Rob
@TDK wrote:> Using HAL to set the time and date takes around 112 us when using both the data and time functions which provides plenty of opportunity for loss of time/data sync especially if there are other processes that can extend this out.
The RTC is stopped during initialization. Initialization is started in HAL_RTC_SetDate and exited in HAL_RTC_SetTime. As long as you're calling them with a consistent date/time, there's no chance for desync.
The documentation should be improved to note that they must be called in the correct order (first HAL_RTC_SetDate then HAL_RTC_SetTime).
Look at the RTC_ISR_INIT bit to see how this is handled.
