ESP32 Forum

I am driving a 480 * 480 RGB565 lcd display. I am getting display drift and want to understand the cause. My setup:
- simple FreeRTOS app with a few tasks
- using lvgl to render an animation
- 15 MHz PCLK, requiring (15 * 2 bytes) 30 MB/s DMA throughput
- 80 MHz Octal PSRAM = 80 MB/s
- double frame buffers in PSRAM (no room in IRAM even for a single buffer)

Using double buffers should avoid tearing etc., any rendering bottlenecks would cause uneven animation, but the screen should remain stable.
Display drift must be caused by slow DMA - copying pixels to the peripheral is not keeping up with PCLK?
But PSRAM bandwidth is more than double the DMA requirements, so it should be OK even when sharing the SPI bus with the cpu cores?

I tried using bounce buffers - two small buffers in IRAM with CPU intensive copy from frame buffer to bounce buffer. No real difference. I don't understand this because now the DMA is from IRAM to peripheral which has a much higher bandwidth and no contention issues. But because the bounce buffers are not full frame size, they must be updated fast enough by CPU copy from PSRAM frame buffer. Perhaps this is the bottleneck?

I'm looking for suggestions for a solid display without drift and with headroom for more task processing.

Could you explain what you mean by display drift? A video clip is worth a thousand words.

Could you tell us more about your display? Is it a raw R/G/B/HSync/VSync panel, or is there a display controller with its own framebuffer and VSYNC signal to avoid tearing?

The esp32s3 drives an ST7701 display chip in RGB mode - continuous refresh at PCLK rate. I think this is correct:

With double buffers in PSRAM, DMA bandwidth is critical. Low render performance will cause low fps and may show as jerky animation, but display integrity should remain as there is always a complete frame to display in the other buffer.
If DMA is constantly too slow for PCLK then a fixed image drifts across the screen. If it is occasionally slow then the image is shifted and remains incorrectly centred (unless DMA restart on VSYNC is used). If the DMA bandwidth is sufficient, display drift can still occur when flash erase/write occurs because flash write prevents DMA access of PSRAM - or the DMA eof ISR can't run?

I have a persistent log that writes to flash and this messes up the display. Am looking for ways to get it to work.

because the bounce buffers are not full frame size, they must be updated fast enough by CPU copy from PSRAM frame buffer. Perhaps this is the bottleneck?

That's likely, as during flash writes PSRAM is inaccessible.

Btw,

80 MHz Octal PSRAM = 80 MB/s

not necessarily, see https://github.com/project-x51/esp32-s3-memorycopy (58.13 MB/s max. @ default 32 bytes cache block size)
Increasing the cache block size to 64 bytes improves bandwidth though: https://github.com/project-x51/esp32-s3 ... 2695486102