Graphic distortion when accessing SRAM?

5 replies [Last post]
tjoAG
Offline
Joined: 2012-05-30

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

0
Your rating: None

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Dave's picture
Dave
Offline
Joined: 2011-07-16

Try increasing the values for both the feedback clock and the command outputs when you setup LPC_SC->EMCDLYCTL

-Dave
"Basic research is what I am doing when I don't know what I am doing"

-Dave
"Basic research is what I am doing when I don't know what I am doing"

tjoAG
Offline
Joined: 2012-05-30

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

wellsk's picture
wellsk
Offline
Joined: 2011-05-17

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.

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

tjoAG
Offline
Joined: 2012-05-30

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

mc's picture
mc
Offline
Joined: 2012-05-21

Hi Thomas,
Can you increase LCD DMA's priority?

feedback