STM32F429 LTDC Sends incorrect pixel data to LCD

ralphj · ‎2015-10-13

Posted on October 13, 2015 at 20:41

Hello,

I'm working on a problem that's brought me to a bit of a standstill. I have a controller-less LCD connected to an STM32F429. I'm also using an external SRAM device at address 0x64000000.

My first try began with writing pixel data to the LCD using the STemWin libraries with the GUI_DrawHLine and GUI_DrawVLine functions; the pixels didn't get placed in the correct place. So I took a step back and tried the GUI_DrawPixel function with no better results.

The display is 480 x 272. When I drew a horizontal line that was shorter than the display, say 360 pixels, the line would wrap around and start on the next line. When I drew a vertical line, the first pixel was ok at (0,0), but then the following pixels were offet the the right...so the result was kind of like a bunch of zig-zaggy lines.

So I had to dig deeper to learn more. I wasn't sure whether the software driver that I selected (GUIDRV_LIN_16) was right. But I have verified by reading values back from the SRAM chip through JTAG and software that the correct pixel data is getting written to SRAM.

I assumed at that point that I had set up the LTDC timing incorrectly. After several days with the reference manual and finally a logic analyzer, I think that the timing is correct, and I see that the LTDC really is sending out the pixels as I see them on the screen.

Over the weekend while reviewing the logic analyzer output it appeared to me that the data being read by the LTDC was stale (for lack of a better word). That is, when previous pixels in the horizontal line were turned on, it took some time for the pixels to be read as off from the memory. The same with a vertical line: when a number of ''off'' pixels preceded to next ''on'' pixel, it took some time to actually read that ''on'' pixel.

So I came in this morning thinking that my SRAM timing could be at fault (even though earlier tests made me think I was reading and writing the SRAM chip ok). So I spent a little time testing memory and I'm becoming more convinced that I am accessing the SRAM correctly.

I have verified that LTDC_L1CFBAR is configured to point to my frame buffer at 0x64000000. I'm beginning to run out of ideas. Are there any reasons DMA access to memory values that have been verifed correct would return incorrect values?

Also, does DMA2D come into play here? I wasn't sure, but I've been coming to the conclusion that module affects the data that is written to memory and could not create the problem that I am seeing.

I appreciate any thoughts on this.

Thank you!

#dma #lct-tft #ltdc #stm32f429

ralphj · ‎2015-10-14

Posted on October 14, 2015 at 17:07

It really seems to be a breakdown between the LTDC and SRAM. I tested the SRAM quite a bit yesterday: I never seem to have a problem reading/writing SRAM, or viewing it through JTAG.

So I began to wonder whether I could just store a static display image in program flash memory to verify the LTDC was set up correctly. When I do that, a horizontal and vertical line are displayed ok.

It's interesting, images that are identical in SRAM and program flash memory (as viewed through the JTAG) end up differently on the LCD. I'm not yet sure why the timing is off between LTDC and SRAM.

Amel NASRI · ‎2015-10-15

Posted on October 15, 2015 at 11:00

Hi bach.talk,

Could you please let us know what are you using as hardware? If it is a custom board, is it possible to tell us the reference of your LTDC and share your LCD conf?

It will be interesting also to provide us more details about the firmware you are using.

These elements may help us to more investigate the issue you are facing.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

ralphj · ‎2015-10-15

Posted on October 15, 2015 at 16:02

Hi Mayla,

Thank you; I appreciate your help.

I've attached a file with the functions that I used to set up the system clock, the LCD, and the SRAM.

I'm using the internal oscillator (I had some trouble with an external crystal circuit that I need to get back to, so I enabled the internal oscillator).

It is a custom board. I didn't seem to have enough pins to make the SDRAM part from the Discovery eval board work, so I used another part that we use with an older STM32 part. The SRAM isCY7C1051DV The LCD is a TFC-S9430RTWQ40TR-01A.

Thanks again. I'll keep plodding along and let you know if I learn anything new.

________________

Attachments :

STM32_Setup.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0iF&d=%2Fa%2F0X0000000bct%2FvSEjkPRcxrZrcN1duQq6VFyxKRhai4O4WkMYbc8hD84&asPdf=false

ralphj · ‎2015-10-16

Posted on October 16, 2015 at 20:49

I don't have this solved yet, but just another observation. It doesn't seem to me that the LTDC observes the memory access timing as set up in the FMC configuration.

One of the behaviors exhibited by the problem that I'm having is that when drawing a simple horizontal line, the line extends further than it should. For example, if I draw a horizontal line at (0,0), 360 pixels long, it actually fills a 480 pixel wide display line and wraps to another line.

I've tried making the FMC access time as short as possible; that improves things a little because the memory bus is keeping up with the LTDC a little better. If I slow down the access time, the LTDC seems to pull data from the bus just as fast as it did before, but now my horizontal line extends for several lines because the LTDC just keeps sending out the ''on'' pixels until it finally gets some ''off'' pixels from memory.

Perhaps there something in the configuration of the LTDC that I'm missing?

ralphj · ‎2015-10-21

Posted on October 21, 2015 at 22:29

I've been working on some other things this past week or so, but this morning I took another look at this LCD problem. I noticed that the main clock setup is incorrect. I should've had PLLM set to 16, not 8:

RCC_OscInitStruct.PLL.PLLM = 16;//8;

Practically working now, but while debugging, I think I might have broken something else that used to work...

ralphj · ‎2015-12-11

Posted on December 11, 2015 at 15:52

Just a final update to this thread:

My other problems were caused by some debugging things that I was doing, the LCD is working fine now.

However, there still seems to be an issue with the the way the LTDC pulls data from the FMC when using an SRAM chip--the SDRAM used on the eval board works fine. I just haven't been able to get the LTDC to observe the timing set up in the FMC configuration. Fortunately, it works ok with the display I'm using.