DMA on ESP32-S3 is working

[stg]

Not so much an issue as a potential solution.

I got DMA on ESP32-S3 working just fine, with some minor adjustments.
Since I am only using this library as a reference for writing a low-level implementation, I do not have a proper fix to share - but figured it might be worth something to you to know what I did to get it working.

1. Use HSPI
2. DMA_CHANNEL <= SPI_DMA_CH_AUTO
3. spi_host <= SPI3_HOST
4. After a DMA transfer: SPI_DMA_CONF_REG <= 0b11

I am doing step 4 in TFT_WRITE_BITS, which isn't a clean solution at all but works just fine, with HSPI at least.

[Bodmer]

Thanks for taking the time to post this. I will see if I can incorporate.

[stg]

No problem.

I would assume step 4 has to do with SPI_DMA_RX/TX_ENA and that my resetting the whole register just happened to also clear these bits.

The reason I think this is the case is the following from the ref. manual: 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.

Let me know if you need/want help with testing, since I have everything hooked up (for the next week or so).

[Bodmer]

Other RP2040 projects and library developments prevent me from working on this at the moment. Thanks for the offer of support but it will be some time before I can look at this in detail and progress it.

[Qvantos]

Not so much an issue as a potential solution.

I got DMA on ESP32-S3 working just fine, with some minor adjustments. Since I am only using this library as a reference for writing a low-level implementation, I do not have a proper fix to share - but figured it might be worth something to you to know what I did to get it working.

1. Use HSPI
2. DMA_CHANNEL <= SPI_DMA_CH_AUTO
3. spi_host <= SPI3_HOST
4. After a DMA transfer: SPI_DMA_CONF_REG <= 0b11

I am doing step 4 in TFT_WRITE_BITS, which isn't a clean solution at all but works just fine, with HSPI at least.

Please write where to enter these changes

[Bodmer]

I have updated the latest Github master (2.5.2) to add DMA for the ESP32 S3 (@stg thanks for the pointers). This has been tested with the examples provided.

Note that this is for SPI displays only and DMA is NOT supported for the ESP32 S3 with parallel interface displays.

[notmart]

with today's master, on an ESP32-S3 and GC9A01 as well, with all the DMA examples I'm getting either a white screen or random garbage on screen.

perhaps depends also on what pins are used?

At the moment using
#define TFT_MOSI 2 // In some display driver board, it might be written as "SDA" and so on.
#define TFT_SCLK 15
#define TFT_CS 17 // Chip select control pin
#define TFT_DC 16 // Data Command control pin
#define TFT_RST 4 // Reset pin (could connect to Arduino RESET pin)
#define TFT_BL 5 // LED back-light

which works fine without DMA

[Bodmer]

For some reason DMA requires that a MISO pin is defined. If you do not have a spare then you can allocate it to be the same as the TFT_CS line and it will work, e.g. in your case add the following to the setup file:
#define TFT_MISO 17

[notmart]

works perfectly, thanks :)

[andrewchilds]

Just noting here that not having #define TFT_MISO 17 in my setup was the culprit in my case (ESP32-S3-MINI-1U + ST7789V2 240x280).

[rsiemens77]

I am on 2.5.33, and when I try to use DMA with HSPI and MISO, only the very first update goes to the display, further updates do nothing, although seem to be running. It's the same others are reporting in this thread. Any ideas?

[shb3014]

DMA using HSPI and setting MISO to the same pin as TFT_CS works just fine. But it seems that dma with FSPI / SPI2 doesn't work. Are there other settings required for FSPI to work?

[Bodmer]

Make sure this line is commented out and the correct pins are used for the port.

[shb3014]

Make sure this line is commented out and the correct pins are used for the port.

With the provided settings, FSPI still doesn't work with dma. The root cause is that the MISO macro is replaced with MOSI when using FSPI if MISO is choosen as -1. Commenting out the related part in TFT_eSPI_ESP32_S3.h resolve the issue. Setting MISO to CS would not help.

    #if defined(CONFIG_IDF_TARGET_ESP32S3) || defined(CONFIG_IDF_TARGET_ESP32S2)
      #if (TFT_MISO == -1)
-        #undef TFT_MISO
-        #define TFT_MISO TFT_MOSI
+        //#undef TFT_MISO
+        //#define TFT_MISO TFT_MOSI
      #endif
    #endif

This seems to be related to the MISO init process in spi_common.c, specifically the esp_rom_gpio_connect_out_signal function. But this somehow does not affect HSPI.

if (bus_config->miso_io_num >= 0) {
            if (miso_need_output || (temp_flag&SPICOMMON_BUSFLAG_DUAL)) {
                gpio_set_direction(bus_config->miso_io_num, GPIO_MODE_INPUT_OUTPUT);
                esp_rom_gpio_connect_out_signal(bus_config->miso_io_num, spi_periph_signal[host].spiq_out, false, false);
            } else {
                gpio_set_direction(bus_config->miso_io_num, GPIO_MODE_INPUT);
            }
            esp_rom_gpio_connect_in_signal(bus_config->miso_io_num, spi_periph_signal[host].spiq_in, false);
#if CONFIG_IDF_TARGET_ESP32S2
            PIN_INPUT_ENABLE(GPIO_PIN_MUX_REG[bus_config->miso_io_num]);
#endif
            gpio_hal_iomux_func_sel(GPIO_PIN_MUX_REG[bus_config->miso_io_num], FUNC_GPIO);
        }

Also, it seems that setting MISO to the same as CS is not necessary with HSPI. Setting it to -1 would do the job.

[Bodmer]

Which Arduino ESP32 board package version are you using? There have been some breaking changes recently!

[shb3014]

I use an esp32s3 module in a customly designed board. I'm also at the latest master branch.

[JackIsGoofingOff]

If you are using a round display from WaveShare, here is a quick solution (Add a new .h file in User_Setups and fill these codes and include this file in User_Setup_Select.h).

#define USER_SETUP_ID 305
#define USER_SETUP_INFO "ESP32-S3-LCD-1.28"

#ifdef ILI9341_DRIVER
#undef ILI9341_DRIVER
#endif

#define GC9A01_DRIVER

#define TFT_WIDTH 240
#define TFT_HEIGHT 240

#define TFT_MOSI 11
#define TFT_SCLK 10
#define TFT_CS 9
#define TFT_DC 8
#define TFT_RST 12
#define TFT_BL 40
#define TFT_BACKLIGHT_ON HIGH

#define LOAD_GLCD
#define LOAD_FONT2
#define LOAD_FONT4
#define LOAD_FONT6
#define LOAD_FONT7
#define LOAD_FONT8
#define LOAD_FONT8N
#define LOAD_GFXFF

#define SMOOTH_FONT

#define SPI_FREQUENCY 80000000

// related to DMA (direct memory allocation)
#define USE_HSPI_PORT
#define TFT_MISO 9

[JackIsGoofingOff]

But only image can be shown, animation is not working

[mjocean]

I'm having a problem which I think is similar to the last poster.

I am using a Waveshare ESP32-S3-Zero (the zero has no USB to UART chip and fewer exposed GPIO pins) and a separate GC9A01 1.28" round LCD display.

Without DMA all is working after I added USE_HSPI_PORT and to knock my frequency down to 27MHz to my config. Pins are as follows:

#define TFT_MOSI 11 //  "SDA" 
#define TFT_SCLK 10
#define TFT_CS    9  // Chip select control pin
#define TFT_DC    8  // Data Command control pin
#define TFT_RST   12  // Reset pin  --I have no header for pin 14 on this board
#define TFT_BL 40
#define TFT_MISO 9 // same as CS

Enabling DMA results in no updates to the display, though the program continues to run and logging shows that time is taken per pushImageDMA as there is a frame rate shown. The same is true in my own code, where I see that pushPixelsDMA takes time, but on my code the display is still blank (same code works with our without DMA on the RP2040, with a different Setup, naturally).

To minimize variables: when running the DMA cube example source, a single initial yellow rect is shown on the display and it is frozen --it never moves, but on Serial reasonable FPS values are shown. These values are slightly higher than those shown with DMA disabled, but with DMA disabled, the cube renders properly, moving around the screen.

Does anyone have any suggestions or advice? Thank you!

[rsiemens77]

I am having the same issue on S3 as the previous recent reports, even with HSPI and MISO defined. The first DMA update works, but successive updates do nothing, although all seems to be executing. This exact DMA code works fine on ESP32E. If I switch to non-DMA pushSprite() everything works fine as well.

This sounds the same as the previous reports that also suggest first display works, but all further updates fail:

"But only image can be shown, animation is not working".

"when running the DMA cube example source, a single initial yellow rect is shown on the display and it is frozen --it never moves"

[rsiemens77]

I did a test where I mix some non-DMA updates with DMA updates. The non-DMA updates work, until a DMA update is made. That DMA update gets pushed to the display, but then -ALL- further updates stop, as if the LCD is frozen. But the code seems to keep running fine.

[rsiemens77]

I put some logging messages in pushImageDMA and spi_device_queue_trans to see if I could find anything odd.

Both the first push and successive ones look the same, all the expected code seems to run, just no update after the first one. And the LCD is frozen now, as non-DMA updates don't work either.

I (9545) TFT: pushImageDMA
I (9548) TFT: dmaWait
I (9551) TFT: dmaWaitdone
I (9554) TFT: spiBusyChecked
I (9558) TFT: while
I (9562) TFT: while done
I (9563) TFT: queue_trans
I (9567) SPI: queue_trans
I (9570) SPI: bus acquired
I (9573) SPI: Queue Send
I (9577) SPI: lock bg request

[Basitadam]

After the first DMA transfer, even this does not recover the SPI communication:

tft.deInitDMA();
delay(100);
tft.begin();

(in fact, CS, DC and SCLK works as it should, but not MOSI. Stays at low level) - My board is ESP32-S3-Zero