I've now also results from testing different heap placements in the SPIRAM address space. I've done these tests on branch "master" with duktape running on core 1 (= no heap corruption crashes). To shift the duktape heap location into the upper SPIRAM regions, I added this modification to DukTapeInit(): * void *shiftmem = ExternalRamMalloc(2*1024*1024);* umm_memory = ExternalRamMalloc(memsize); * ESP_LOGI(TAG, "Duktape: shiftmem=%p umm_memory=%p", shiftmem, umm_memory);** ** if (shiftmem) free(shiftmem);* I've tried shifting into the upper 2 MB as shown here, and then shifting by just 1 MB up to place the head at the upper end of the lower 2 MB (so memory corruption by other processes is unlikely). I've then run the event test script 15 times until aborted by the error and collected the total loop counts. Result: there is a strong correlation between the heap memory half used and the error frequency: with the heap in the upper half (shifted by 2 MB), the loop will run *>10x longer* on average than with the heap in the lower half. In absolute numbers: the average loop count with the heap in the lower 2 MB SPIRAM was ~ 3,000, with the heap shifted into the upper 2 MB it was ~ 40,000. Within the lower half, there is no difference between shifting by 1 MB and no shifting, so it's most probably not caused by some other process corrupting the duktape heap region. My conclusion would be now, this is still the SPIRAM bug, or a previously undetected variant thereof. Can some others please try to reproduce my results? Regards, Michael Am 17.09.21 um 10:56 schrieb Michael Balzer:
I just remembered…
https://github.com/espressif/esp-idf/issues/2892#issuecomment-459120605
…and as Duktape runs on core #1, I now test shifting the Duktape heap into the upper 2 MB of SPIRAM.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26