Why RTC always count twice 00:00:00?

[Junde]

Hi guys:

I initialed the RTC of STM32F103C8T6 by cubeMx and enabled the RTC global interrupt.

 

 

void HAL_RTCEx_RTCEventCallback(RTC_HandleTypeDef *hrtc) /* second callback */
{
 RTC_DateTypeDef rtcDate;
 RTC_TimeTypeDef rtcTime;
 HAL_RTC_GetTime(hrtc, &rtcTime, RTC_FORMAT_BIN);
 HAL_RTC_GetDate(hrtc, &rtcDate, RTC_FORMAT_BIN);
 LOG_DBG("[20%02d-%02d-%02d(%d) ", rtcDate.Year, rtcDate.Month, rtcDate.Date, rtcDate.WeekDay);
 LOG_DBG("%02d:%02d:%02d] tick[%5d]\n", rtcTime.Hours, rtcTime.Minutes, rtcTime.Seconds, HAL_GetTick());
}

 

 

 I got the following output:

 

 

[2023-17-24(6) 23:59:58] tick[ 4140]
[2023-17-24(6) 23:59:59] tick[ 5175]
[2023-17-24(6) 00:00:00] tick[ 6210]
[2023-17-24(6) 00:00:00] tick[ 7245]
[2023-17-24(6) 00:00:01] tick[ 8280]
[2023-17-24(6) 00:00:02] tick[ 9315]

 

 

 It is clear that the time 00:00:00 is output twice, and we can see the ticks are different, and the data still keep 24, NOT change to 25.

So my questions are:

1. Why the time "00:00:00" output twice?

2. Why the date NOT be updated after 23:59:59?

Thanks.

[STOne-32]

Dear @Junde ,

Please have a look on the month also , 17 ? Should be in range 1-12.  
Hope it helps you.

ST1-32

[Junde]

@STOne-32 

Thanks for your reminder. I do ignore it.:rolling_on_the_floor_laughing:

I checked the code, and the reason is the MX_RTC_Init() function initials the RTC by BCD format: 

/* Coded in BCD format */
#define RTC_MONTH_NOVEMBER ((uint8_t)0x11)

 

[waclawek.jan]

The repeated 00:00:00 is probably consequence of the bizarre way how Cube/HAL handles calendar in 'F1. And I don't know the answer to question 2, but wouldn't be surprised if it turns out to be related. Also, do you use a genuine STM32F1xx, or a counterfeit clone (usually on a BluePill)?

'F1's RTC does not have native calendar, it's a simple counter. The "library" tries to keep it below seconds-equivalent of 24h, and when it detects it being above 24h, it decrements 24h from it and increments the date.

I am not going to find out the exact mechanism how this goes wrong in your case. You can look yourself, Cube/HAL is open source.

The remedy is in not using Cube/HAL at all, maintaining an epoch time in the counters, using a proper procedure to read them (see RM), and using standard C <time.h> facilities to calculate between epoch and calendar formats (with the Y2k38 caveat).

JW

[Junde]

@waclawek.jan Thanks for your help.

Thanks for @STOne-32 's reminder, after I change the date format from Binary to BCD, the date can be updated normally.