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]

@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

[DPfei.16]

@Martin KJELDSEN​ do you mean the FIFO underruns or the assertion?

[Martin KJELDSEN]

I mean how and why TouchGFX added a dynamic bitmap in RGB888 ? I don't think this is something that the designer will do.

/Martin

[DPfei.16]

No, this is not a bug, this was my fault as I didn't notice this function call in the code:

Bitmap::dynamicBitmapCreate(40, 40, Bitmap::RGB888);

This function call was added from our GUI developer.

   

[Martin KJELDSEN]

Ahh, allright. Thanks. Glad things are working now!

/Martin