ESP32 Forum

Hi
I am getting low on IRAM. Optimization reduced the usage but still on the edge. I am using a lot of components from ESP-IDF but not everything at the same time.

Below is a "functional description of my architecture.
I assume that the static analyze of IRAM usage summarize it all, i.e I2C+Nimble BLE+WIFI+ESP-MQTT+NTP.

This will never happen so the indicated IRAM usage is much to high.

Before the optimization I was using to much IRAM so I could not flash my device.
As I describer the actual usage is lower then what the static analyze shows.

Is there a way to disable this IRAM check so I can load my code even if the analyze says I use to much.

Hi.

If by "IRAM" you are actually referring to "Instruction RAM" (not generally "internal RAM"), I believe you're out of luck.
AFAICT, whether a function/ISR is located in IRAM or not is statically defined at build-time, IRAM space is statically allocated to pieces of code and that allocation cannot change during runtime. There is no way to "unload" such a function/ISR from IRAM and load in another one in its place at runtime.
It should be possible to "manually" copy code from flash to IRAM as&when needed, but that would open another can of worms with regard to building/linking and relocation, not to forget the necessary memory management. Obviously, the former issue is solvable somehow as proven by the existence of IRAM functions...

It seems that using OVERLAYs in the liker script would take care of the build-time stuff (see https://ftp.gnu.org/old-gnu/Manuals/ld- ... ld_22.html), allowing you to build/link multiple sections which expect to be all executed from the same address at runtime. With that, you'd "only" have to copy the desired section from flash to IRAM when needed and make sure that everybody knows which function is currently loaded, or rather, which one is not, so as to not call the wrong code.

Would be interesting to explore, but "hacking" the IDF to join that game is probably not worth it.

Note that stuff is generally in IRAM because at the time it needs to be called, the flash memory may be unavailable... so using overlays wouldn't work either in that case.

Not sure if many people are aware of that, i.e. the point that they should only select code for IRAM which needs to be able to run during write accesses to flash (mainly OTA or nvs, if I'm not mistaken). I know it's documented, but maybe not as clearly as it could be.

@ESP_Sprite In your experience, is reduced ISR latency/jitter another valid reason to go to IRAM, or does it not really make a difference?

MicroController wrote: ↑

Thu Feb 16, 2023 3:54 pm

@ESP_Sprite In your experience, is reduced ISR latency/jitter another valid reason to go to IRAM, or does it not really make a difference?

Yes, it's also a reason some people put stuff in IRAM: if not there, it has to come from flash via the cache and if it's a relatively lightly used function, it may be pushed out of cache which means it needs to be loaded from flash again (slower) when used. Putting the routine in IRAM stops that from happening. However, functions for which this is done tend to be pretty small.