High IRAM (93.6%) usage in wifi_provisioning component (IDFGH-8550)

[gkoumanos]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

We have experienced very high IRAM usage when wifi_provisioning component is used.
ESP-IDF version: v4.2.4

user@machine: ~/esp/esp-idf/examples/provisioning/wifi_prov_mgr$ idf.py size
...
Used static DRAM:   42640 bytes (  81940 remain, 34.2% used)
      .data size:   16088 bytes
      .bss  size:   26552 bytes
Used static IRAM:  122665 bytes (   8407 remain, 93.6% used)
      .text size:  121638 bytes
   .vectors size:    1027 bytes
...

Similar results appear on ESP-IDF 4.2.1 and 5.1.
This leaves no space for our code. Is this normal?

[Harshal5]

Hello, @gkoumanos

The wifi_prov_mgr example combines both WiFi and Bluetooth libraries and hence the IRAM usage is higher. Please follow the IRAM optimizations guide if you would like to optimize the IRAM usage.

Thank you.

[gkoumanos]

Thank you @Harshal5
The IRAM optimizations don't seem to be available in ESP-IDF version: v4.2 though which is very hard to change for us.

[mahavirj]

@gkoumanos

• If you need additional IRAM for your own application, then you may consider using FreeRTOS in single core mode (CONFIG_FREERTOS_UNICORE). It shall free up 32K cache memory which can be used as IRAM.
• You can consider disabling some IRAM optimization flags like CONFIG_ESP32_WIFI_IRAM_OPT, CONFIG_ESP32_WIFI_RX_IRAM_OPT and CONFIG_LWIP_IRAM_OPTIMIZATION if they are enabled in your case
• You can try to build your application with CONFIG_COMPILER_OPTIMIZATION_SIZE, it may help to compact code size a bit

[mahavirj]

@gkoumanos Interim, any specific reason you would like to keep your code in IRAM? Given its v4.2 release which is quite old, I do not see any other suggestions that may help here apart from the ones I gave in my earlier comment.

[gkoumanos]

@mahavirj

any specific reason you would like to keep your code in IRAM?

We request no IRAM usage explicitly. We weren't even aware of this till we had to use the wifi_provisioning component.
All our "needs" are added from IDF itself. Any way to address this?

[mahavirj]

@gkoumanos

Did you try out suggestions from my earlier comment?

[gkoumanos]

Sorry, I forgot to mention. All your suggestions were previously applied before opening this issue.

[mahavirj]

All your suggestions were previously applied before opening this issue.

Okay. Can you please share your sdkconfig? After applying above suggestion, I do not think IRAM utilization should be ~93% for wifi_provisioning example, I would expect at-least gain of 40-45K gain in IRAM.

We request no IRAM usage explicitly

Sorry, I am still not quite clear on your requirement. If you have no requirement for explicit IRAM, then even current configuration should work for you, right? Just note that, most of the firmware code lies in flash and executes directly from flash itself. Are you facing any build time issues? If yes, can you please share logs?

[gkoumanos]

I only used the wifi_provisioning example as reference to avoid sharing our closed-source code. Our code uses 77.3% of IRAM simply by using ESP-IDF and some components BEFORE trying to add wifi_provisioning component.
We cannot enable CONFIG_FREERTOS_UNICORE in our code due to performance issues. The rest of the optimizations were applied under 4.2.1.
Please find attached our sdkconfig below:
sdkconfig.txt

For your reference here are some of the results of my tests with wifi_provisioning example:

Code	Used	Avail	%
example wifi_prov_mgr @v4.2.1	121609	9463	92.8
example wifi_prov_mgr @v4.2.4	122665	8407	93.6
example wifi_prov_mgr @v4.4.2	118862	12210	90.7
above 4.4.2 with all optimisation	89910	41162	68.6
example wifi_prov_mgr @master	124506	6566	95.0
above master with all optimisation	97166	33906	74.1

Our requirement is to add wifi_provisioning component into our code but it seems impossible with 4.2.1 and pretty much any IDF version. Please confirm...
Is there a way to use one core for BT and WiFi and the other core for user tasks?

[mahavirj]

@gkoumanos

Your analysis looks correct. Unfortunately, there are no additional config option apart from the ones you already tried.

Our code uses 77.3% of IRAM simply by using ESP-IDF and some components BEFORE trying to add wifi_provisioning component.

Just to double check, does your code already integrates WiFi/BT libraries before trying to add wifi_provisioning component? If yes, then actual overhead due to wifi_provisioning component might be much less compared with numbers you shared above. Might be worth integrating the wifi_provisioning component once in your application and checking for actual IRAM overflow.

Is there a way to use one core for BT and WiFi and the other core for user tasks?

Please check out relevant config options 1 and 2

[gkoumanos]

@mahavirj

Just to double check, does your code already integrates WiFi/BT libraries before trying to add wifi_provisioning component?

It does implement WiFi but no BT/BLE.

Might be worth integrating the wifi_provisioning component once in your application and checking for actual IRAM overflow.

We have already done that (this is why we raised this issue):

Linking .pio/build/dev/fw_debug_0.3.23.elf
fw_debug_0.3.23.elf section `.iram0.text' will not fit in region `iram0_0_seg'
IRAM0 segment data does not fit.
region `iram0_0_seg' overflowed by 468 bytes

Please check out relevant config options 1 and 2

Thank you. We tried these and they do not seem to affect IRAM. It was a wild guess (out of desperation :) )

[mahavirj]

@gkoumanos

We have on outstanding feature request on this topic at #9824 (please also see #7876 (comment)).

Interim, is it possible to share .map file of your project, I will see if I can find any quick solution for your issue?

[gkoumanos]

@mahavirj I subscribed to #9824 in case it gets updated in the future.
For the moment using only configuration options we managed to drop to 97.1% of IRAM which is great news as we can link and flash but it gives great uncertainty for the future to keep it that high. I'll be glad to share the map file with you but not publicly. Is there a way to do so?

[mahavirj]

@gkoumanos You can add me as collaborator on your private repository or you may also directly email me (please look out for address in IDF commit message)

[mahavirj]

As discussed offline, we do not see any further optimization scope in IRAM numbers.

Adding couple of things that we found for future reference purpose:

1. For ESP32 ECO3 with SPIRAM enabled case, setting CONFIG_ESP32_REV_MIN to 3 can help to save ~10K IRAM. This is now documented with 07fe9ca
2. Moving to IDF v5.0 release can provide more flexibility w.r.t. placement of FreeRTOS symbols in flash. This can further help to save the IRAM memory.

I would suggest that we track this issue through #9824 which may further help in this regard. Closing this one.

[ESP-Marius]

On latest master we've added a kconfig option for using parts of SRAM1 as IRAM in 5cbd311 which will help with this issue.

We've also focused on reducing IRAM usage/making placement optional for several components. For an full overview of all such option see Optimizing-iram-usage. All new options for saving IRAM we add will be listed in this chapter.

[jaimelaguia]

I usually check this list first https://docs.espressif.com/projects/esp-idf/en/v5.1/esp32s3/api-guides/performance/ram-usage.html. Nowadays, i have need decrease the iram wifi consumption. If you have SPIRAM, you can change in "SPI RAM config" the access method of the spi ram to "CONFIG_SPIRAM_USE_CAPS_ALLOC=y". Then the "Wi-Fi" configuration allows to use "Type of WiFi TX buffers(dynamic)" instead of static ones. In addition you can put "Max number of WiFi static RX buffer" in 2 and "WiFi AMPDU RX BA window size" in 2 too. This steps free 14% iram in my project.