STM32F429I LTDC SDRAM and screen jitter/flicker

[hbarta2]

Posted on April 17, 2015 at 15:34

Hi folks,

We are experiencing screen flicker (jitter?) with a setup consisting of an STM32F429I with external SDRAM frame buffer (part similar or identical to what is on the STM32F429I-DISCO board) and an external 480 wide x 800 high LCD. We are using the STemWin screen package. I have copied code from the STemWin_HelloWorld application to use as the starting point for the LCD configuration. The project is configured using STM32CubeMX and I have overridden settings produced by the LTDC configuration which are not correct for our configuration. Present settings are:

hltdc.Init.HorizontalSync = 9;
hltdc.Init.VerticalSync = 2;
hltdc.Init.AccumulatedHBP = 24;
hltdc.Init.AccumulatedVBP = 5;
hltdc.Init.AccumulatedActiveW = 504;
hltdc.Init.AccumulatedActiveH = 805;
hltdc.Init.TotalWidth = 514;
hltdc.Init.TotalHeigh = 808;

(STM32CubeMX limits height to 600 and the part is specified for a maximum height of 7 I have reduced the height used to well below 768 and it seems not to make a difference so I think that the height is not the root of the problem.) Here is what I know: The screen looks fine when it is static. Any time there is a screen update, content on the screen gets shifted to the right. The distance it gets shifted increases toward the bottom of the screen. Once the screen update is complete, the jitter settles and the display again looks normal. I have configured LTDC interrupts. On startup theLTDC_ER_IRQHandler() interrupt gets called once for a FIFO underrun. This happens when STemWin callsCUSTOM_FillRect(...) to fill the screen with a solid color. The target is the SDRAM screen buffer. I did not see any error bits set in DMA2D registers and do not understand the cause of the interrupt, but it occurs only once during initialization. TheLTDC_IRQHandler() ISR never gets called. This is the one that would switch layers (if I understand the code correctly) and seems like a likely cause for this issue. Based on what I see on the LCD, it seems to me like the process that the LTDC uses to fetch data from the screen buffer is being delayed while STemWin updates the screen buffer. I looked for a priority setting, thinking that if the priority of the LTDC access could be increased so it is higher than the priority of the STemWin write, the LTDC read would not be delayed. It is entirely possible that I have overlooked or otherwise messed something up copying code from the Discovery example. AFAIK this is not the ''flicker'' that is usually discussed WRT screen updates. The typical problem is that the buffer writes to update in image in the frame buffer is not complete when the display updates, causing the image to update in parts rather than all at once. That seems not to be the problem here but rather the image getting shifted across the screen. Any suggestions on where to look or how to solve this are really welcome! thanks, hank

[Tesla DeLorean]

Posted on April 17, 2015 at 16:52

Like the snow effect on IBM's original CGA adapters?

And what speed are you running the processor?180MHz?What if you run it at 200 or 168MHz gets better, worse, or no different?Adjust SDRAM timing, flash delays as appropriate. 16-bit or 32-bit SDRAM interface?Image size (width x height) vs update rate, is still the bandwidth constraining limit here.

[hbarta2]

Posted on April 17, 2015 at 17:37

Hi Clive,

Thank you for your thoughts on this. After posting I continued working with it (and searching the Segger forum for clues.) It turned out that enabling MEMDEV solved the flicker problem. As part of that solution I also moved the STemWin buffer (provided to STemWin by GUI_ALLOC_AssignMemory() ) to external SDRAM in order to meet requirements specified in the STemWin manual. That resulted in different issue. I have coded an SDRAM test that can be run on demand. It writes all over SDRAM. That's OK when it clobbers the frame buffer - I just recreate the screen when the test is complete. However clobbering the STemWin buffer leads to a hard fault. I either need to coordinate STemWin's use of MEMDEV with the test or not test that portion of SDRAM.I recall CGA adapters but not snow problems. Back them most of my work was on a VT220 which did not have that issue. Or graphics. ;) SDRAM is 16 bit and the FMC maps correctly to 8 or 32 bits as needed, but I think all of our access is 16 bit.We're running at 168 MHz, BTW. We seem to have enough cycles to do what we need at that speed.I did not evaluate bandwidth but assumed the H/W engineer considered that when choosing parts. We did tighten up SDRAM timings but it did not seem to make a difference. We also tried enabling burst mode on the SDRAM which did not work. it resulted in a corrupted display and did not pass the SDRAM tests.Thanks!