esp32-s3-lcd-ev-board Display Image Shifting

[mikeg78]

I have been developing an application on the esp32-s3-lcd-ev-board which uses the 480x480 touchscreen with lvgl, wifi and bluetooth with littlefs filesystem. I have a problem where static content on the LCD gets shifted (frame buffer appears to shift with respect to the display) whenever a slight delay occurs due to other processing e.g. writing a file to flash via littlefs. There are no operations to lvgl when this happens - so this appears related to delay.

[mikeg78]

The config CONFIG_LCD_RGB_RESTART_IN_VSYNC=y seems to have resolved this issue. This appears to be required if the application cant supply LCD data fast enough "Reset the GDMA channel every VBlank to stop permanent desyncs from happening. Only need to enable it when in your application, the DMA can't deliver data as fast as the LCD consumes it."

[mikeg78]

The problem appears to happen when the LCD is starved of data (due to processing delay). The solution for this appears to be setting config CONFIG_LCD_RGB_RESTART_IN_VSYNC - this stops the display shift but the display still glitches quite regularly when navigating menus etc - is there any way to improve this?

In esp_lcd_panel_rgb.c:

"// reset the GDMA channel every VBlank to stop permanent desyncs from happening.
// Note that this fix can lead to single-frame desyncs itself, as in: if this interrupt
// is late enough, the display will shift as the LCD controller already read out the
// first data bytes, and resetting DMA will re-send those. However, the single-frame
// desync this leads to is preferable to the permanent desync that could otherwise
// happen. It's also not super-likely as this interrupt has the entirety of the VBlank
// time to reset DMA."

[ESP_Sprite]

You could try enabling bounce buffers in the esp_lcd_rgb_panel config - it uses the CPU to get the data from PSRAM, so it's a bit less efficient, but as CPU transfers get different priority, it may be able to eke out enough bandwidth to make it work. Also make sure that your PSRAM is configured for the highest speed your board allows.

[mikeg78]

You could try enabling bounce buffers in the esp_lcd_rgb_panel config - it uses the CPU to get the data from PSRAM, so it's a bit less efficient, but as CPU transfers get different priority, it may be able to eke out enough bandwidth to make it work. Also make sure that your PSRAM is configured for the highest speed your board allows.

Have tried bounce buffers with various configurations. Currently running PSRAM at 80MHz - not sure of this is the max but other examples on this board use 80MHz. I did instead manage to fix the issue by dropping the LCD clock from 16 to 12MHz - appears to be rock solid now.