Graphic distortion when accessing SRAM?

[lpcware]

Content originally posted in LPCWare by tjoAG on Tue Aug 07 02:07:02 MST 2012
Hi All

I'm using a LPC1788 at 120 MHz, with a 16 bit SDRAM and 16 bit SRAM

The frame buffer is located in the SDRAM and I use the SRAM for some persistent data.

When I access the SRAM with relative large memory amount (+300 bytes memcpy), the display has graphics distortion. It looks like it draws shadows of the text displayed.

I guess the EMC is busy accessing the SRAM and the LCD DMA transfer is blocked.

I could split my SRAM access into smaller pieces or use DMA access to the SRAM.
That may help?

Speed up SRAM/SDRAM timing?

But is there any other solutions or am I just doing things wrong.
I'm using FreeRTOS.

Thomas

[lpcware]

Content originally posted in LPCWare by mc on Mon Aug 20 10:48:39 MST 2012
Hi Thomas,
Can you increase LCD DMA's priority?

[lpcware]

Content originally posted in LPCWare by tjoAG on Fri Aug 17 00:38:01 MST 2012
Hi


Doing a simple for-loop did not help.. Same thing

I changed the timing param for the SRAM to make the access a bit faster and lowered the LCD CLK. That did help a lot

But I guess it all just depend on the data size I do copy to the SRAM. Then I will see the distortion again?

The data I need to read/write from the SRAM is not very speed depending, so I will make some SRAM memory function that do read/write in chunks to minimize the memory bus load.



Thomas

[lpcware]

Content originally posted in LPCWare by wellsk on Thu Aug 16 07:07:13 MST 2012
LCD refresh from SDRAM and memmove to SRAM both use the same external memory bus.
If your memmove operation takes too long, the LCD refresh cycle will be delayed too long and the LCD will appear to glitch. Depending on your LCD pixel clock rate and color depth, the LCD must get data at a minimum rate. Longer operations on the external memory bus like long stack push/pop sequences, memmove/memcpy functions (which use LDM/STM burst), or extended operations to a slower memory peripheral can stall the LCD refrsh long enough for this to happen.

It sounds like your SRAM is slower than SDRAM if the memmove works ok with SDRAM. Instead of moving data to SRAM via a memmove/memcpy function, try moving the data via a simple for-loop to see if the issue goes away. memmove/memcpy are typically optimized to use LDM/STM burst with sizes of 16 bytes of more, so the external memory controller will be unavailable to the LCD controller for that SRAM burst.

[lpcware]

Content originally posted in LPCWare by tjoAG on Thu Aug 16 06:42:50 MST 2012
Hi Dave

I has no effect changing the EMCDLYCTL register.
As soon I try moving approx. 30 byte or more to the Static RAM, the graphics does get destored!.

I'm running 60 MHz on the EMCCLK.

Does the SRAM memcpy really takes so long that the LCD controller frame-buffer access get interrupted?

Could the static part of the EMC be configured wrongly?
If I copy the data to the SDRAM (just for test) the graphics does not get destored.

So seems to be an issue with the EMC static/dyn controller and LCD DMA access?

Thomas

[lpcware]

Content originally posted in LPCWare by Dave on Sun Aug 12 17:16:29 MST 2012
Try increasing the values for both the feedback clock and the command outputs when you setup LPC_SC->EMCDLYCTL