pushImageDMA crashes with ESP_ERR_NO_MEM

[rsiemens77]

Discussed in #3242

^{Originally posted by rsiemens77 March 19, 2024}
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?

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]

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?

[rsiemens77]

After investigating the lower level SPI routines being used, I realize this likely happens due to implementation at that level. Doing malloc and free every time to create a dma-able buffer seems very naive. I expected this would be using something wiser, like a memory pool implemented in dma-able size chunks, not full bitmap size. As it is, it's always better to re-use a fixed buffer like I am doing, rather than let the lower level SPI routines malloc/free over and over again.

Perhaps could turn this into a feature request to do it the better way as described above.