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]

Update: 

It works, if I use

hrtc.Init.HourFormat = RTC_HOURFORMAT_12;

instead of

hrtc.Init.HourFormat = RTC_HOURFORMAT_24;

 

I wonder why.

[waclawek.jan]

> HAL_RTC_GetTime(& hrtc, ti, RTC_FORMAT_BIN);

> HAL_RTC_GetDate(& hrtc, da, RTC_FORMAT_BIN);

This doesn't look right, the second parameter should be a pointer to the time/date structure.

Cube/HAL is open source, so you can debug it as your code, while checking the actual RTC registers content.

JW

[awiernie]

It is correct, it is wrapped in a function:

 

HAL_StatusTypeDef RTCGetTimeAndDate(RTC_TimeTypeDef * ti, RTC_DateTypeDef * da)

[waclawek.jan]

OK so what are the contents of RTC registers before and after the "jump"?

JW

[waclawek.jan]

It dawned on me.

As I'm not US-based and use the normal 24h time, it took me some time to realize, that 12:59am is 00:59 in 24-h time, thus one minute after that is 01:00am i.e. 01:00.

In other words, the am/pm changeover happens at 11:59:59xm->12:00:00xm transition, not at 12:59:59xm->01:00:00xm.

JW

[waclawek.jan]

Decimal printout of registers is not very useful.

You haven't shown a hour transition: 65817 is 01:01:19 and 67128 is 01:06:38.

As I've said above, in the 12h timekeeping (i.e. when you have RTC_CR.FMT=1, as you do have in your setup), you have the following transitions:

11:59:59am +1sec = 12:00:00pm (noon)

12:59:59pm + 1sec = 01:00:00pm (13:00:00)

11:59:59pm + 1sec = 12:00:00am (midnight)

12:59:59am  +1sec = 01:00:00am (01:00:00)

and this explains what you've posted in your initial post, i.e. it's counterintuitive but completely OK.

JW

 

PS. You have RTC_CR.DCE=1. Do you really use the Coarse calibration?

[awiernie]

 

You think that I have RTC_CR.FMT = 1?

Where do you see it?

Is it 8403960 = 0x803BF8 above at the "CR" line?

 

 

I have corrected the TR before the jump above,  I have been too slow in the debugger and copied the value after the jump. Now it is TR = 1202225 = 0x125831 which is 12:58:31.

 

I don't use coarse calibration. But this will not be the problem here?

 

 

[waclawek.jan]

> You think that I have RTC_CR.FMT = 1?

> Where do you see it?

> Is it 8403960 = 0x803BF8 above at the "CR" line?

Yes.

> I have corrected the TR before the jump above, I have been too slow in the debugger and copied the value after the jump. Now it is TR = 1202225 = 0x125831 which is 12:58:31.

And, as I've said already, 12:59:59am +1sec = 01:00:00am so that's normal.

 

> I don't use coarse calibration. But this will not be the problem here?

As you are surprised by this bit being set, it's quite likely that the FMT bit has been set inadvertently, too (and I'm willing to bet that some of the other CR bits, too). Often it's consequence of using uninitialized local variables.

JW

 

[waclawek.jan]

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