STM32F407 RTC Daylight Savings bug or feature?

[dave23]

Posted on May 28, 2018 at 23:06

I'm currently trying to sync the clock on my STM32F407 using the time from an NTP time server. The time server always responds in UTC time format without any daylight savings whatsoever. So I tried using the ADD1H bit of the RTC_CR register to add 1H to the clock on summer time, instead of doing it in software, and works just fine, except during a specific time frame.

When I sync my clock between 23h00 and 23h59, the ADD1H bit adds one hour to the clock, but the days don't increment. 'Day of the week' doesn't increment, and neither does 'day of the month'. It looks like this process of incrementing days only happens when the clock rolls over from 23:59:59 to 00:00:00 (I'm working with 24H time), like the seconds register rolling over to 00 triggers the whole process, instead of being like a cascade that each register rolling over triggers the next.

I was wondering, is that a bug? In which case is there any known work-around to this problem, besides doing it all manually in software? Preventing the system to sync during this time frame is not an option, because the system can be turned on at any given time, after having it's backup supply removed and the RTC reset, so it needs to be synced at power up.

I understand that daylight savings are usually applied at 02h00 - 03h00 so there's no way the clock would roll over / under to change the calendar day at that time, so is it a feature that the RTC module on the STM32 was only meant to be used that way (in offline mode)?

Thanks in advance for your suggestions

[waclawek.jan]

Posted on May 28, 2018 at 23:29

The RTC is relatively simply implemented. Think of how much more logic would it need to have should it implement the day/month/year increment (and of course also decrement) in addition to the rollover. Think about the silicon area = cost; and the power consumption this would impose.

Take it as it is, an imperfect implementation. Keep it in one mode all the time. Do all your time shifting in software - and the easiest way is to convert to epoch time, do the shift, then convert back. Been there, many of us here. It's been commented several times that a plain counter might be better in many cases, but we have to live with whatever available.

JW

[dave23]

Posted on May 29, 2018 at 22:12

Thanks for your comment!

It helps to know the limitations of the hardware you're working with. It saves you alot of time otherwise wasted trying to have it do something it just can't. I've always used it the 'proper' way before, but since it's the first time I try to mix NTP and the STM32's RTC together, I was hoping to be able to do something fancy with it!