SPI DMA crashes when using WiFi

[HighVoltage]

I'm using ESP32e and IDF v4.4.6. I'm using TFT_eSPI library to push images via DMA to ST7735 mini LCD. This works fine most of the time, until I try to do a simultaneous request to web server I have running in lower priority task.

Then this assert inside pushImageDMA fails:

Code: [Select all] [Expand/Collapse]

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

GeSHi © Codebox Plus Extension

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?

Also, 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 continue 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 while using DMA updates?

[HighVoltage]

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.

[HighVoltage]

The same error occurs when I simultaneously run my task that does updates to LED strip through FASTLED library. There are lots of vTaskDelay() in that task, it is not CPU bound. So it seems not related just to WiFi usage but some kind of contention in general.

[HighVoltage]

I output the minimum and current heap size available before each invocation, and there is 60K free. I thought it might be 8-bit accessible related, but checked heap_caps_get_free_size(MALLOC_CAP_8BIT) and it is also 60K.

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;
    }

[HighVoltage]

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?

[ESP_Sprite]

Oooh, if the image data is in flash, that'll trigger this: as flash isn't DMA'able on most chips, the driver needs to copy the thing to RAM first. In theory, it could indeed do this in small chunks, triggering to re-copy on every DMA chunk, but in practice it doesn't do this: it would make the SPI driver a lot more complicated and having flash as a source is an uncommon enough scenario that it's not worth the extra complication.

[HighVoltage]

having flash as a source is an uncommon enough scenario

Huh? Where else would a pixmap image come from? It would always originate in flash.

Yeah, I was surprised to see how the lower level SPI routines are implemented when I investigated further. It seems naive to me, but I guess it's up to the end user to implement a better strategy. For now, I'll just prevent the memory management by reusing my own buffer.