ESP32-S3 RGB Panel controller example for ESP-IDF v4.4

[itavero]

Hi,

For a new product platform we are developing, I'm evaluating the ESP32-S3 for controlling an TFT LCD panel using the RGB panel controller peripheral. I'm using an ESP32-S3-DevKitC-1-N32R8V to evaluate this (it was the only Dev Kit with the ESP32-S3 and PSRAM I could get my hands on at the time).

Unfortunately I've been unable to get the example that is currently on the master branch running using ESP-IDF v4.4.
I've manually made the changes to use heap_caps_aligned_calloc to allocate the frame buffer in esp_lcd_rgb_panel.c, but it seems that as soon as I enable the external PSRAM support in menuconfig, that I'm running into issues inside lcd_rgb_panel_create_trans_link that cause the panicHandler to get triggered.
Strange thing is that this even happens when I'm not using external RAM for the frame buffer.

Is there any example available for the RGB controller peripheral that does/should work on ESP-IDF v4.4?
The ESP32-S3 should be supported by ESP-IDF v4.4 according to the compatibility info in the README.

Hopefully someone can point me in the right direction.
I'd rather not rely on an unreleased SDK when it comes to deciding whether or not the ESP32-S3 will be a core component of the new product platform or not.

Kind regards,
Arno

[ESP_Sprite]

Does the example crash 'out of the box', or did you do modifications to it? Also, you don't happen to be accidentally using pins that are internally connected to the flash or SPI RAM for the LCD?

[itavero]

I ported the RGB LCD panel driver stuff to an adjusted LVGL example that was part of v4.4 (I've also been driving panels with integrated controllers over SPI/i80 as part of my evaluation).
Unfortunately, to my knowledge, there is no RGB LCD panel example for IDF v4.4.

I'm going to do further analysis today and I'll also try to run ESP-IDF master with the example, if I manage to get that working without breaking my v4.4 install (which happened last time I tried this).

Unfortunately I've been unable to debug the device with the integrated USB/JTAG solution (I can connect OpenOCD, but programming it via VS Code does not seem to work for me on Windows).
Because of that I started adding log statements in esp_lcd_rgb_panel.c, that's how I determined that lcd_rgb_panel_create_trans_link was the last function being called.
Funny thing is that I do not see the "install DMA failed" message after that (but also not the log message for the next function call).
It is immediately followed by the panicHandler log.

[itavero]

Just noticed that I also initialized an additional SPI bus/device before initializing the panel (as I have to use SPI to set the panel I'm using into 16 bit RGB mode).
Uncommenting this resolved the panic, so I guess there's a conflict in the DMA somehow.

[ESP_Sprite]

Just to check: what GPIO pins did you use for the SPI port?

[itavero]

I was trying to use pin 35, 36 and 37 for the SPI, but when I hooked up an oscilloscope I noticed these did not work, so I switched to 38, 39 and 40.
The crash is no longer occurring, so it can also be a collision in the pins I've used.

Can you provide any information on which panel was used to validate the RGB LCD example (or which controller was on it)?
If I can somehow get the same/similar panel, that would help me reduce some variables.

For the RGB lines, I'm using the following definitions, which should be identical to rgb_lcd_example_main.c in the master branch:

Code: Select all

   #define EXAMPLE_PIN_NUM_DE   45   ///< Data input enable. Active High to enable input
   #define EXAMPLE_PIN_NUM_PCLK 21   ///< Clock signal; latching data at falling edge
   #define EXAMPLE_PIN_NUM_HS   47   ///< Horizontal sync signal (neg polarity)
   #define EXAMPLE_PIN_NUM_VS   48   ///< Vertical sync signal (neg polarity)

   #define EXAMPLE_PIN_NUM_R0  14   ///< Red data
   #define EXAMPLE_PIN_NUM_R1  15   ///< Red data
   #define EXAMPLE_PIN_NUM_R2  16   ///< Red data
   #define EXAMPLE_PIN_NUM_R3  17   ///< Red data
   #define EXAMPLE_PIN_NUM_R4  18   ///< Red data

   #define EXAMPLE_PIN_NUM_G0 8    ///< Green data
   #define EXAMPLE_PIN_NUM_G1 9    ///< Green data
   #define EXAMPLE_PIN_NUM_G2 10   ///< Green data
   #define EXAMPLE_PIN_NUM_G3 11   ///< Green data
   #define EXAMPLE_PIN_NUM_G4 12   ///< Green data
   #define EXAMPLE_PIN_NUM_G5 13   ///< Green data

   #define EXAMPLE_PIN_NUM_B0 3   ///< Blue data
   #define EXAMPLE_PIN_NUM_B1 4   ///< Blue data
   #define EXAMPLE_PIN_NUM_B2 5   ///< Blue data
   #define EXAMPLE_PIN_NUM_B3 6   ///< Blue data
   #define EXAMPLE_PIN_NUM_B4 7   ///< Blue data

[ESP_Sprite]

From what I can tell, the ESP32-S3 N32R8V has octal ram, which means GPIO33-37 are used... could be that even with PSRAM disabled, the fact that you're sending stuff to the PSRAM chip makes it try to send stuff out on the other pins which are connected to the flash, causing a crash. 38 and on should be safe, though, so that doesn't explain the crash.

Sorry, I couldn't find what LCD was used for the example.

[itavero]

38 and on should be safe, though, so that doesn't explain the crash.

As mentioned in my previous post, the crash no longer seems to be occurring after I switched the pins. So I think it is likely that the wrong pins being used was the issue.

Sorry, I couldn't find what LCD was used for the example.

Unfortunately I have a panel with a ST7701S driver, which I seem to "wake up" via a three-wire SPI first, before being able to control it over RGB.
The datasheet of that controller isn't that clear to me (which might be due to my inexperience), so I'm still facing some issues there but I'm not sure if they are ESP32-S3 related or not at this point.

Having this information, would at least allow me to see the RGB controller in action.
I think I'll contact our distributor so they can reach out to their contacts at Espressif to hopefully get us this information.

[ESP_Sprite]

I don't think that info is available in Espressif... the person who wrote that code simply ordered a LCD off Taobao, without looking at the typenumber, and the seller didn't provide one. Fwiw, the Taobao link is here.

[itavero]

Not sure how to get on Taobao from here, but I got myself a "simpler" panel as well.

What I'm noticing now is that (even without the LCD connected), the PCLK and DE have 0V low and 3.3V high, but the HS and VS go between 0V and about 1.7V.
I would expect the levels to be similar for all these pins.
Does this mean that the controller is broken or is it perhaps a bug in ESP-IDF v4.4?

Update: I changed HS from GPIO 47 to 41 and VS from 48 to 42, and now they are using 3.3V as well.