Can't get DMA working with ESP32-S3 and ST7735

[rsiemens77]

I've previously been using ESP32E-Devkit, and my code worked fine on there, with DMA working. Now, I'm porting application to ESP32-S3-devkit and have issues. TFT_eSPI 2.5.43. Arduino 2.0.17.

If I use the non-DMA calls, everything works fine. If I try a DMA update, the single first update works and then the display seems to be frozen, although all the code still seems to run. The general process is to do updates to the sprite framebuffer, and then the non-DMA vs DMA functions to push the changes are:

sprite.pushSprite(0,0);
tft.pushImageDMA( 0, 0, width, height, (uint16_t *)sprite.frameBuffer(1) );

I realize there's a couple of other discussions describing similar problems, and I've read through them and tried everything I could from those, but I haven't been able to get it to work. Namely these:

#2233
#3432

I've read the Espressif docs about the IOMUX vs MATRIX pins, and these should be the faster IOMUX ones:

CS0 1 | 10
SCLK | 12
MISO | 13
MOSI | 11
QUADWP | 14
QUADHD | 9

Here is a table of some of my test runs. Whether DMA updates occur beyond the first frame seem very dependent on the TFT_DC pin setting. If I use some of the UART pins there like 17, 18, I get some weird updates as described below. Can anyone make sense of the results, or any insights, or what else I should try?

I've tried various SPI_FREQUENCY values but doesn't change the results.

HSPI : means "#define USE_HSPI_PORT" is active
VSPI : means "//#define USE_HSPI_PORT" is commented out

NonDMA / DMA : means the calls used as above

works : updates are running fine
first frame : first update to the display works, then it's frozen (even non-DMA updates don't work after)
no response : display did absolutely nothing
mixed : display is updating, some frames are correct but skewed horizontally and vertically, some frames seem look byte swapped and also skewed
crash : this happens at tft.init() -> writecommand() -> begin_tft_write()

---

Pins	Pins	Pins	Pins	Pins	Pins	Pins	Pins
TFT_SCLK	12	12	12	12	12	12	12
TFT_MOSI	11	11	11	11	11	11	11
TFT_RST	14	14	14	10	10	10	2
TFT_DC	10	10	46	9	9	17	38
TFT_CS	-1	46	10	46	14	14	39
TFT_MISO	-1	46	46	46	13	13	13
HSPI nonDMA	works	works	no response	works	works	mixed	works
HSPI DMA	first frame	first frame	no response	first frame	first frame	mixed	first frame
VSPI nonDMA	crash	crash	crash	crash	crash	crash	crash
VSPI DMA	crash	crash	crash	crash	crash	crash	crash

---

[TheWolf95]

Are you calling tft.beginWrite() and tft.endWrite() methods before and after DMA pushes?
What about mallocs? Did you use flags to ensure the memory is DMA accessible?

Lastly, try my example code in #3432 (first reply) with the following config: (try both HSPI and VSPI)

#define TFT_MISO 13
#define TFT_MOSI 11 // In some display driver board, it might be written as "SDA" and so on.
#define TFT_SCLK 12
#define TFT_CS   39  // Chip select control pin
#define TFT_DC   38  // Data Command control pin
#define TFT_RST  2  // Reset pin (could connect to Arduino RESET pin)

let me know how it goes!

[rsiemens77]

I tried your pins, and added to my table above, it's the same results: first frame only. I'm still curious what you did to make VSPI work, as I always get a crash if I dont use HSPI. Seems that was the verdict in the other discussion too.

I did try again with the manual startWrite and endWrite. But my understanding is if you do "initDMA(true)" it will do it automatically on the ESP32. Regardless, I've tried both ways, and doesn't make a difference.

Using the sprite framebuffer there's a callocsprite() which I've swapped out to explicitly do the same malloc as yours for DMA, and it makes no difference in the results. I think my code is doing the same calls as yours now.

I did previously try the TFT DMA example, and only got the first frame, just as reported by others in that other discussion.

[TheWolf95]

I suspected it when you mentioned a crash and not even the first frame showing. TFT_eSPI is known to work with Arduino <=<2.0.14, I see just now you work on Arduino 2.0.17 . You may want to try downgrading it and see how it goes!

[rsiemens77]

Alright, and what version of TFT_eSPI are you using? May as well match things up here.

[rsiemens77]

Googling for 2.0.14 and TFT_eSPI, I did indeed find this issue about init problem.

#3329

I did fresh install of arduino-esp32-2.0.14 and TFT_eSPI-master, but I am getting the same crash. Some on that thread also reported the same.

Only changes I made in UserSetup.h to the fresh install are:

#define ST7735_DRIVER // Define additional parameters below for this display

#define TFT_WIDTH 128
#define TFT_HEIGHT 160

#define ST7735_ROBOTLCD // For some RobotLCD Arduino shields (128x160, BGR, https://docs.arduino.cc/retired/getting-started-guides/TFT)

#define ESP32_DMA

#define TFT_SCLK 12
#define TFT_MOSI 11
#define TFT_RST 2
#define TFT_DC 38
#define TFT_CS 39
#define TFT_MISO 13

Darn, thought it was going to work this time...

[TheWolf95]

How unfortunate, I thought it wa it too..
I suggest you posting your complete error trace, like I did here. Perhaps someone will find a solution to it. You may also consider opening an isssue at this point

[TheWolf95]

Try messing with settings you may have missed in UserSetup.h too. I really got it working by doing random changes

[rsiemens77]

I'm really curious about the only configuration where I get the same results with DMA and nonDMA is with the TFT_DC set to 17, but the updated frames are only correct sometimes, other times they are byte swapped, and they are always skewed. That configuration seems close, but wondering what the problems are with it.

[rsiemens77]

crash : this happens at tft.init() -> writecommand() -> begin_tft_write()

Within the begin_tft_write() it's the SET_BUS_WRITE_MODE macro failing. I expanded it at compile time and the code is:

*(volatile uint32_t*)(((((3)>=2) ? (0x60024000 + (3-2) * 0x1000) : (0)) + 0x10)) = ((1UL << (27)))

[rsiemens77]

The only possible insight on updates not happening on the LCD is this description from stg that sounds like it might cause that.

#2233 (comment)

The bits SPI_DMA_RX_ENA and SPI_DMA_TX_ENA in register SPI_DMA_CONF_REG should be set, otherwise the read/write data will be stored to/sent from the registers SPI_W0_REG ~ SPI_W15_REG

When I had my logic analyzer connected I could see that all transactions were in fact taking place as expected - but there was no data (MISO line was kept low), which would be explained by the aforementioned statement.