ESP32-S3 RGB LCD maximum throughput

[fdrvlx]

Hi,

I'm currently developing a custom board with an ESP32-S3-WROOM-1-N8R8 driving a 800x480 5" LCD display with a 16 bit RGB interface.
The problem is, the display works correctly only with a pixel clock up to ~14 Mhz. Increasing the speed leads to visualization problems (the image on the screen shifts).

I believe this is an underrun related issue; the GDMA is not fast enough to provide the LCD peripheral with the content of the frame buffer (which is located in the PSRAM).
Making some rough calculations, the octo-spi SPIRAM interface running at 80 MHz should provide a 80 MB/s transfer speed (ignoring overheads).
Fetching the whole framebuffer (800*480*2 bytes) should therefore take 9.6 ms.
The LCD display, clocked at 16 MHz, has a refresh period of 800*480/16M = 24 ms (ignoring blanking periods).

Shouldn't the ESP32-S3 be able to handle such throughput? Do you have any thoughts on this?

I tried tweaking almost every LCD peripheral configuration register but with no success.
I'm using the latest esp-idf master branch.

Thanks

[ESP_Sprite]

I think your calculations are correct. Are you sure that the PSRAM is actually running at 80MHz and in octal mode? I don't think that's the default, you need to select that in menuconfig.

[fdrvlx]

Sure, i selected octal mode, 80 Mhz in menuconfig.

[ESP_morris]

The latest master has fixed one issue that could slow down the RGB LCD flushing speed: https://github.com/espressif/esp-idf/co ... a790121899

Please try the new driver and to see if that can help.

[fdrvlx]

Thank you, I've just tried the new driver.

The only difference I see is that the image doesn't keep shifting anymore, but instead it hase some "glitches". This is because the new driver forces the display to start drawing every time from the correct start position, but then again it cannot keep up with the speed.

By the way, about 10 seconds after the boot, the ESP reboots with the following error:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x42062ad1  PS      : 0x00060033  A0      : 0x82053305  A1      : 0x3fc952b0
0x42062ad1: gdma_reset at D:/esp-idf-master/components/driver/gdma.c:517 (discriminator 2)

[...]

Backtrace:0x42062ace:0x3fc952b00x42053302:0x3fc952e0 0x40377a63:0x3fc95300 0x403763e1:0x3fc95320 0x40376caa:0x3fc95340 0x420117b4:0x3fceacf0 0x42028506:0x3fcead10 0x4202869b:0x3fcead50 0x4203119d:0x3fcead70 0x4203130f:0x3fceada0 0x42046892:0x3fceadc0
0x42062ace: gdma_reset at D:/esp-idf-master/components/driver/gdma.c:514 (discriminator 2)

0x42053302: lcd_rgb_panel_start_transmission at D:/esp-idf-master/components/esp_lcd/src/esp_lcd_rgb_panel.c:489

0x40377a63: lcd_default_isr_handler at D:/esp-idf-master/components/esp_lcd/src/esp_lcd_rgb_panel.c:516
 (inlined by) lcd_default_isr_handler at D:/esp-idf-master/components/esp_lcd/src/esp_lcd_rgb_panel.c:500

0x403763e1: shared_intr_isr at D:/esp-idf-master/components/esp_hw_support/intr_alloc.c:407

0x40376caa: _xt_lowint1 at D:/esp-idf-master/components/freertos/FreeRTOS-Kernel/portable/xtensa/xtensa_vectors.S:1117

0x420117b4: clear_screen at D:\WS_WSP32-S3\prj\build/../application/gui.c:4178 (discriminator 2)

Making some other tests, I came to the conclusion that the problem is not the LCD peripheral in itself. It is the fact that the application code also makes use of the PSRAM, therefore stealing bandwidth to the LCD peripheral.

I think the only possible solution to this would be some sort of hardware interlocking feature which blocks any access to the PSRAM while the GDMA is reading from it. Is anything like this possible?

[Deouss]

Hi,

I'm currently developing a custom board with an ESP32-S3-WROOM-1-N8R8 driving a 800x480 5" LCD display with a 16 bit RGB interface.
...
...

May I ask what kind of LCD display it is?
Is it OTM8009A ?

[fdrvlx]

It's this one: http://www.cdtech-lcd.cn/uploads/201707 ... 38a945.pdf

[Deouss]

I don't see any lcd controller mentioned in the docs. Probably some custom silicone so I guess you must figure things out on your own.
I would say all glitches are related to slowness of CPU and/or peripheral lagging performance for such large amount of data.
Btw PSram speed is quite slow - for 80mhz you get 5-7mb/sec and screen lcd has 750kb page so you get 6-9 fps max
Probably wouldn't use esp for your project

[Deouss]

I actually missed the LCD IC ) EK73002ACGB+EK9713CA
Found one lcd here https://www.globalsources.com/TFT-LCD/t ... 41305p.htm
Good luck

[fdrvlx]

There's no problem with the LCD display. And the PSRAM is actually working at almost 80 MB/s.

In fact, yesterday I was able to drive the display with a pixel clock of 40 MHz (almost 80 MB/s) by displaying a static image e not using the PSRAM for doing anything else in the application code. This means that the hardware is fast and it is working correctly.

As I said, problems rise when the application code starts using the PSRAM for other purposes, as this seems to "stretch" the GDMA transactions, making the LCD peripheral loose data.

The only way to solve this would be some sort of hardware priority schemes which allow GDMA to complete its job without being interrupted.

The ESP32­S3 Technical Reference Manual points to "Chapter 3 Permission Control (PMS)" which is not yet available...