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

[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]

Your effective VSYNC with one vs the other. This impacts your overall framerate. So, you can decide if this reduced pixel clock and overall performance of the application is acceptable or if you need to re-check your configurations or if you need to revisit your hardware design.

[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]

@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();

  }

}

[DPfei.16]

@oleksandr.karbivsky​ @Martin KJELDSEN​ 

I tried to use RGB565 instead of RGB888 to reduce load on SDRAM.

Therefore I read this article in TouchGFX knowledge base: https://touchgfx.zendesk.com/hc/en-us/articles/360017493592-Color-Depth

I use these settings:

opaque_image_format := RGB565

non_opaque_image_format := ARGB8888

The first screen works fine with these settings. But during transition to the second screen I get an assertion inside function LCD16bpp::drawPartialBitmap() in TouchGFX lib and the program hangs-up.

I have converted all used bitmaps in the TouchGFX\generated\images\src folder to RGB565.

Do you have any idea?

[Martin KJELDSEN]

The only reason LCD16 asserts is if it's dealing with the wrong opaque image format, like RGB888. Can you double check your assets/config? Grep your generated folder for //RGB888 - it says in the generated cpp files for images what the format is.

/Martin

[DPfei.16]

The reason for the assertion was that our GUI developer added a dynamic bitmap in RGB888 format which I didn't noticed ...

Now with the 16 bit color depth I don't get FIFO underruns anymore.

@Martin KJELDSEN​  @oleksandr.karbivsky​  many thanks for you help!

[Martin KJELDSEN]

Great! And, that's interesting. Can you tell me more about how that happened? Do you think it might be a bug?

/Martin