RTC reset after 49 days

[DBhut.1]

Hello,

I am using STM32L412CBT6 MCU with STM32CubeIDE and STM32CubeFW_L4 V1.17.2.

I am using en.i-cube_lrwan for our project. I am using same structure of libraries used in this en.i-cube_lrwan package.

I am using below libraries for rtc:

1)rtc_if.c

2) rtc.c

3) stm32_systime.c

4) stm32_timer.c

I use the SysTimeSet() function for time sync, and to get time I used SysTimeGet() function.

For sync time, I have to send command through uart, containing current time, which will call SysTimeSet() function.

I have set date time of 13 January 2023 in all devices, and on today (3 March 2023), all devices shows time of 13 January 2023.

So, what causes this type of issue after 49 days?.

Please help us to solve this problem, this is very critical issue for us.

Thank You

[waclawek.jan]

How is VBAT connected? Was there a VDD failure? Is 13.Jan 2023 hardcoded in your program? Upon which conditions does your program set this datum into RTC?

JW

[Tesla DeLorean]

49 days is typically associated with 32-bit rollover of a milli second tick count. Bad logic and math can cause failures.

I​f it is critical, review and understand the code, all the source is available to you and your team.

[DBhut.1]

VBAT is connected to a coin cell. and there is not MCU reset happens after 13 Jan 2023 and works on 3.2V AA battery. and this date is not hardcoded, as mention in post, I have used uart command to set date and time.

We have reviewed the code, and doesn't find any issue with configuration.

and as In STM32L412 there is no 32bit counter for RTC, So there is n chances of 49 days overflow.

[Tesla DeLorean]

When doing math on time and dates make sure you have enough bits to carry the range of intermediate values, and the units used.

Probably not the RTC itself, but calendaring or computing of elapsed time.

Look Harder

Look Critically

[waclawek.jan]

Oh, so, do you actually read RTC or not?

JW

[DBhut.1]

RTC is read by below function:

SysTime_t SysTimeGet( void )
{
  SysTime_t calendarTime = { .Seconds = 0, .SubSeconds = 0 };
  SysTime_t sysTime = { .Seconds = 0, .SubSeconds = 0 };
  SysTime_t DeltaTime;
 
  calendarTime.Seconds = UTIL_SYSTIMDriver.GetCalendarTime( ( uint16_t* )&calendarTime.SubSeconds );
 
  DeltaTime.SubSeconds = (int16_t)UTIL_SYSTIMDriver.BKUPRead_SubSeconds();
  DeltaTime.Seconds = UTIL_SYSTIMDriver.BKUPRead_Seconds();
 
  sysTime = SysTimeAdd( DeltaTime, calendarTime );
 
  return sysTime;
}

In which Getcalender function points to below function:

uint32_t RTC_IF_GetTime(uint16_t *mSeconds)
{
  RTC_TimeTypeDef RTC_TimeStruct ;
  RTC_DateTypeDef RTC_DateStruct;
  uint32_t ticks;
 
  uint64_t calendarValue = RTC_GetCalendarValue(&RTC_DateStruct, &RTC_TimeStruct);
 
  uint32_t seconds = (uint32_t)(calendarValue >> RTC_N_PREDIV_S);
 
  ticks = (uint32_t) calendarValue & RTC_PREDIV_S;
 
  *mSeconds = RTC_IF_Convert_Tick2ms(ticks);
 
  return seconds;
}

[waclawek.jan]

How is SysTime_t defined?

What does SysTimeAdd() do?

> all devices shows time of 13 January 2023.

How do those devices show time?

As Clive said above, if you count delta time in milliseconds, rounding it down to 32-bits at any point results in wraparound after 49 days.

JW

[DBhut.1]

delta time is fixed time stored in rtc backup register(epoch time)

typedef struct SysTime_s

{

uint32_t Seconds;

int16_t SubSeconds;

}SysTime_t;

All deives have oled display to show date/time, and can synced only via uart command.

delta time is in seconds, which will wrapped in more than 140 years.

[waclawek.jan]

Then maybe the calculation inside RTC_GetCalendarValue() or SysTimeAdd() overflows.

JW