STM32F469: HAL_RTC_GetTime jumps from 12:59 to 1:00 instead 13:00 or 1:00 pm

[awiernie]

I get the time in one thread with following code:

RTC_TimeTypeDef ti = {0};

RTC_DateTypeDef da = {0};

HAL_RTC_GetTime(& hrtc, ti, RTC_FORMAT_BIN);

HAL_RTC_GetDate(& hrtc, da, RTC_FORMAT_BIN);

It jumps from 12:59 to 1:00 instead 13:00,

With another project which uses an older firmware and different pcb but same MCU this does not happen.

Can this be a probem in the Cube Ide HAL 1.28.1?

Or a problem with the RTC itself? I have only one prototype yet, but I will check next week with other prototypes.

HAL_RTC_GetTime contains the following code:

sTime->Hours jumps from 13 to 1 but sTime->TimeFormat remains 0.  

I use 24 hours, but even if the settings would be 12 hours, the sTime->TimeFormat should be set after going from a.m. to p.m.

sTime->Hours = (uint8_t)((tmpreg & (RTC_TR_HT | RTC_TR_HU)) >> RTC_TR_HU_Pos);

sTime->Minutes = (uint8_t)((tmpreg & (RTC_TR_MNT | RTC_TR_MNU)) >> RTC_TR_MNU_Pos);

sTime->Seconds = (uint8_t)( tmpreg & (RTC_TR_ST | RTC_TR_SU));

sTime->TimeFormat = (uint8_t)((tmpreg & (RTC_TR_PM)) >> RTC_TR_PM_Pos);

The jump happens also if I  set the time to 12:59 and afterwards put the MCU some minutes into power saving mode. I am not sure if the jump happens in the RTC (but worked previously) or after initialising and restoring the RTC backup.

[awiernie]

In the meantime I have power cycled the device and the problem disappeared.

An there was also an uninitialised variable once there:

RTC_TimeTypeDef ti = {0};

RTC_DateTypeDef da = {0};

HAL_RTC_GetTime(& hrtc, ti, RTC_FORMAT_BIN);

HAL_RTC_GetDate(& hrtc, da, RTC_FORMAT_BIN);

ti and ta had not been initialised, but this should not have an influence on the internal RTC storage.

I wonder why the setting is not corrected on startup (w/o power cycle).

rtc handle hrtc is a global variable which is initialised to 0:

  RTC_HandleTypeDef hrtc; 

MX_RTC_Init sets:

 hrtc.Init.HourFormat = RTC_HOURFORMAT_24;

it calls:

HAL_RTC_Init

In that function there is:

/* Check whether the calendar needs to be initialized */

 if (__HAL_RTC_IS_CALENDAR_INITIALIZED(hrtc) == 0U)

Within this if, the CR would be set:

 hrtc->Instance->CR |= (uint32_t)(hrtc->Init.HourFormat | hrtc->Init.OutPut | hrtc->Init.OutPutPolarity);

The problem was, that the hour formate was not set because __HAL_RTC_IS_CALENDAR_INITIALIZED delivered true.

Why the odd value of the CR came into it, don't know.

[waclawek.jan · Accepted solution]

You correctly don't change the RTC settings once set up and running, but if incorrect bits in CR get set, they remain set until the next backup-domain reset (battery removal, or explicit backup-domain reset for whatever reason).

> Why the odd value of the CR came into it, don't know.

It's usually consequence of uninitialized struct in calling HAL_RTC_SetTime() where the DayLightSaving and StoreOperation fields are OR-ed to RTC_CR.

As I've said in the pointed-to article, it may be also consequence of the backup-domain brownout, if that's a possibility in your hardware setup.

JW

[awiernie]

Calling HAL_RTC_SetTime() used a local RTC_TimeTypeDef, which was uninitialised.

[waclawek.jan]

Thanks for coming back with this information.

JW