RTC with FreeRTOS and TouchGFX

[ktrofimo]

Hello everybody!

Have asked this as a comment in another thread (https://community.st.com/s/question/0D50X0000BvkqIZSQY/inexplicably-slow-rtc?t=1622663635692), but decided to make a separate question in this group.​

So far I was able to run STM32H743 (rev V) with FreeRTOS, LWIP and TouchGFX. Now I was trying to get TouchGFX show RTC clock and I stuck. 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.

How did you measure LSE? Don't measure on crystal, but output it to MCO and measure there.

Try without TouchGFX exercise the individual peripherals, or, conversely, while running TouchGFX, try to disable individual peripherals.

Observe power supply voltage (using oscilloscope), comparing working and non-working case. Review power and ground routing, with regard to unwanted common paths or crosstalk to LSE tracks.

JW

[ktrofimo]

Ok, here is some progress: MCO output of LSE shows that frequency breaks when there is some changing data (random color) on line R6 (RGB565=0x4000) and it does not depend on TouchGFX - waveform breaks if I manually fill buffer with random data. All other LTDC bits are not influencing MCO at all.

But another problem is that R6 line is far away from LSE quartz:R5 & G6 line - the only ones that are going near the LSE quartz do not affect clock al all:

[waclawek.jan]

Where is the buffer? In external memory? Then consider the data line which corresponds to R6.

As a different kind of test, toggle R6 (or any other pin that might be suspicious) as GPIO.

JW

[ktrofimo]

Yes, this exactly is what I ​was going to check next

[waclawek.jan]

Is it FMC_D30 next to one of the LSE pins?

JW

[ktrofimo]

Exactly. FMC_D30 is a problem. And there is no alternatives for both LSE and D30. Only these pins.

[waclawek.jan]

I presume you've already checked those two pins for direct short. Thoroughly wash the board, use a needle to clean the space between the pins. Decrease the GPIO_OSPEEDR setting for FMC_D30.

Again review the ground connection from the decoupling capacitors to the nearest ground pin. Avoid common ground paths especially with the memory - remove capacitors from the bottom side of board and "air-mount" them on the top, connecting thin ground wire directly to the nearest ground pin of mcu.

JW

[ktrofimo]

Yes, I have checked everything, and everything seems to be okay. But it looked like nothing helped. Suddenly I have noticed that everything is working fine... Why? Checked everything again I found that LSE drive really helps. The only thing - this​ setting is applied after power restart (RTC domain should be restarted?), but not during debugger restart. Also, according to H7 errata "medium low" and "medium high" are swapped.

[waclawek.jan]

> this​ setting is applied after power restart (RTC domain should be restarted?), but not during debugger restart.

I don't use the 'H7. The LSEDRV bits description in RM is characteristically sloppy (The driving capability can be changed dynamically from high drive to medium high drive, and then to medium low drive.) without explaining how this, or any other change of LSEDRV relates to other backup domain bits (namely LSEON/LSERDY, or maybe RTCSRC).

JW