LCD DPI with GC9503V-powered display

[zegelin]

This is a follow up to some questions I asked on Matrix a few days ago. And tangentially related to #2866

---

I'm trying to get the LCD DPI peripheral working with the driver chip and panel inside a "WirelessTag WT32S3-86S" -- a wall mount LCD touch screen powered by an ESP32S3.

This device appears to have similar internals to the ESP32-S3-LCD-EV-Board:

• ESP32S3 with 16MB flash and 8MB PSRAM (vs the 16MB PSRAM on the eval board).
• Display: 480x480 pixels.
• Driver chip: GC9503V.
  • The WT32S3-86 data sheet says "GC9503V".
  • The ESP32-S3-LCD-EV-Board says "GC9503CV", yet the Espressif eval board user guide's table of LCD Subboards links to the data sheet for the GC9503NP! ╯°□°）╯︵ ┻━┻

There is a demo firmware with source available from WirelessTag. I have flashed this and it successfully displays a touch UI on screen.

I believe that I'm successfully initialising the display. It talks "3 wire SPI".
There appears to be no error correction/detection/checksums. Hence I can't be 100% certain the commands I'm sending work. And while the GC9503V datasheet claims support for reading registers (eg, display ID), my attempts at reading from the chip have been unsuccessful.

Initially I was bit-banging 3-wire SPI via GPIOs, and did have issues where the init sequence wasn't sent correctly due to timing issues.
I have now switched to using the newly added 3-wire mode in esp-hal, which is what Espressif's own driver code for the eval board uses.

But strange things are afoot...

Issue

I can only seem to get one line of a DMA transferred pixel buffer to render to the display.
In addition, this row of pixels is repeated down the entire screen.

• If I transfer less than 480 pixels, only part of the line is displayed, as expected. However the cut off line is repeated down the entire screen.

  I init the DMA buffer for this transfer like so:

   let mut tx_buf = dma_tx_buffer!(250 * 2).unwrap();
  
   for (i, pixel) in tx_buf.as_mut_slice().chunks_mut(2).enumerate() {
       let shade = (i as f32 / 480.0) * (MAX_RED as f32);
       let color = rgb(shade as u16, 0, 0);
       pixel.copy_from_slice(&color.to_le_bytes());
   }

  And I see a cut-off red gradient:

  

• If I transfer more than 480 pixels, for example 2*480 pixels, I only see the first 480 pixels. And this first line is again repeated down the entire screen.

  I init and fill the DMA buffer for this transfer like so:

   let mut tx_buf = dma_tx_buffer!(480 * 2 * 2).unwrap();
  
   for (i, pixel) in tx_buf.as_mut_slice().chunks_mut(2).enumerate() {
       let x = i % 480;
       let y = i / 480;
  
       let shade = (x as f32 / 480.0) * (MAX_RED as f32);
  
       let color = if y == 0 {
           rgb(shade as u16, 0, 0)
       } else {
           rgb(0, shade as u16, 0)
       };
       pixel.copy_from_slice(&color.to_le_bytes());
   }

  i.e, fill it with a red gradient for the first line, and green for all others. And yet I only see a red gradient:

  

---

My understanding is that dma_tx_buffer! creates a non-circular buffer, and hence the DMA engine should stop transferring data into the LCD TX FIFO once it hits the end of the buffer. And while I do call dpi.send(false, tx_buf) in a loop, I have experimented with only calling it a minimal* number of times, and yet the display still has the data repeated down the whole screen.

* Strangely, with a 480 pixels buffer, if I only call dpi.send once, I get no image on screen. Twice, nothing. Three times, that's the charm! The line (repeated) shows up briefly, before fading away. 3 * 480 != 480 * 480, so its not like I'm calling send enough times to transfer every line (or so is my understanding).

---

Thus I'm confused as to why the buffer gets repeated down the screen -- I'm not sure if it's the ESP32 DMA engine or LCD peripheral that's repeating the data, or perhaps the GC9503 gets confused?

And I don't understand why a buffer greater than 480 pixels doesn't show any pixels on the screen past the 480 pixel mark.

---

Code that I'm working with is here: https://github.com/zegelin/wallbox/blob/gc9503/firmware/src/main.rs

Many thanks in advance.

[Dominaezzz]

My understanding is that dma_tx_buffer! creates a non-circular buffer, and hence the DMA engine should stop transferring data into the LCD TX FIFO once it hits the end of the buffer.

This is correct.
Once the DMA is done sending data, the LCD_CAM hardware would send black (I think) pixels for the rest of the screen.

Thus I'm confused as to why the buffer gets repeated down the screen -- I'm not sure if it's the ESP32 DMA engine or LCD peripheral that's repeating the data, or perhaps the GC9503 gets confused?

I'm 99% sure that this is a quirk of the display (GC9503).

And I don't understand why a buffer greater than 480 pixels doesn't show any pixels on the screen past the 480 pixel mark.

This one is interesting though, I'm not sure why you're seeing this. Try adding more rows add see what happens. You should be able to fit 50 rows in RAM

[zegelin]

I'm 99% sure that this is a quirk of the display (GC9503).

This got me thinking that perhaps the display was only somehow receiving/able to decode the first line of data. And that lead me to revisit the timings for the display. I didn't think to check these, since the screen was displaying something and I was focused on trying to fix it on the DMA side.

Turns out I had the timings set incorrectly. horizontal_blank_front_porch was equal to hsync_width (and same for the vsync variants). Adjusting them to match the demo firmware C code fixes the issue. I'm able to draw a checkerboard across ~1/2 the screen (not enough SRAM for a full 480x480 frame buffer).

Thanks for the pointers @Dominaezzz