LCD controller FIFO underrun

[DPfei.16]

Hello,

i use a custom DSI display on the STM32F769 Discovery Board.

The display has 720x720 pixels and no framebuffer. Therefore I can't use the DSI adapted command mode but I have to use the DSI video mode.

I have the following problem:

When the pixel clock is too low (below 30 MHz) the display is flickering (as the frame rate is too low).

When the pixel clock is above 30 MHz there is no flickering any more but then I get fifo underrun erros when a button is pressed on the display. So the display look completely correct but as soon as I press a button (causing some drawing), I see glitches until the drawing is completed, after which the display look correct again.

This link (https://touchgfx.zendesk.com/hc/en-us/articles/205676691-Debugging-Pixel-Error-Issues) says that the problem occurs because TouchGFX is rendering to one frame buffer in SDRAM while the LCD controller is reading from the other frame buffer. Depending on bus arbitration, this may cause the LCD controller to be denied SDRAM access for a time, long enough for the LCD FIFO to become starved.

The µC is running on his maximum frequency of 216 MHz. I use the generated code from TouchGfx. I only changed the DSI mode from adapted command mode to video mode. I use double buffering.

Does this mean that the selected display is not suitable for the STM32F769 µC or are there some things to optimize?

BR

Daniel

[Martin KJELDSEN]

It makes sense that you're only getting FIFO underruns when the application is actually doing something, because this is when your memory is strained by LTDC (reads) and DMA2D (writes).

One thing you could try to verify is to run full speed on pixel clock, but hal.lockDMAToFrontPorch(true); in your board configuration, so that the DMA won't start until the LTDC is out of active area.

720x720 pixels is slightly more than the 800x480 we're used to for the F769 DISCO Board. Maybe this is enough to starve the FIFO. But those displays have a framebuffer and we only run a single framebuffer in our application templates.

/Martin

[oleksandr.karbivsky]

Hi. How many layers and what pixel format you use for LTDC?

[Martin KJELDSEN]

We only utilize a single layer in TouchGFX. The pixel format depends on your application configuration.

Either: LTDC_PIXEL_FORMAT_RGB565 or LTDC_PIXEL_FORMAT_RGB888 for the disco board.

[DPfei.16]

Hi guys,

calling hal.lockDMAToFrontPorch(true) doesn't solve the problem. I still get fifo underruns and glitches on the display.

@oleksandr.karbivsky​ I use only 1 layer and the RGB888 pixel format.

BR

Daniel

[oleksandr.karbivsky]

Try to use RGB565 pixel format. This is reduce load on SDRAM.

[Martin KJELDSEN]

Try reducing the pixel clock until it looks good again and compare the numbers (nonlockDMA vs lockDMA).

/Martin

[DPfei.16]

@Martin KJELDSEN​ which numbers should I compare?

[Tesla DeLorean]

Perhaps give a full/effective presentation of your current configuration and clock settings for DSI and LTDC? This will avoid the "Guess What's Wrong" type games.

The specific display, with a cite for the data sheet, and your settings with respect to pixel clock, and horizontal and vertical settings/totals.

[Tesla DeLorean]

https://community.st.com/s/question/0D50X0000BG06tOSQR/dsi-clock-frequency

[DPfei.16]

Hi guys,

I use a color depth of 24 bits. Display has 720x720 pixels. With the porch and sync areas I have in total 770 horizontal pixels and 748 vertical pixels. This means for example at a pixel clock of 30 MHz I have a refresh rate of 19,2 ms. DSI Clock is 400 MHz.

Tearing effect pin is not used.

Attached you can find the display datasheet and the data sheet of the display LCD driver.

I also attach the source files which I had to change for DSI video mode.

BR

Daniel

[Martin KJELDSEN]

You say that TE pin is not used. How are you syncronizing with TouchGFX? This may be what's causing the glitch. Normally in adated command mode we rely on the TE interrupt to drive the application forward and protect the framebuffer(s).

/Martin

[DPfei.16]

..

[DPfei.16]

..

[DPfei.16]

@Martin KJELDSEN​ I use the LTDC line interrupt for syncronizing with TouchGFX.

You can see the syncronizing in the attached source file STM32F7HAL.cpp. This code is coming from CubeMx. (When DSI video mode is selected in CubeMX).

Here is the code snippet:

void HAL_LTDC_LineEvenCallback(LTDC_HandleTypeDef *hltdc)

{

  if (LTDC->LIPCR == lcd_int_active_line)

  {

    //entering active area

    HAL_LTDC_ProgramLineEvent(hltdc, lcd_int_porch_line);

    HAL::getInstance()->vSync();

    OSWrappers::signalVSync();

    // Swap frame buffers immediately instead of waiting for the task to be scheduled in.

    // Note: task will also swap when it wakes up, but that operation is guarded and will not have

    // any effect if already swapped.

    HAL::getInstance()->swapFrameBuffers();

    GPIO::set(GPIO::VSYNC_FREQ);

    s_nVsyncCnt++;

  }

  else

  {

    //exiting active area

    HAL_LTDC_ProgramLineEvent(hltdc, lcd_int_active_line);

    GPIO::clear(GPIO::VSYNC_FREQ);

    HAL::getInstance()->frontPorchEntered();

  }

}