Out of static IRAM
Posted: Wed Aug 29, 2018 8:49 am
Dear All,
I believe many of us tried to get as much as possible from ESP32, so I hope at least someone ran into this problem already.
In my project I use BLE (as a peripheral only) and WiFi simultaneuosly. WiFi connection in turn is used to communicate with AWS IoT services and libsodium is used internally for some data encryption. In order to get enough RAM I've decided to go with ESP32-WROVER module with on board SPI RAM and external 16Mb flash for OTA updates. Everything worked fine so far until I tried to add a simple gpio interrupt handler marked with IRAM_ATTR, and after compiling the code I've got the following error:
I don't have any code in my project with IRAM_ATTR, so obviously it's ESP IDF components filled all IRAM available. I have tried running my interrupt code without IRAM_ATTR, it works, but is far as I understand it is not advisable to do so with time-critical stuff like GPIO interrupt handlers.
My question is there any way to decrease the static IRAM usage by ESP IDF components (either via menuconfig or any other technique) leaving at least some IRAM for my own performance critical code? The obvious solution of removing some libraries and functionality from the project is not an option unfortunately.
Please see the output of "make size components" below:
I believe many of us tried to get as much as possible from ESP32, so I hope at least someone ran into this problem already.
In my project I use BLE (as a peripheral only) and WiFi simultaneuosly. WiFi connection in turn is used to communicate with AWS IoT services and libsodium is used internally for some data encryption. In order to get enough RAM I've decided to go with ESP32-WROVER module with on board SPI RAM and external 16Mb flash for OTA updates. Everything worked fine so far until I tried to add a simple gpio interrupt handler marked with IRAM_ATTR, and after compiling the code I've got the following error:
Code: Select all
/home/user/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/user/projects/test-fw/build/test_fw.elf section `.iram0.text' will not fit in region `iram0_0_seg'
/home/user/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 47 bytes
My question is there any way to decrease the static IRAM usage by ESP IDF components (either via menuconfig or any other technique) leaving at least some IRAM for my own performance critical code? The obvious solution of removing some libraries and functionality from the project is not an option unfortunately.
Please see the output of "make size components" below:
Code: Select all
$ make size-components
Total sizes:
DRAM .data size: 15728 bytes
DRAM .bss size: 33112 bytes
Used static DRAM: 48840 bytes ( 66360 available, 42.4% used)
Used static IRAM: 130951 bytes ( 121 available, 99.9% used)
Flash code: 799362 bytes
Flash rodata: 145076 bytes
Total image size:~1091117 bytes (.bin may be padded larger)
Per-archive contributions to ELF file:
Archive File DRAM .data & .bss IRAM Flash code & rodata Total
libbt.a 473 2428 1492 142739 10746 157878
libmbedtls.a 92 272 48 117261 19453 137126
libnet80211.a 314 9221 3565 109308 13178 135586
liblwip.a 19 3876 10538 88513 15254 118200
libc-psram-workaround.a 751 28 9628 63164 3887 77458
libesp32.a 3070 601 18782 25799 25201 73453
libpp.a 1229 5274 13275 45250 4208 69236
libbtdm_app.a 367 4695 19502 36070 3135 63769
libphy.a 1282 910 5666 29657 0 37515
libfreertos.a 4152 776 20938 0 2489 28355
libdriver.a 83 41 2871 12893 10709 26597
libspiffs.a 0 12 0 24236 1607 25855
libwpa.a 0 682 0 20941 2312 23935
libmain.a 451 2592 0 9784 10552 23379
libnvs_flash.a 0 32 0 13692 3192 16916
libwpa_supplicant.a 0 0 0 13553 2318 15871
libspi_flash.a 36 323 7044 1577 1723 10703
libaws_iot.a 0 25 0 9022 1622 10669
libsoc.a 657 8 4814 731 4085 10295
libheap.a 864 8 3585 1229 904 6590
libgcc.a 4 20 104 5568 888 6584
libvfs.a 232 103 0 5625 401 6361
libcoexist.a 1365 106 3708 0 0 5179
libbootloader_support.a 0 4 0 2525 1474 4003
libstdc++.a 8 20 0 2689 1253 3970
libtcpip_adapter.a 0 124 0 2977 377 3478
libapp_update.a 0 80 0 2132 785 2997
librtc.a 0 4 2308 0 0 2312
libnewlib.a 152 272 830 871 84 2209
libi2cdev.a 0 56 0 1187 512 1755
libpthread.a 16 12 178 874 632 1712
liblog.a 8 268 478 740 162 1656
libcore.a 0 5 0 799 417 1221
libsmartconfig_ack.a 0 1 0 778 312 1091
libds3231.a 0 0 0 822 0 822
libhal.a 0 0 515 0 32 547
libfactory_nvs.a 0 16 0 311 158 485
libmesh.a 1 1 0 55 0 57
libcxx.a 0 0 0 11 0 11
libwpa2.a 0 1 0 0 0 1
libwps.a 0 1 0 0 0 1
libethernet.a 0 0 0 0 0 0
, this really solves the issue for now, would be great though if Espressif team can plan some further optimizations of IRAM usage by IDF components, even with some performance penalties, because 91.9% is still a high figure and I can imagine a situation when this may be not enough for user application.