ESP32 Forum

Posted: **Fri Dec 14, 2018 1:29 pm**

I am looking for advise as to how to reduce IRAM footprint and/or reallocate more.

Presently I have; Wifi, Ethernet, BLE, SDCARD and use CAN, SPI, I2C, RMT.
I will be adding SPIFFS, mDNS, HTTP and an MQTT broker if I can find one.

The story so far using v3.2-beta1-34-gfb7ba1baa
Integrated my standalone BLE server into the main build and receive the dreaded:

Code: Select all

ld.exe: IRAM0 segment data does not fit.
ld.exe: region `iram0_0_seg' overflowed by 1708 bytes

Modified esp32.ld and bumped IRAM to 0x40000 allowing:

Code: Select all

make -j8 size-components

 DRAM .data size:   14624 bytes
 DRAM .bss  size:   44920 bytes
Used static DRAM:   59544 bytes (  65036 available, 47.8% used)
Used static IRAM:  132780 bytes ( 129364 available, 50.7% used)
      Flash code:  964264 bytes
    Flash rodata:  280584 bytes
Total image size:~1392252 bytes (.bin may be padded larger)
Per-archive contributions to ELF file:
            Archive File DRAM .data & .bss   IRAM Flash code & rodata   Total
                 libbt.a        366  26459   1230     362968    81866  472889
             libstdc++.a        148   4268      0     113026    64795  182237
               liblwip.a         19   3857      0     111924    17132  132932
 libc-psram-workaround.a       1744     32  14197     104751     5351  126075
              libesp32.a       2498   2645  23850      27761    29503   86257
             libdriver.a        135    171   7716      38910    32164   79096
           libbtdm_app.a        255   2261  17885      44543     3819   68763
                libphy.a       1284    915   5710      29030        0   36939
           libfreertos.a       4156    776  21294          0     2320   28546
              libfatfs.a          4     47      0      20935     1314   22300
          libnvs_flash.a          0     32      0      16599     3345   19976
              libtests.a          0      0      0      14165     4108   18273
              libsdmmc.a          0      0      0      11263     4192   15455
                libsoc.a        161      4   7976        889     4230   13260
         libble_server.a        534     66      0       3501     9098   13199
          libcandriver.a          0      0      0      10640     2309   12949
          libspi_flash.a         36    323   9182       1546     1760   12847
           libethernet.a          8    343    508       8943     2498   12300
               libheap.a       1378     34   7325       1805      968   11510
                libvfs.a        240    103      0       7659      583    8585
            libcoexist.a       1365    115   4352       1666        0    7498
                libgcc.a          4     20    104       5556      888    6572
               libhwci.a          0     60     78       4102     1556    5796
        libesp_ringbuf.a          0      0   4716          0      459    5175
               libmain.a          0      0      0       2813     1824    4637
      libtcpip_adapter.a          0    124      0       3789      408    4321
             libnewlib.a        152    272   1517       1597      191    3729
            libpthread.a         16     12    599       1571      718    2916
               libleds.a          0      0      0       2433      349    2782
                librtc.a          0      4   2346          0        0    2350
           libnet80211.a         12   1021     20        370      917    2340
                liblog.a          8    268    596       1285      134    2291
                libcxx.a         12     16      0       1105      489    1622
    libsmartconfig_ack.a          0      1      0        930      312    1243
             liblogger.a          4    516      0        330      102     952
         libapp_update.a          0      4      0        199      745     948
                libhal.a          0      0    515          0       32     547
     libwpa_supplicant.a          0      0      0        146        0     146
libxtensa-debug-module.a          0      0     46          0        0      46
 libbootloader_support.a          0      0      0          0        0       0
               libcore.a          0      0      0          0        0       0
           libextflash.a          0      0      0          0        0       0
              libflash.a          0      0      0          0        0       0
            libmbedtls.a          0      0      0          0        0       0
               libmesh.a          0      0      0          0        0       0
                 libpp.a          0      0      0          0        0       0
                libwpa.a          0      0      0          0        0       0
               libwpa2.a          0      0      0          0        0       0
                libwps.a          0      0      0          0        0       0

Its surprising how quick the figures add up. There seem to be some greedy IDF libraries. I have barely used 100 bytes.
How should I proceed? For example librtc used 2346 and I am fairly sure I do not use it, not directly at least.

Posted: **Fri Dec 14, 2018 1:36 pm**

If not already done then would recommend enabling make menuconfig -> Compiler options -> Optimization Level (Release). Well this does not really answer your question but can serve as quick fix.

Posted: **Fri Dec 14, 2018 1:55 pm**

Thanks, drops me to:

Code: Select all

Used static IRAM:  120516 bytes

Which gives me a little breathing space but that 8K will go fast.

1) What did I lose with the release compile option? Did I loose back trace or anything?
2) How do I trim and/or remove some of the greedy modules?

EDIT: For example I can see that libheap has 6.5K - why would I want to malloc() in IRAM and how do I stop that resource allocation?
Probably basic questions but I have not needed to play with the build system yet.

Posted: **Fri Dec 14, 2018 4:02 pm**

I encountered the same issue when switching from a master IDF commit to v3.2, I also use BT classic, WiFi, CAN, SPI, HTTP, SPIFFS
for now I went back to commit a8754cc, but I really need a solution for this

Posted: **Sun Dec 16, 2018 4:42 pm**

PeterR wrote: ↑
Fri Dec 14, 2018 1:55 pm
Thanks, drops me to:
Code: Select all
Used static IRAM:  120516 bytes
Which gives me a little breathing space but that 8K will go fast.

1) What did I lose with the release compile option? Did I loose back trace or anything?
2) How do I trim and/or remove some of the greedy modules?

EDIT: For example I can see that libheap has 6.5K - why would I want to malloc() in IRAM and how do I stop that resource allocation?
Probably basic questions but I have not needed to play with the build system yet.

One more thing which you forgot is that you can use PSRAM as well which is of 4 MB to allocate memory as per requirement.

You also need to do some analysis of map file generated so that you can have idea like where more memory is allocated into IRAM section. Also, You can play with LD Scripts as per your requirement

Posted: **Mon Dec 17, 2018 10:10 am**

I encountered the same issue when switching from a master IDF commit to v3.2, I also use BT classic, WiFi, CAN, SPI, HTTP, SPIFFS for now I went back to commit a8754cc, but I really need a solution for this

Thanks, I will check.
The problem with the older releases is that there are some serious real-time problems. Just look at how many times 'atomic' has been added!

One more thing which you forgot is that you can use PSRAM as well which is of 4 MB

PSRAM won't cut it when I start needing to improve my interrupt handlers latency.
I could go through the IDF and spot the IRAM attributes but would rather not as then I have to track other changes.

Can someone explain what changes I get when I move to production building (as recommended)?
Also how to remove unwanted modules like librtc ?

Posted: **Mon Dec 17, 2018 10:22 am**

PeterR wrote: ↑
Mon Dec 17, 2018 10:10 am

I encountered the same issue when switching from a master IDF commit to v3.2, I also use BT classic, WiFi, CAN, SPI, HTTP, SPIFFS for now I went back to commit a8754cc, but I really need a solution for this
Thanks, I will check.
The problem with the older releases is that there are some serious real-time problems. Just look at how many times 'atomic' has been added!

One more thing which you forgot is that you can use PSRAM as well which is of 4 MB
PSRAM won't cut it when I start needing to improve my interrupt handlers latency.
I could go through the IDF and spot the IRAM attributes but would rather not as then I have to track other changes.

Can someone explain what changes I get when I move to production building (as recommended)?
Also how to remove unwanted modules like librtc ?

First of all, check it using make menuconfig and disable all not required components. then please check map file with IRAM 0 section like which components are taking much memory. so based on that report you can decide what to do next for that

Posted: **Mon Dec 17, 2018 10:46 am**

Thanks Ritesh but please read the posts.

We know that we need to remove some modules & have already posted the map summary along with a few suggestions.
We are looking for concrete suggestions and/or an IDF fix.

The IRAM options are not in menuconfig or at least are not obvious. The compiler option was a help FTM.
I suspect that IDF is using IRAM simply to speed up processing. Without knowing more about the IDF I cannot be sure however.
If I remove IRAM attributes is something going to crash down the line?
I would rather not fight the IDF as well as my application!

So we are looking for hands on experience and ideally a friendly ESP man to hold our hand.

I can see that libheap uses 6500 bytes. Can I just remove the IRAM attribute from all its functions? Something tells me that there is a dependency chain to understand here.

Posted: **Mon Dec 17, 2018 11:43 am**

Had a closer look.
We need ESP support. IRAM is used extensively in closed source libraries and/or in things which may be called from an interrupt.
If called from an interrupt then we need to know how the interrupt was registered.

If I were to pick my top 10 list then I would ask why libbtdm_app.a uses so much IRAM. Probably a BT stack response requirement?
Next I would question if removing IRAM attribute from libheap.a would be reliable.

Perhaps we can prune libfreertos.a
My understanding is that only stuff which has been used will be brought into the build. So again we need to understand which parts of the IDF uses what and not add anything.

Its not looking great though.
Now I need to understand FLASH fetch latency.

Wonder if I can reduce second processor cache?

Posted: **Mon Dec 17, 2018 4:21 pm**

PeterR wrote: ↑
Mon Dec 17, 2018 10:46 am
Thanks Ritesh but please read the posts.

We know that we need to remove some modules & have already posted the map summary along with a few suggestions.
We are looking for concrete suggestions and/or an IDF fix.

The IRAM options are not in menuconfig or at least are not obvious. The compiler option was a help FTM.
I suspect that IDF is using IRAM simply to speed up processing. Without knowing more about the IDF I cannot be sure however.
If I remove IRAM attributes is something going to crash down the line?
I would rather not fight the IDF as well as my application!

So we are looking for hands on experience and ideally a friendly ESP man to hold our hand.

I can see that libheap uses 6500 bytes. Can I just remove the IRAM attribute from all its functions? Something tells me that there is a dependency chain to understand here.

Sorry. We are still working on ESP32 IDF 3.0 and 3.1 IDF for our application development purpose.

So, I need to check your issue into ESP32 IDF 3.2 and development branch but might be Espressif Systems SDK Engineer can help you for your requirement for IRAM issue.

I will also look for same thing and will let you know if find anything for that.

ESP32 Forum

IRAM0 segment data does not fit

IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit

Re: IRAM0 segment data does not fit