esp-rs / espflash

Serial flasher utility for Espressif SoCs and modules based on esptool.py
Apache License 2.0
471 stars 115 forks source link

Bootloader address issue #401

Closed dragazo closed 1 year ago

dragazo commented 1 year ago

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 at 0x3c187fa0, 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 by espflash is incorrect according to ESP-IDF, as it uses 0x3C000000..0x3E000000 (see here) instead of ESP-IDF's definition of 0x3C000000..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 in espflash that controls the external RAM range (as defined here)? Perhaps in the bootloader binary itself? My guess is that the bootloader is using the 0x3C000000..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 actually 0x3D000000..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.

dragazo commented 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.

jessebraham commented 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.

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.