Timing issues with sram and lcd on fsmc bank 1

[bk]

Posted on April 29, 2014 at 15:13

Hello

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

[bk]

Posted on April 30, 2014 at 10:27

Another set back today.  Can't even display an image in my test-code, the lcd only shows the first 50 rows or so. Previously I solved this by some minor changes to the BUSTURN and DATAST, but this doesnt have any effect now.

Now this is strange; If I read from the same 100 bytes in sram over and over and write these to the LCD everything works, but if I loop through 153600 bytes and write them to the LCD it stops displaying data after some rows. What can be the cause of that? I'm not so sure it's related to timing. The only thing that is different from reading 153600 different bytes  and the same 100 bytes over and over is the change of address lines. hmmm And I know my LCD code is correct, because if works flawlessly if the data is stored in internal memory. Initially I thought it might be some cache exhaustion, but when I checked with a logic analyzer the mcu isnt caching sram reads,

[bk]

Posted on April 30, 2014 at 13:39

It's actually much more stable when I have my logic analyzer connected to FSMC_NE03 and FSMC_A0, even when the analyzer it's powered off.