pushImageDMA crashes on ESP32 when...

[rsiemens77]

I'm running ESP32 and updating ST7735 LCD with pushImageDMA. This works fine in general, but it immediately crashes when I make a request to my app's web server. Web server is running in it's own task.

There's an assert inside pushImageDMA that fails in that circumstance:

ret = spi_device_queue_trans(dmaHAL, &trans, portMAX_DELAY); assert(ret == ESP_OK);

By the way, is there an assert I can substitute that will give me the value of "ret" as well?

If I switch to the non DMA version of pushImage, there's no crash. Is there some contention between using ESP32 WiFi and SPI DMA? Interrupts don't work well together?

I did some more experimenting, and some further interesting findings:

The crash happens when WebServer is running at a lower or same priority task. If I make the WebServer task a higher priority, it just pre-empts/pauses LCD updates until the Web request finishes. The LCD updates just continues fine afterward.

Ideally, I'd like the LCD to keep updating regularly while lower priority web server requests are made. Any way I can accomplish this?

[rsiemens77]

Further testing reveals it's not just WiFi usage that causes this. If I run my task that uses FastLED to update LED strips simultaneously, that will also eventually crash.

I've updated pushImageDMA to output the return code that is causing the failure. It is consistently 257. That is hex 0x101 which is

#define ESP_ERR_NO_MEM 0x101 /*!< Out of memory */

Docs says

ESP_ERR_NO_MEM if allocating DMA-capable temporary buffer failed

Is this recoverable? Seems to be caused by some kind of contention from other tasks.

[rsiemens77]

I output the minimum and current heap size available before each invocation of pushImageDMA, and there is 60K free, and it's all 8-bit / DMA-able.

Is the SPI API doing something unusual with memory usage that causes this?

It seems the error likely originates from this in spi_master.c

Code: Select all

spi_trans_priv_t trans_buf = { .trans = trans_desc, };
ret = setup_priv_desc(host, &trans_buf);
if (ret != ESP_OK) {
    return ret;
}

[rsiemens77]

It looks like setup_priv_desc will malloc dma'able memory, because my image comes from FLASH. That appears to be where the likely failure occurs.

I decided to do a test, and I set up a single frame buffer in dma'able memory and copied from my image in FLASH to my own buffer, and then called pushImageDMA on my buffer. I no longer get any crashes then.

Something doesn't add up, my single frame buffer is much larger than what the SPI calls should be using: isn't DMA only done in small chunks, thus small buffers should be used?

[dj140]

Hi, i get the same issue too, Is there a solution to this problem now？

I (5507) spi_master: Allocate length: 32706
I (5507) spi_master: free MALLOC_CAP_DMA: 109167
E (5508) spi_master: MALLOC_CAP_DMA fialed
I (5508) spi_master: setup_priv_desc: 257 
E (5508) lcd_panel.io.spi: panel_io_spi_tx_color(388): spi transmit (queue) color failed

[rsiemens77]

I don't think this is an issue. I think it's due to the way the SPI API does dynamic memory allocation of "DMA-able" memory. It's really a pretty poor style. If you just allocate and re-use your own buffer, you should be able to avoid the constant allocation and deallocation of memory that the SPI API does.