STM32F7 LTDC Flickering

[ekondratiev]

Posted on September 20, 2017 at 14:39

Hello! I've encountered a very strange bug with STM32F7 (767 and 746) LTDC. It seems, that FPU operations sometime cause LTDC flickering (sync miss or something). It rather difficult to debug this issue because the display flickers ocasionally and flickrs become rather rare under debuger step-by-step run. I've checked all interrupts and their priorities - everything is OK. Moreover, LTDC itself doen's use the interrupt. It just reads data from SDRAM and generates the scanning. In normal circumstancec it works absolutely clear.

But I've found the reason of the glitches for STM32F746. It is a double to float conversion function. But it happens not all the time. When I turned all ariphmetics to floats (added 'f' after all float constants, use sinf, cosf and other __f funtions) the flickering was gone.

Now I have the same issue on 767 (with double precision FPU). And here I can't solve the problem with just a single precision compilation.

I use FreeRTOS and 5 tasks and a lot of different peripherals (I2C, SPI, FMC, UART, GPIO, SDIO, timers and so). In both cases LTDC video memory is located in SDRAM connected thru FMC. I think that it could be reason of FreeRTOS task switching with FPU context. Moreover, it seems that display doesn't flicks (or flickrs very rare) when only 4 tasks run.

Can't imagine where I'm wrong and how to deal with it. Can somebody help me with that?

#stm32f7 #stm32f767 #stm32f746 #ltdc

[waclawek.jan]

Posted on September 20, 2017 at 14:43

You are hitting the bandwidth limitations of the bus matrix. Decrease resolution or color depth. Decrease burden on the FMC (i.e. reduce other use of SDRAM or any other memory connected to FMC or QSPI).

JW

[ekondratiev]

Posted on September 20, 2017 at 15:11

I've found the same question on uGfx board - 

https://community.ugfx.io/topic/818-deterministic-periodic-display-glitch-on-stm32f7xx-ltdc-driver/

 

And when I've turned off the D-Cache - the glitches were gone. But FPS also went down...

[ekondratiev]

Posted on September 20, 2017 at 14:47

Hello! It seems no. No other use of SDRAM here. If I would access it during the LTDC refresh it will flicker very intensive. And flickering becomes faster (more often) when FPU is used intensively. Moreover, it completely gone for 746 when I've switched the ariphmetics to single precision.

[waclawek.jan]

Posted on September 20, 2017 at 15:31

> And when I've turned off the D-Cache - the glitches were gone. But FPS also went down...

Do you cache also FMC/SDRAM? Do you write to the SDRAM from processor?

JW

[waclawek.jan]

Posted on September 20, 2017 at 18:39

All these operations are synchronized so there is no concurrency access to SDRAM.

So the LTDC is stopped while you draw the graphics and then copy using DMA2D?

Please, elaborate.

JW

[ekondratiev]

Posted on September 20, 2017 at 18:09

I turn D-Cache on with the standard CMSIS function (SCB_EnableDCache). Don't know about FMC/SDRAM cache. And yes, I write to SDRAM directly from CPU (SDRAM is memory mapped to 0xD0000000). I draw the graphics in it and than copy it with DMA2D to the screen buffer. All these operations are synchronized so there is no concurrency access to SDRAM. For instance, if I would write to SDRAM in other task in parallel I will receive heavy screen flickering all the time.

It seems to me that it is some strange internal CPU overload for some operations like FPU or context switch. And in this particular overload tick LTDC skips its scan/refresh cycle. Flickr could happen once in a minute or 20 minutes, or 5 times per second. It depends on, I think, instructions sequence. For example, on 746 it was a situation where I clear the rectangural area in black and than write some digits in white and it heavy glitches, but when I clear the same area in blue - it works fine. It sounds crazy but it was.

Moreover, on 767 with double precision flickrs happen much rarely than when the program was compiled with single precision.

Now I know that disabled D-Cache helps. But application speed is slow. I need to optimize it.

And I plan to change all the ariphmetics to soft FPU and try.

[ekondratiev]

Posted on September 21, 2017 at 13:24

Hello! No, LTDC generates data refresh all the time. If it would stop, the display goes black. LTDC works even if CPU stoped in debugger mode.

DMA2D synchronizes cycles so the image update happens in between of the frames and no image flickering happens here.

I think that is is the data cache. I will read some manuals (AN4861 and AN4839) and test than. Will write here the results.

[markus239955_stm1_stmicro_com]

Posted on October 23, 2017 at 16:46

If your floating point calculations are part of your screen rendering, the D-Cache accelerates your code, but may delay the content of your screen. Flush the D-Cache with SCB_CleanDCache(); after you finished your Screen calculations and before you swap the Screen buffers.

Had the same Problems with STM32F7, same code worked fine on a STM32F4.

[Tran Minh Cong]

Posted on April 02, 2018 at 08:27

Dear everybody,

I want ask about FPU.

How to enable to use FPU in STM32F746BGT6?

How is configure FPU accuracy and MCU can run faster?