external gram / vram / videoram - any experience?

[Beck.Karl-Michael]

Posted on July 06, 2018 at 15:50

Hello,

we are running a stm32f49xxx mcu with sdram which is used as a video ram.

now with higher product lines we have more traffic on the memory bus causing flickering. With code optimization we can reduce it but it appears again and again with every minor change we make in the stm32 application code.

as far as i understand the lcd controller requests in 60fps rates the data from for the picture from the sdram which interfers with the applications access to the sdram causing the flickering.

if we had a lcd controller with own framebuffer the flickering should disappear as the frame is buffered in the gram, right?

i just had a look on the solomon systech ssd1963...

Is there anyone who has experience with this issue, maybe can suggest a concrete model of lcd controller which works good with the stm32f49xxx? Some tips what i need to be aware off?

As far as i understand the gram should be adressable through the memory controller, in order dma2d can be used to transfer the frame to the gram. More 'major best practices' known for this?

Thanks so far.

[Beck.Karl-Michael]

Posted on July 09, 2018 at 15:54

jan waclawek,

yes i already searched the forum about flickering. some issues we allready reasearch for example the flickering occuring when doing double=&gtfloat conversion. [1]

since we dont have the equipment here to debug issues in the area of nanoseconds timing, i wanted the thread to be more about a external gram / gram inside the lcdc not primarly about flickering.

nevertheless regarding flickering:

one thing which points to the l.o.w. (level of weirdness -) ) is that by just enabling a software component the flickering disappears. we may just change some lines of code and with the next build the problem occurs again. of course this is not 100% for sure, but it seems so. today i extended the &39LoadGeneratorDebugComponent&39 to do some double=&gtfloat conversions and since i included (NOT excluded) the component in the build (even without activating it) the flickering disappears. 

We have 3 different kinds of flickering occuring independently of each other.

a) Heavy screen corruption after changing a value on the display. recovering immeadiately.

b) continuous high frequent flickering of dark gray colors (white and black stable)

c) &39swimming&39 of bright color areas.

[1] 

https://community.st.com/0D50X00009XkYgXSAV

[Tesla DeLorean]

Posted on July 09, 2018 at 17:48

>>buswitdh to SDRAM  is 32 bit.

Clocking at 90 MHz? Parts rated at 100, 133 or 166 MHz. Aggressive timing?

>>We have 800x480 px at 16bit pixeldepth with doublebuffer.

800x480@60Hz, >23 MHz Pixel clock, right?

Stack/Heap in CCMRAM

[waclawek.jan]

Posted on July 09, 2018 at 22:49

As I've said I have no first-hand experience with the LTDC/MIPI-DSI in STM32 (although have experience with video generaly). Some random thoughts:

-according to Tab.10 in AN 4861, you should be good with 23MHz pixel clock even if using 2 layers and DMA2D, even with some performance to spare (it says max. 37MHz for 2 layers with 32-bit SDRAM), which I believe should be enough for any processor access. Do you use 2 layers?

- do you have any other memory/device on the FMC?

- do you perform DMA (using the 'general-purpose' DMA units) to/from the SDRAM?

- Do you run code from the SDRAM? Do you have stack in SDRAM? I can't think of any other reason for

flickering occuring when doing double=>float conversion.

-

Heavy screen corruption after changing a value on the display. recovering immeadiately.

can't that be more like 'heavy screan corruption just before changing a value on display? That could be explained by timing being OK for static display but going beyond the margin when the inactive buffer is heavily accessed, possibly by DMA2D. If so, consider either using processor instead of DMA2D for moving data around, or making the heavy updates during blanking intervals

-

included (NOT excluded) the component in the build (even without activating it)

Do you have located the buffers at defined addresses? If not, adding code - which I assume may have variables located into SDRAM - may move the location of buffers, and move them to addresses which involve penalty when displaying from them -- read chapters 4.5.2 and 4.5.3 in AN8461

JW

[Tesla DeLorean]

Posted on July 10, 2018 at 01:29

Looking at my F7 DSI/HDMI panel settings I used for 800x480@60Hz 16-bpp, looks like I clocked the DSI at 230 MHz

Horizontal rate 31 KHz, Vertical rate 59 Hz, Pixel Clock 28.75 MHz (accounting for line totals)

Horizontal Total 928, Vertical Total 525

Would double check the SDRAM settings, make sure they are commensurate for the device being used, an not unnecessarily slow, or have excessively long bursts.

Perhaps chase down one of the FAE with experience with the graphics hardware?

https://www.st.com/content/dam/technology-tour-2018/chicago/post/T1_S3_EmbeddedGraphics_TT_Schaumburg.pdf

 

Some of the issues sound more like problems with the display, or back-light.

[Beck.Karl-Michael]

Posted on July 10, 2018 at 13:57

Thanks a lot for your tips.

Actually clives' hint to the 23-mhz pixel clock pointed to the solution. It was just the wrong timing of the pixel / ltcds clock which caused this issue.

Setting lcd-tft clock to 12 mhz did it.

It was intended to be 12 mhz in the basic clock-init-routines but it was overwritten by the displaydriver-init to be only 1 mhz.

This resulted in sporadic flickering depending on the build and the cpu/bus load.

Setting to 24 mhz it resulted in very heavy flickering.

A bit more and only pixel artefacts are visible.

However, with 12 mhz the heavy disruption is good, but the dark-gray-flickering is more. I need to check again that everything is properly set according to the spec of the display... But at least i found the relevant settings which causes this issue.

Regarding memory questions:

IRAM is used for stack.

SDRAM is used for heap.

[Beck.Karl-Michael]

Posted on July 10, 2018 at 14:04

Hi,

adding code - which I assume may have variables located into SDRAM - may move the location of buffers, and move them to addresses which involve penalty when displaying from them -- read chapters 4.5.2 and 4.5.3 in AN8461

Good tip, i guess you mean the thing that the adress of the screen buffer needs to be alligned at 4 bytes, right (addr modulo 4 must be 0)?

Actually the screen buffer is allocated from the heap. But the frame buffer allocator treats this. it always allocates some more bytes and alligns the allocated memory to suit this requirement.

[Beck.Karl-Michael]

Posted on July 10, 2018 at 15:06

It was intended to be 12 mhz in the basic clock-init-routines but it was overwritten by the displaydriver-init to be only 1 mhz.

Setting to 24 mhz it resulted in very heavy flickering.

The Freqs above. are wrong. I assumed a different PLLM.

Following Freq should be right 😉

With the ideal freq of 33.3 Mhz i still observed sporadic dark-gray flickering. So finally i set PixelClock to 41,6 Mhz which is in the upper area of the specified range for the display we use. With this it seems all flickering is gone.

Thanks for all your tips. Sometimes the cause is just obvious

🙂

[Beck.Karl-Michael]

Posted on July 11, 2018 at 19:00

Ok - just to sum it up - following where the problems:

1. The pixelclock was not in the specified range for the display.

2. The alignment of the dynamically screen buffers was not good according to Application note 4861, Chapter 4.5.2 (LCD-TFT display controller (LTDC) on STM32 MCUs)

When having a good adress alignment, i can increase pixelclock by 2 * PixelClockMax until the screen gets disrpupted. With bad adress alignment the pixel clock was decreased to ~5% of PixelClockMin causing instant flickering in the dark colors. But even with the pixel clock that low it occured the disruption - dependending on the build an depending on the actual adress of the dynamically allocated framebuffer.