displayTask fails on master branch now

[ESP32DE]

hi jeroen,

with the vanilla esp-idf ( master ) with psram support now we have in menuconfig new possibles for "psram" config:

with the psram-malloc branch i get this output and it is ok and esp32-doom runs well on this hardware:

on same hardware and with the actually vanilla esp-idf with psram support https://github.com/espressif/esp-idf/commit/d78ba789cfc7dc640f7f180b4d85f847efb47a02

i get this

and it stop here:

https://github.com/espressif/esp32-doom/blob/master/components/prboom-esp32-compat/spi_lcd.c#L306

    //We're going to do a fair few transfers in parallel. Set them all up.
    for (x=0; x<NO_SIM_TRANS; x++) {
        dmamem[x]=pvPortMallocCaps(MEM_PER_TRANS*2, MALLOC_CAP_DMA);
        assert(dmamem[x]);
        memset(&trans[x], 0, sizeof(spi_transaction_t));
        trans[x].length=MEM_PER_TRANS*2;
        trans[x].user=(void*)1;
        trans[x].tx_buffer=&dmamem[x];
    }
xSemaphoreGive(dispDoneSem);

i have try all three options in menuconfig but it finish not to start.

did we need a special change in code?

txs best wishes rudi ;-)

[Spritetm]

You probably need to use the malloc() option as well as reserve some memory for DMA. I'll see if I can get this compiling on master and update the sdkconfig when I have time.

[OtherCrashOverride]

I encountered this too. It seems there is a bug (unconfirmed) that DMA memory that is reserved when using PSRAM is not actually used (SPIRAM_MALLOC_RESERVE_INTERNAL). Setting the reservation value to "0" (it currently defaults to 32K) returns the memory for use and resolved this. However, with the current esp-idf, there is an issue where IRAM is used causing mutex handles to be placed in PSRAM. This causes a panic when anything tries to use and lock a mutex (printf, gettimeofday, etc). To resolve this issue, PSRAM needs to be explicitly requested here: https://github.com/espressif/esp32-doom/blob/085f21b630f11adb69a3894db5a1efa39a7aa31a/components/prboom/z_zone.c#L393

[Spritetm]

OtherCrashOverride: Your fix probably works, but it's not the best solution: the original issue, as you somewhat deduced, stems from esp-idf being perfectly fine allocating queue structures in psram, then balking because it doesn't like that the portmux embedded in that structure is not in internal memory. Fix to esp-idf is coming up.

[pbliss]

Any word on a fix for this? Thanks!

[Spritetm]

This should actually be fixed with a commit merged a while ago. Feel free to retry with the current master branch of esp-idf.

[pbliss]

I pulled the latest esp-idf and tried master and v3 branch. Both give me the same dma error

R_InitData: Textures Flats Sprites Tranmap build [.assertion "dmamem[x]" failed: file "/Users/peterb/esp/esp32-doom-master1/components/prboom-esp32-compat/./spi_lcd.c", line 306, function: displayTask abort() was called at PC 0x400d3b13 on core 1 0x400d3b13: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)

Backtrace: 0x40088f8b:0x3ffd53f0 0x40088fbc:0x3ffd5410 0x400d3b13:0x3ffd5430 0x400840bf:0x3ffd5460 0x40088f8b: invoke_abort at /Users/peterb/esp/esp-idf/components/esp32/./panic.c:572

0x40088fbc: abort at /Users/peterb/esp/esp-idf/components/esp32/./panic.c:572

0x400d3b13: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)

0x400840bf: displayTask at /Users/peterb/esp/esp32-doom-master1/components/prboom-esp32-compat/./spi_lcd.c:299 (discriminator 1)

Thanks!

[danhans42]

I am experiencing the same issue with the master branch. Has anyone managed to get this to work at all as I am getting the same issue as above?

Thanks