Why an STM32L476's RTC counts more than 24h and don't icnreases the day

[albert2]

I've designed a board that has a STM32L476.

This part is supplied using a triple system of dual battery + power ( when it is available)

We've manufactured more than 20k units of them and they are working ok

A few days ago 2 boards came back to our design lab that exhibit the following symptoms :

-> The RTC keeps counting past 23:59:59 until 39:59:59

-> Neither on 23h nor 39h rollover the day gets increased

-> When trying to set the time we get the following data:

If the time is less than 20h, 20h get added to it

Else the hour is correctly set

-> Rollover behavior don't changes

If we force a reset of the CPU, the problem dissapears.

More data:

-> The RTC access is done using HAL libs.

-> The RTC isn't reset when setting the date/time

We still have one untouched board for testing, but any try to use a debugger would trigger a CPU reset, making the probblem dissapear. (This is why we lost ont of the boards )

Does anybody have a hint about what the problem could be ?

[IGtti]

Yes the sDate and sTime variables are local. My application uses FreeRTOS and these variables are declared outside the forever loop. In this case I understand the initialization is called only once, right?

That is the reason I am adding the parameters initialization inside the forever loop, just before the date and time update.

I am following the discussion here about root cause related to uninitialized parameters...

My problem is exactly the same as in this thread, RTC is counting more than 24h...

My hardware is the STM32L433CB.

Thank you,

Iaran

[waclawek.jan]

Details do matter. If the structs are initialized to zero and then never changed (except the time and date itself), the "problematic" fields remain to be zero so they should not cause problem even without the explicit zeroing.

JW

[IGtti]

How can we address this topic to the ST HAL development team? A correction could be implemented directly in the HAL code.

I see there are other HAL structs, for ADC, UART, I2C... Is this initialization issue also present in those structs?

Thank you,

Iaran

[waclawek.jan]

Root of the problem is, that users call the Cube/HAL functions with incorrectly set parameters (struct fields - having them as uninitialized local variables is only one way how they can be set incorrectly).

I don't understand how could Cube/HAL fix something which is user error.

JW

[IGtti]

It seems I misunderstood the answer from @albert2​, saying the "The HAL lib doesn't mask the bit fields before writing the data to the RTC registers".

For me it was some HAL Lib problem.

If the solution is just to initialize ALL struct members than it should be fine for my application now.

Orinally, I was not using/not updating these two parameters: SubSeconds and SecondFraction.

Do you think this could be the reason for the RTC hours counting going more than 24h?

Thanks.

EDITED: Just happened again. Today morning I see the hours showing 26! I still don´t get real root cause for this problem...

[waclawek.jan]

> It seems I misunderstood the answer from @albert2 (Community Member)​, saying the "The HAL lib

> doesn't mask the bit fields before writing the data to the RTC registers".

> For me it was some HAL Lib problem.

I am not really willing to discuss Cube/HAL issues, I don't use it and I think it's simply a waste of time.

Nonetheless, masking bitfileds won't help with uninitialized struct fields as they may have unwanted ones (note, uninitialized means random content) at the places which are unmasked.

> Just happened again. Today morning I see the hours showing 26!

> I still don´t get real root cause for this problem...

The very first thing to do when you encounter this sort of problems is to read out and check the RTC registers content.

Then check all places where you write into RTC, whether all registers are written as intended. Note, that at this moment you should consider Cube/HAL code as your own and debug it as such.

JW

[gbm]

For me, one of the more serious sources of the problem is the way in which CubeMX creates the code and how HAL examples are written in all the ST demos.

This is an example of the error-prone ST style:

  GPIO_InitTypeDef GPIO_InitStruct = {0};
 
  /*Configure GPIO pin : CEC_CK_MCO1_Pin */
  GPIO_InitStruct.Pin = CEC_CK_MCO1_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  GPIO_InitStruct.Alternate = GPIO_AF0_MCO;
  HAL_GPIO_Init(CEC_CK_MCO1_GPIO_Port, &GPIO_InitStruct);

And that's how it should be written to educate the users:

  static const GPIO_InitTypeDef GPIO_InitStruct = {
  /*Configure GPIO pin : CEC_CK_MCO1_Pin */
  .Pin = CEC_CK_MCO1_Pin,
  .Mode = GPIO_MODE_AF_PP,
  .Pull = GPIO_NOPULL,
  .Speed = GPIO_SPEED_FREQ_LOW,
  .Alternate = GPIO_AF0_MCO
}
  HAL_GPIO_Init(CEC_CK_MCO1_GPIO_Port, &GPIO_InitStruct);

This way:

• init structure uses Flash, not RAM
• all the non-initialized explicitly fields are guarateed to be 0

There is one problem with this approach. Most of HAL creators don't understand the importance of const specifier in pointer-to-structure arguments, so most of HAL functions don't like constant arguments which they incorrectly believe to be variables. This is a well-known serious issue of HAL code.

[jea74]

I have the same problem with a B-U585I-IOT board.

Days never increase and hours keep increasing...

Try all the above suggestions... none worked

Something new ?

thanks

[jea74]

Sorry, this works:

sDate.WeekDay = RTC_WEEKDAY_WEDNESDAY;
sDate.Date = 31;
sDate.Month = RTC_MONTH_DECEMBER;
sDate.Year = 23;
 
sTime.SubSeconds = 0;
sTime.SecondFraction = 0;
sTime.TimeFormat = RTC_FORMAT_BIN;
sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;
sTime.StoreOperation = RTC_STOREOPERATION_RESET;
sTime.Hours = 23;
sTime.Minutes = 59;
sTime.Seconds = 55;
 
__HAL_RTC_WRITEPROTECTION_DISABLE(&hrtc);
RTC_EnterInitMode(&hrtc);
if (HAL_RTC_SetTime(&hrtc, &sTime, RTC_FORMAT_BIN) != HAL_OK) {
	printf("Error Setting Time !\n");
}
if (HAL_RTC_SetDate(&hrtc, &sDate, RTC_FORMAT_BIN) != HAL_OK) {
    printf("Error Setting Date !\n");
}
RTC_ExitInitMode(&hrtc);
 __HAL_RTC_WRITEPROTECTION_ENABLE(&hrtc);
 
HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DR0, 0x1234); // Date & Time are set

The day, month & year are incremented 5 seconds later

[fatih7490]

void Set_RTC_Date_And_Time(Date_And_Time_Typedef *dt)

{

dt->Timeout_Counter = 0;

Set_RTC_Time(&dt->The_Time);

Set_RTC_Date(&dt->The_Date);

__HAL_RTC_WRITEPROTECTION_DISABLE(rtc_ptr);

RTC_EnterInitMode(rtc_ptr);

rtc_ptr->Instance->CR = 0;//CR_Old & 0xFFFFFFDF;

RTC_ExitInitMode(rtc_ptr);

__HAL_RTC_WRITEPROTECTION_ENABLE(rtc_ptr);

HAL_RTCEx_SetWakeUpTimer_IT(rtc_ptr, Calculate_WakeUp_Counter_Value(5000), RTC_WAKEUPCLOCK_RTCCLK_DIV16,0);//todo

Set_RTC_Alarm_For_Next_Second(dt);

}

void Get_RTC_Date_And_Time(Date_And_Time_Typedef *dt)

{

Get_RTC_Time(&dt->The_Time);

Get_RTC_Date(&dt->The_Date);

dt->Raw_UnixTime = Date_Time_To_UnixTime(dt);

// --------------------------------------------------------------------------------------------------------

Update_Log_Time(dt->Raw_UnixTime);

// --------------------------------------------------------------------------------------------------------

static uint8_t second_1 = 0;

static uint8_t hour_1 = 0;

if(second_1 != dt->The_Time.Seconds)

{

second_1 = dt->The_Time.Seconds;

sprintf(dt->Time_Str," %02u:%02u", dt->The_Time.Hours,dt->The_Time.Minutes);

sprintf(dt->Time_Sec_Str," %02u", dt->The_Time.Seconds);

}

if(hour_1 != dt->The_Time.Hours)

{

hour_1 = dt->The_Time.Hours;

sprintf(dt->Date_Day_Month_Str,"%02u-%02u", dt->The_Date.Date,dt->The_Date.Month);

sprintf(dt->Date_Year_Str," 20%02u", dt->The_Date.Year);

}

}

void Set_RTC_Date(RTC_DateTypeDef *sDate)

{

sDate->WeekDay = Get_Weekday_of_Date(sDate);

if (HAL_RTC_SetDate(rtc_ptr, sDate, RTC_FORMAT_BIN) != HAL_OK)

{

//_Error_Handler(__FILE__, __LINE__);

}

}

void Set_RTC_Time(RTC_TimeTypeDef *sTime)

{

sTime->DayLightSaving = RTC_DAYLIGHTSAVING_NONE;

sTime->SecondFraction = 0;

sTime->SubSeconds = 0;

sTime->TimeFormat = RTC_HOURFORMAT_24;

sTime->StoreOperation = RTC_STOREOPERATION_RESET;

if (HAL_RTC_SetTime(rtc_ptr, sTime, RTC_FORMAT_BIN) != HAL_OK)

{

//_Error_Handler(__FILE__, __LINE__);

}

}

This code solved my problem. Basically, Set CR register 0, after setting the time and date, then restart your alarm or wakeup timer if you need to.