AnsweredAssumed Answered

STM32F429 LTDC Sends incorrect pixel data to LCD

Question asked by on Oct 13, 2015
Latest reply on Dec 11, 2015 by

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 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!