cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a known STM32F091 leap year RTC problem?

LClem.1
Associate II

If I set the RTC (on a STM32F091) to Feb 28th 11pm, I can see that the RTC is correctly set. I can watch the RTC increase each second. However, when Feb 29th, 12:00 am is reached, the calendar date is changed to March 1, 2020; it skips Feb 29th. This chip is supposed to have compensate for leap years.

"Compensations for 28-, 29- (leap year), 30-, and 31-day months are performed automatically. ", from DocID018940 Rev 9

I also don't see any relevant RTC initialization restrictions listed in the STM documents; such as the RTC must be set 2 days prior to a leap day, in order for the calendar RTC to be updated correctly.

Can anyone confirm that setting the RTC within 24 hours of a leap day causes an incorrect RTC calendar result when the RTC transitions to the next day? If so, where is it documented?

1 ACCEPTED SOLUTION

Accepted Solutions

> RTC_DR= 0x0050C228

This is 2050 not 2020, and 2050 won't be a leap year. The RTC is 2000-based, not 1970-based.

Truth is, that I can't find this to be mentioned anywhere in the manual, and given 1970 is a relatively commonly used epoch, the confusion is understandable.

@Imen DAHMEN​  , can please this be mentioned in the RTC chapters in the STM32 RMs, possibly at the description of RTC_DR register? Thanks.

JW

View solution in original post

7 REPLIES 7

Don't know, the RTC hardware is simplified as every year divisible by 4 in the 1901 to 2099 range is a leap year, so I'm hard pressed to see that 2020 would be any more prone to failure than 2016 or 2024

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
LClem.1
Associate II

So my expectation is correct; the RTC should have transitioned to Feb 29th instead of the March 1?

Also, is it correct to say that there is no configuration (bit, flag, etc) for leap day? Just wondering if I missed some odd register setting or initialization process.

However, this problem is repeatable. After setting the RTC to a time such that the RTC should advance to Feb 29th within the hour, the month/day advance to Mar 1 instead. I am running experiments to see if there is a time boundary (set the time 24 hours, 48 hours prior to the transition), but these tests won't be complete for a while.

Also wondering if anyone else has tried to set the RTC on Feb 28th which resulted in a whole day being skipped as time advanced.

Read out and post content of the RTC registers before and after the transition.

JW

LClem.1
Associate II

BEFORE TRANSITION:

RTC_CR= 0x00001110

RTC_ISR= 0x00000037

RTC_TR= 0x00235852

RTC_DR= 0x0050C228

RTC_SSR= 0x000000B1

{

 "response": {

  "status": 0,

  "reason": "success",

  "year": 2020,

  "month": 2,

  "day": 28,

  "hours": 23,

  "minutes": 58,

  "seconds": 50

 }

}

AFTER TRANSITION:

RTC_CR= 0x00001110

RTC_ISR= 0x00000037

RTC_TR= 0x00000008

RTC_DR= 0x0050E301

RTC_SSR= 0x00000045

{

 "response": {

  "status": 0,

  "reason": "success",

  "year": 2020,

  "month": 3,

  "day": 1,

  "hours": 0,

  "minutes": 0,

  "seconds": 8

 }

}

> RTC_DR= 0x0050C228

This is 2050 not 2020, and 2050 won't be a leap year. The RTC is 2000-based, not 1970-based.

Truth is, that I can't find this to be mentioned anywhere in the manual, and given 1970 is a relatively commonly used epoch, the confusion is understandable.

@Imen DAHMEN​  , can please this be mentioned in the RTC chapters in the STM32 RMs, possibly at the description of RTC_DR register? Thanks.

JW

turboscrew
Senior III

"The RTC is 2000-based, not 1970-based."

Very good to know!

Thank you!