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.

[Tesla DeLorean]

Posted on July 06, 2018 at 16:51

What is stm32f49xxx? You mean F429 or F469?

Is your external bus 32-bit wide?

How large (resolution) is the screen and frame buffer? Are you using multi-frame buffers? You don't have to get far to get into the 54-60 MHz bandwidth and 100 MBps

Consider parts with more internal memory, and DSI.

L4+ Series?

[waclawek.jan]

Posted on July 06, 2018 at 16:54

Clive,

Consider parts with [more internal memory], and DSI.

I thought the MIPI/DSI module is just a hangoff on a very same LTDC as in the MIPI-less mcus, so it can't make a difference bandwith-wise... did I miss something?

Jan

[Tesla DeLorean]

Posted on July 06, 2018 at 17:19

DSI doesn't eat a shed load of pins, so the arguments for wide memory buses and pin utilization are easier to have.

I don't think the STM32 design and SDRAM are good at high pixel clocks. I had to buy a video card in around 2000 with a 250 MHz Video DAC, so I think the design here is pretty nut-less.

640x480 24-bpp @ 60 Hz -> 75 MBps, you need multiple frames, and expect to be able to render fast than you can raster.

Definitely not going to be able to render to a frame buffer in an SSD1963 faster than you can to SDRAM

[waclawek.jan]

Posted on July 06, 2018 at 16:51

No experience with this here, but have you read the related appnotes (

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Fapplication_note%2Fgroup0%2F25%2Fca%2Ff9%2Fb4%2Fae%2Ffc%2F4e%2F1e%2FDM00287603%2Ffiles%2FDM00287603.pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM00287603.pdf

This is a reocurring question here so you may want to search the forum.

JW

[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

[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

[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 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.