Closed dragazo closed 1 year ago
The underlying issue was apparently caused by memory corruption from stack overflow, but I'm still curious why the DROM ranges appear to be different than ESP-IDF expects.
The underlying issue was apparently caused by memory corruption from stack overflow, but I'm still curious why the DROM ranges appear to be different than ESP-IDF expects.
We just copy whatever values are used in esptool.py
, not sure why they're different from ESP-IDF but that's what we've always done. A separate team develops esptool.py
so you would need to ask them 😁
Don't think there's anything actionable here so closing this issue, feel free to re-open if you disagree of course.
I'm having an issue with my project crashing upon ESP-IDF trying to lock the global mutex that protects
malloc
. The issue is elaborated here. One of the findings was that said mutex is allocated at0x3c187fa0
, which for my ESP32-S3 device is within the DROM range as defined here. This is clearly wrong since a mutex cannot be read-only, but I'm trying to figure out what's causing that to happen. In trying to look for a cause for this, I discovered the DROM address range used byespflash
is incorrect according to ESP-IDF, as it uses0x3C000000..0x3E000000
(see here) instead of ESP-IDF's definition of0x3C000000..0x3D000000
.But this wouldn't fully explain my problem since it still puts the mutex in the
0x3Cxxxxxx
range of DROM. But if one thing is wrong, there could be others. Is there some other range somewhere inespflash
that controls the external RAM range (as defined here)? Perhaps in the bootloader binary itself? My guess is that the bootloader is using the0x3C000000..0x3E000000
range that is typical for ESP32 devices and this mutex is meant to be allocated in PSRAM, but the PSRAM range in ESP32-S3 devices is actually0x3D000000..0x3E000000
(see link above).I realize this only affects projects that use ESP-IDF, but there should at the very least be a CLI flag I can pass to fix these ranges if the default is incompatible.