ESP32: .iram0.text overflow with recent IDF versions
#8260
Comments
|
I'm successfully building esp-idf v4.4rc1 with micropython master. I'm targeting ESP32 d4, ESP32 S2, and ESP32 S3. |
|
I don't know if this is useful but here is an idf.py size-components diff report between GENERIC_SPIRAM and GENERIC using esp-idf V4.4 showing the static IRAM overflow. |
|
Interesting! Thanks for this @russhughes. Inspired by this I've used The worst culprit, The Gist of code for doing comparison for reference. |
|
There are at least 2 factors here for running out of iRAM:
|
|
Thanks for the background @dpgeorge. I just attempted a new 4.3.2 For interest, changes in So quite a surprising number of large reductions. Off to dig out a microcontroller to test this build on… |
|
I'm also seeing boot loop issues with latest master and IDF4.4 release on my TinyPICO (has SPIRAM) - working fine on my S2 and S3 boards. So it seems we will need to remove some of the IRAM optimisations for PSRAM boards @dpgeorge ? Is that even possible to do on a per board level? |
|
@UnexpectedMaker can you test the plain
Yes. Define relevant macros in |
|
GENERIC still boot loops my TinyPICO. |
|
Yes, at the moment I'm not convinced that the boot loop failure on v4.4 tag builds is the same IRAM problem as the other stuff I've been hitting. The backtrace I got suggested a bad pointer
8000
in the UART initialisation. I've not had time to dig deeper into it though – I've gone back to 4.3.2 and am building |
|
Have opened #8277 about the v4.4 problem – it's not a build problem by the looks of things. |
.iram0.text overflow with recent IDF versions
|
[Focusing on the main issue from all of this noise that I've generated:] Given there's a clear constraint on |
These boards do not build with IDF v4.4 because the section .iram0.text does not fit in region iram0_0_seg. Enabling SPIRAM increases the code size so use -Os instead of -O2 to build these boards. Fixes issue #8260.
|
GENERIC_SPIRAM and UM_TINYPICO (which also uses SPIRAM) are now unconditionally built with -Os instead of -O2, as of ae3d528. I think that's a reasonable thing to do, otherwise things get too complicated. This issue should be able to be closed now. |
the note is in its attack phase
|
I am seeting the same again at this very moment. A clean micropython pull and esp-idf 5.0.2 (which is imho the version currently supposed to use) results in:
|
I do not get that with a GENERIC_ESP32 build. Which board variant did you try? |
|
Ah, sorry. It's with
Going back to tag v1.21.0 fixes this. But current git fails. |
|
Confirmed. The SPIRAM board variant fails to build. It came with commit: |
|
See #13131. |
I'm seeing a bunch of problems building against different versions of the IDF. All of the following is building 102cc12 with 2 of my patches integrated on top (#6263 and #7582).
A
GENERICESP32 build against the latest v4.4 tag results in a binary that explodes on boot:Switching to v4.3.2 works, but I am unable to do a matching
GENERIC_SPIRAMbuild (for the other boards that I use) as it seems to be overflowing theiram0memory segment:I have verified that this is the same building against
masterwithout my patches.This last error is a little outside my area of expertise: I'm not actually familiar with the ESP32/MicroPython memory model. I did a little hunting to see if I could figure out what's in that
textarea and why it's suddenly overflowing with v4.3.2, but nothing immediately jumped out at me. I'm also not sure how the size of the regions is configured.Backing up one more version to build against v4.3.1 appears to work OK, but suffers from the missing memory problem documented in #7813
This is about 109000 free on a straight MicroPython 1.18 GENERIC download.
Going back to v4.0.2 I get seemingly good builds for both
GENERICandGENERIC_SPIRAMand my memory back:Is the moral of this tale: do not attempt to build MicroPython against any version of the IDF more recent than v4.0.2?
I've been using v4.3.1 for ages, but always with a
GENERIC_SPIRAMbuild so I hadn't noticed the missing memory on a non-SPIRAM device until yesterday.The text was updated successfully, but these errors were encountered: