AnsweredAssumed Answered

Timing issues with sram and lcd on fsmc bank 1

Question asked by baka on Apr 29, 2014
Latest reply on Apr 30, 2014 by baka
I really hope someone has been down this road before :-)

I have a hard time getting my sram and lcd working together on fsmc bank 1. I use a STM3221G-EVAL for testing, with it's 16Mbit SRAM and a ILI9341 LCD. Both devices works ok independently, so I think I have got the timing correct.

LCD is located at 0x68000000 and SRAM is at 0x64000000

I get major trouble when I try to write to the LCD _from_ SRAM.  I figured it might be related to timing of the chip-select signal, so I tried to tweak the timing configuration. Suddenly I got both working togheter after tweaking BUSTURN and DATAST, and I could display some pictures stored in SRAM from my init code of the LCD.

I thought everything was ok, and that the BUSTURN adjustment made sense. Then I moved on to using the SRAM as buffer in my emWin code, but then all the problems came back, and I havent found the cause of problem yet.

The symptom is as follows: I make a region starting at 0x64000000 in my scatter file and put some images in there as well as the emWin extMem[] buffer. When I run my application with extMem[] in SRAM the display is corrupt and only some pixels are displayed correctly. If I tweak DATAST of both the SRAM and LCD I notice that a few more pixels are displayed correctly.

I can actually display some images stored in SRAM with emWin, but only as long as I dont put extMem[] in SRAM as well.

What do you think? Is this a problem caused by fsmc timing, or some bug/incompatibility in the emWin code when placing extMem[] in SRAM?

I have spent so much time debugging and looking at this from different angles, so I am probably ignoring some fundamental problem.

No interrupts are touching memory
A simple ram test routine verifies that ram is ok