Problem with simultaneous use of spi and wifi DMA controllers

[Patrick78]

ESP-WROOM-32

i have two task, one task is on core 0 on which soft AP and tcp server works, another task works on core 1 and he uses HSPI with DMA. when tcp server receive some data HSPI Stops working for a moment, about a millisecond. i use spi for rotate display and This pause is quite noticeable.when i use spi without DMA all works fine, but at once i can send 64 byte Which is very little and so I had to send it several times so it takes twice as long to send 1200 bites without DMA.

i suppose simultaneous use of wifi DMA and spi-DMA,poses This problem/bug.What would you recommend to me on this issue?

[ESP_Sprite]

Where do you iniitialize your SPI peripheral? The interrupt handling for it is done on the core the device is initialized, so if you do that on core 0, it may still interfere with WiFi.

[PeterR]

Would be interested in your IDF version.
You are right, you will have a finite bandwidth to share among the DMA functions. I have found that it is very expensive to setup DMA on short transfers. You can pre configure but that is extra code.
1 mS is a long time though. Guessing 160Mhz internal RAM so 20MB/S. Thats quite a few frames. Setup latency & critical sections will kill that potential though. The IDF is generally high latency but even so....
IDF 4.1? Try 4.0 or lower. Just a guess but I am seeing significant latency issues since upgrading from 4.0 dev & suspect Ethernet in 4.1.

[Patrick78]

Where do you iniitialize your SPI peripheral? The interrupt handling for it is done on the core the device is initialized, so if you do that on core 0, it may still interfere with WiFi.

spi initialized on core 1 and wifi on core 0.

I was told that two DMA may not have simultaneous access to RAM.
but spi without dma uses core 1 for all work and why he has no problem with access to RAM when wifi Dma receiving data?

[Patrick78]

Would be interested in your IDF version.
You are right, you will have a finite bandwidth to share among the DMA functions. I have found that it is very expensive to setup DMA on short transfers. You can pre configure but that is extra code.
1 mS is a long time though. Guessing 160Mhz internal RAM so 20MB/S. Thats quite a few frames. Setup latency & critical sections will kill that potential though. The IDF is generally high latency but even so....
IDF 4.1? Try 4.0 or lower. Just a guess but I am seeing significant latency issues since upgrading from 4.0 dev & suspect Ethernet in 4.1.

i have esp-idf ver 4.1
when i changing to version 4.0 i can't normally connect this and all necessary stuff to eclipse. i use ubuntu.

[ESP_Sprite]

spi initialized on core 1 and wifi on core 0.

I was told that two DMA may not have simultaneous access to RAM.
but spi without dma uses core 1 for all work and why he has no problem with access to RAM when wifi Dma receiving data?

It depends. The memory bus is really fast, however, and all DMA in total should easily have 80MHz*32bit=320MByte/sec of capacity. You'd need an pretty large DMA transfer (300KByte'ish) to block the bus for the amount of time you're seeing it blocked.

Is there a way we can see your code? Perhaps there's something obvious going wrong.

[Patrick78]

For continuous video display work I have three temporary buffers the size of each is 30 kilobytes. When at least one buffer i will be read tcp the server gets 30 kilobytes of information which is approximately 17 packets, I think some packets come in so fast that sometimes there is no time left for the spi to use its DMA but not so fast that the image is not interrupted. I think it's about 200 microseconds to 1 millisecond, and I know this because I need 200 microseconds to update one line of the pov screen, and I can easily see how much is lost.
When I don't use DMA to update the image, there is no problem. I wonder why spi limited only 64 bytes without DMA ?
Why does this problem occur during DMA using?

I don't want to tire of showing a bit of abstract and tangled code, but if there's anything, I can put a part of tcp code.

[ESP_Sprite]

Still, DMA being slow is pretty much an impossibility... from what I recall, a DMA underrun pretty much is a fatal condition; the SPI peripheral will abort instead of just stopping to transmit for a while. How are you queueing the 30K of data? All in one transaction, or in many small transactions? If the latter, the issue may be the switchover from one transaction to another as that is done in software on the ESP32, or the thread that feeds the SPI transactions to the driver.

SPI is only limited to 64 bytes because that is all the memory the SPI controller has internally; the idea is that normally you use it with DMA.

[Patrick78]

30kbyte I send it entirely from Matlab and reading it with recv() function in loop, all occupies about 20 milliseconds, meanwhile spi Sends in pieces another 30 kbyte buffer, 150 bytes every 200 us, I do not place transactions in the queue.

[ESP_Sprite]

What reason do you have to think the DMA transfer gets interrupted then?