Page 1 of 1

ESP32-S3 RGB LCD: drawFastVLine()/single-column framebuffer anomaly using ST7262 panel

Posted: Sat Jul 18, 2026 8:01 am
by FLYINGSCOT
Hi all,

I am developing a non-commercial Electronic Flight Information System (EFIS) called SkyeScope using an ESP32-S3 and a Waveshare 4.3" 800×480 RGB display based on the ST7262 controller.

Software environment
Arduino IDE 2.3.7
ESP32 Arduino Core 3.3.5
ESP-IDF libraries bundled with the core (IDF 5.5)
RGB LCD driver (esp_lcd)
ESP32_Display_Panel library (current release)

Initially I believed there was a problem with my graphics code, but after extensive testing the evidence seems to suggest something lower in the display pipeline.

Graphics architecture

My graphics engine is very simple:

drawFastHLine()
\
\
-> drawPixel() -> framebuffer
/
drawFastVLine()

Both drawFastHLine() and drawFastVLine() ultimately use the same drawPixel() primitive.

Observed behaviour

A horizontal line renders exactly as expected.

A single vertical line does not.

For example:

graphics.drawFastVLine(198, 50, 300, Colors::Red);

or

for (int y = 50; y < 350; y++)
{
framebuffer.pixel(198, y) = Colors::Red;
}

produces a black vertical stripe instead of a red line.

However:

for (int y = 50; y < 350; y++)
{
framebuffer.pixel(198, y) = Colors::Red;
framebuffer.pixel(199, y) = Colors::Red;
}

produces two correct red vertical lines.

Similarly, drawing two adjacent columns works correctly whereas drawing either column individually does not.

Important observations

I verified the framebuffer contents immediately after writing.

For example:

framebuffer.pixel(198, 200) = Colors::Red;

Serial.printf("%04X\n",
framebuffer.pixel(198, 200));

returns:

F800

exactly as expected.

Therefore the framebuffer itself appears correct.

The CPU writes the expected RGB565 values, and reading them back immediately confirms they are present.

Colour tests

Using direct framebuffer writes:

Colour RGB565 LCD Result
Green 07E0 Displays correctly
Red F800 Black stripe
Blue 001F Black stripe
Magenta F81F Black stripe
Yellow FFE0 No visible change (background remains unchanged)
Cyan 07FF No visible change

The framebuffer always contains the expected RGB565 values.

Question

Has anyone seen behaviour where:

single-column updates are not displayed correctly,
adjacent columns display correctly,
framebuffer contents are verified as correct,
but the RGB LCD output differs from the framebuffer?

Could this be related to RGB timing, DMA, cache coherency, bounce buffers, or some aspect of the esp_lcd RGB panel driver?

Any suggestions for further investigation would be greatly appreciated.

Thank you.

Re: ESP32-S3 RGB LCD: drawFastVLine()/single-column framebuffer anomaly using ST7262 panel

Posted: Sat Jul 18, 2026 9:12 am
by MicroController
cache coherency
Frame buffer in PSRAM? Then yes, that might be an issue.

Re: ESP32-S3 RGB LCD: drawFastVLine()/single-column framebuffer anomaly using ST7262 panel

Posted: Sat Jul 18, 2026 11:17 am
by FLYINGSCOT
Thanks for your reply.

cache coherency? Please explain.

Yes, I assume that the Frame buffer is in PSRAM. But how do I confirm that it is?

Regards.

Re: ESP32-S3 RGB LCD: drawFastVLine()/single-column framebuffer anomaly using ST7262 panel

Posted: Sat Jul 18, 2026 12:00 pm
by FLYINGSCOT
Thanks for the suggestion.

The framebuffer is obtained from the ESP32_Display_Panel library rather than allocated by my application, so I'm not currently certain whether it resides in PSRAM or internal SRAM.

My understanding is that the library ultimately creates the panel using esp_lcd_new_rgb_panel(), and I retrieve the framebuffer through the library interface.

Is there a recommended way to determine whether the framebuffer is located in PSRAM, and if cache coherency is the issue, what would be the recommended approach? Should cache write-back/invalidation or an explicit cache synchronization be performed after framebuffer updates?