Inexplicably slow RTC

[DWeie]

Hi,

I'm experiencing a curious issue with the Real Time Clock of an STM32F746BGT6. When running a legacy project, the RTC is every bit as accurate as I'd expect it to be. When running a new TouchGFX template I've generated for the hardware, the RTC loses about 5s for each minute. I've combed through the startup code and the data sheets and there doesn't seem to be a good explanation for why this is. In both cases I am setting up the clock to reference the LSE in the RCC initialization, and in both cases I am using the same values for the synchronous and asynchronous divisors within the RTC registers. In both cases the time is being read using calls to

      HAL_RTC_GetTime(&hrtc, &currentTime, RTC_FORMAT_BIN);

      HAL_RTC_GetDate(&hrtc, &currentDate, RTC_FORMAT_BIN);//necessary for next read

I can post more code if this would be helpful, but the RTC seems pretty uncomplicated so I'm not sure what I've missed. I cannot blame the hardware since, as I've mentioned, the RTC is dead accurate when running legacy firmware on the same exact board. Is there a way that the RTC could be "interrupted" where it stops counting for brief periods because something else is suspending the LSE? Is TouchGFX doing anything in the background that could cause an issue like this?

Thanks you for any and all input. We're pretty stumped right now.

Best,

Don

[waclawek.jan]

> I am setting up the clock to reference the LSE in the RCC initialization,

Regardless of what you think you set, the truth is in the registers. Just read them out (both relevant parts of RCC and RTC) and check - this sounds much like you're running out of LSI rather than LSE.

JW

[dbgarasiya]

double check your clock settings

[DWeie]

EDIT: Looks like I jumped the gun a little bit here. The value of RCC_BDCR is 0x8103 and the value of RTC_CR is 0x40. Both of these values are what I would expect and indicate the the RTC is running off of the LSE and the the LSE is stable. The original message is:

Thanks for the advice Jan. I followed your recommendation and printed the RCC_BDCR per your suggestion and, sure enough, the RTC is set to reference the LSI. It's a good reminder to examine your assumptions when something doesn't make sense. I'll be taking a look at how this came to be the case, but the code I'm using is

 PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_RTC;

 PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;

 if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)

 {

   Error_Handler();

 }

in the SystemClock_Config() function.

something seems fishy here.

Thank you again for your advice.

Don

[waclawek.jan]

You have a "working" and a "nonworking" code, so there must be some difference between them - again in the registers.

Or you make some mistake in reading out the RTC, interpreting its output, or is the difference related/aggravated by resetting the mcu often?

JW

[DWeie · Accepted solution]

After some time away I was able to circle back to this and found the issue. The issue ended up being the LSE_DRIVE setting. I was using the default, and on this hardware in particular it was necessary RCC_LSEDRIVE_MEDUMHIGH in order to get accurate timing.

Thanks for the help!

[waclawek.jan]

Thanks for coming back with the result. Please select you post as "Best" so that the thread is marked as solved.

JW

[ktrofimo]

Hello everybody!

Look like I have to take this issue back to live again.

I see exactly the same problem: STM32H743 (rev V) with FreeRTOS and RTC is working precisely (both with FreeRTOS [in a separate task] and without FreeRTOS [in a main while loop] ) until TouchGFX is started. Tried different task priorities - without success.

MCU is configured for LSE (BDCR->LSEON=1, BDCR->LSERDY=1, BDCR->RTCSRC=0x01 (LSE), BDCR->RTCEN=1 [BDCR=0x8103])

LSE itself is exactly 32.768kHz (oscilloscope measured)

But in my case setting LSE Drive to RCC_LSEDRIVE_MEDIUMHIGH (as well as any other value) does not help.

Reading RTC time from separate task at 1000ms intervals (osDelay(1000) ) log shows double values about every 5 seconds:

03.06.21 00:07:20

03.06.21 00:07:21

03.06.21 00:07:22

03.06.21 00:07:23

03.06.21 00:07:23 *

03.06.21 00:07:24

03.06.21 00:07:25

03.06.21 00:07:26

03.06.21 00:07:27

03.06.21 00:07:28

03.06.21 00:07:28 *

03.06.21 00:07:29

03.06.21 00:07:30

03.06.21 00:07:31

03.06.21 00:07:31 *

03.06.21 00:07:32

03.06.21 00:07:33

03.06.21 00:07:34

Same code with commented out TouchGFX task gives precise RTC clock at every second.​

I can't understand how CPU, even being busy within interrupts, can slow down RTC (in a separate domain with it's own clock)?

Any ideas why this happens and how fix it?

Thank you!

P.S.​ I have checked dividers while RTC is running slow: PREDIV_A=127 and PREDIV_S=32767. These are default values for 32,768kHz quartz and theoretically should give 1s CK_PRE frequency.

[waclawek.jan]

If there's no change in any of the RTC and LSE related registers - which you can check by reading them all out and comparing to the working case, one explanation may be problematic board design, where the LSE is influenced by any peripheral which gets activated by TouchGFX, e.g. electrical noise from display or its backlight, or from SDRAM - either from signals or through power/ground.

JW

[ktrofimo]

Thank you for idea, will check it tomorrow... I would be amazed if it is a PCB problem... PCB is 4 layer with separate PWR and GND layers, and LSE is just 5mm away from MCU.