HAL RTC BUG

[malcolm2]

Posted on September 02, 2014 at 10:40

There appears to be a bug in the HAL drivers for the RTC.

I have only recently migrated to STM micros and am in the process of rewriting a number of projects to use them.  I have a project running on a STM32F405RG with 16MHz external crystal used as source for both main 160MHz system clock and RTC.

If the RTC is read using HAL_RTC_GetTime it will read a valid, and correct, time but subsequent reads only return the same time as the first read.

After many hours of head banging I have found a work around which is to read the date as well with HAL_RTC_GetDate even though the date is not wanted.  The RTC reads are then correct.

[Montassar BEN ROMDHANE_O]

Posted on September 02, 2014 at 11:04

Hi rook.malcolm,

This is not a bug. To have correct behaviour of your application, you must call the HAL_RTC_GetDate() after calling HAL_RTC_GetTime() API, in order to unlock the values in the higher-order calendar shadow registers.

Please find the @note within the HAL_RTC_GetTime() API header comment.

With regards.

[malcolm2]

Posted on September 02, 2014 at 11:30

Hi

I must disagree with you on this one.

Surely if you cannot read the time without also reading the date then this should be a single API call of say HAL_RTC_GetDateTime.

The note is also rather misleading in that it infers that it is only necessary to read the date if you want to unlock the higher-order calendar registers but does not state that GetDate MUST BE CALLED after GetTime.  Please at least make that clear!

[Montassar BEN ROMDHANE_O]

Posted on September 02, 2014 at 12:12

You're right, we'll take your feedback and suggestions into consideration, in order to highlight the correct usage of these APIs.

Thank you.

[danielbuga9]

Posted on November 30, 2017 at 09:07

Hello,

3 years later, HAL APIs still have separate GetTime/GetDate functions. Even though I'm aware that GetDate needs to be called after GetTime, I still frequently mess it up when I only need the time part... In my opinion an API should minimize the possibility of using it incorrectly. I get the reason (date should belong to the time that was read) but when there is only a single correct way to use something, why offer the possibility of use said thing in the wrong way? Documenting something is, in my opinion, not enough. HAL has enough issues as it is now, and leaving frustrating behaviour in does not help.