AnsweredAssumed Answered

STM32F429I LTDC SDRAM and screen jitter/flicker

Question asked by Barta.Hank on Apr 17, 2015
Latest reply on Apr 17, 2015 by Barta.Hank
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 768. 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 the LTDC_ER_IRQHandler() interrupt gets called once for a FIFO underrun. This happens when STemWin calls CUSTOM_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.

The LTDC_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

Outcomes