UI flickering resolved, but unclear how (ITM/DWT?)

[etamarin]

I am in a pretty strange situation here.

I have an application using FreeRTOS and TouchGFX. This application occasionally sees screen flickering. I have tried different ways to mitigate it but have been unsuccessful until recently.

I tried enabling ITM and DWT to use the CYCCNT counter and ITM port 0 for some debug messages. I perform a print through the ITM port every 500 ms or so.

As far as I can tell, the addition of printing through the ITM port has reduced the flickering significantly. I have switched between my commits and this is pretty much the only change that's led to this improvement.

Personally I find this counterintuitive, as the printf call could only make things worse in terms of timings and memory accesses. However, this is not what I observe and so my questions are as follows:

• Is there any process by which enable the ITM/DWT debug frameworks could make the screen flickering issue disappear?
• Is there a good way to calculate timings for TouchGFX related processes and memoery accesses to compare the performace before and after?

Further information: I am using double framebuffer strategy (with animation buffer as well), LTDC, FMC is configured to use SDRAM bank 2 and has a 512Mbit memory connected to it. MCU is STM32H750.

Any help is appreciated.

[MM..1]

Your question lacks important info. How display mode single/double/partial buf , ltdc / spi / fmc ??? mcu?

[etamarin]

Double framebuffer (with animation buffer as well), LTDC, FMC configured to use SDRAM bank 2 and has a 512Mbit memory connected to it. MCU is STM32H750.

[Mohammad MORADI ESFAHANIASL]

Hello @etamarin ,

I personally haven't used ITM/DWT, but it seems that there is a timing issue between transferring the framebuffer to the screen and updating it especially in the case of double framebuffers. TouchGFX already has some dedicated pins for measuring the performance if you use the available TouchGFX Board Setup for the STM32H750-DK. You can access the documentation about it from here.  
Additionally, you can read about some general TouchGFX Performance tips available here .

I hope this helps you 

[etamarin]

Thanks for the answer - I unfortunately have to easy way to monitor the pins so i was trying to see if I can catch some related error flags like LTDC underrun.

The page you linked mentions reducing frame rate - any tips on how to do that? I believe I've read somewhere that it's necessary to increase the porch size but can't find the source anymore.

[etamarin]

@Mohammad MORADI ESFAHANIASL thanks for answer, see my other post in this thread as it didn't tag you properly. In short, I would appreciate any tips on reducing farmerate (porch size? something else?). Thanks.

[MM..1]

Primary contrl for framerate for RGB displays is LTDC pixel clock. Simply in clock config set PLL.

Too good is calculate actual frame rate FR= LTDCclk / (totalwidthxheight)

[Mohammad MORADI ESFAHANIASL]

You can enable the LTDC global interrupt to catch the underrun interrupt; however, it is not very helpful for measuring the performance. You can enable it from the Multimedia tab, LTDC -> NVIC Settings inside you STM32CubeMX project.LTDC global error interrupt

But, as our amazing friend @MM..1 mentioned, you can easily adjust the frequency of the LTDC signal by changing its clock speed from the Clock Configuration tab in the STM32CubeMX project.
Changing LTDC pixel clock

Additionally, if you wish to change the parameters of your LTDC (such as the porch dimensions), you can navigate to the same settings as for the interrupt. However, instead of selecting NVIC Settings, choose Parameter Settings.

LTDC parameter settings I hope this helps you.

[Mohammad MORADI ESFAHANIASL]

Hello @etamarin ,

Have you made any progress on this topic?

[etamarin]

Hi Mohammad,

Thanks for the follow-up - I did make some progress but it's still unclear to me what the reason for the flickering is.

I have managed to alleviate the issue. The method that did it is a series of repeated memory write operations in the D1 RAM region. 

As strange as it sounds it is true. By writing values to D1 RAM (specifically .bss section) regularly, the flickering disappears. My theory is that this resolves (or masks) some (perhaps timing related) interaction between the peripherals on the D1 matrix. In my application, the D1 matrix is generally quite heavily used so this would explain the flickering I am seeing during some flash/SD card intensive operations.

However, I have not been able to figure out the exact cause here.