ESP32 RAM Allocation breakdown

[noman.cyclewala]

As per the specifications of ESP32 it has total of 520KB of RAM. Is there any document where i can see the complete breakdown of where All the Ram is being allocated and used?

Is there any way to reconfigure or resize the total heap section and other sections of the RAM.

I have tried a simple demo of "Hello world" and printed free heap which shows around 298KB of free heap. So i would like to know where the rest of the RAM is being used and a guide or document for the configuration for it so i can increase the heap size if possible.

[WiFive]

Heap uses what is left after static data and iram and cache requirements so you can't increase it without decreasing something else.

[PeterR]

It is complicated & no, I have not found a reliable guide.
The 520K headline is; IRAM, DRAM (some of which may also be stolen as IRAM), Cache, RTC Fast & RTC slow memory.
I believe that we have 320K (ish) of DRAM and some of that may be allocated as IRAM (but practically does not seem to be).
For data use you can dynamically steal from IRAM if you only access using 32bit. There does appear to be a good amount of IRAM left over these days to try but...
One source of confussion is that the capability reports report exactly as stated on the tin. I ask for an IRAM report and I am told about 'pure' IRAM but also DRAM which may be used as IRAM. If I actually used that IRAM I would also take a hit on DRAM. That is to say that if you report on each capability you may well get a number >> 520KB (& you only have 520KB)

RAM disappears through; .bss, .data and heap allocation. All your auto variables will be on stack & so heap (either main thread or your own C++11 thread/FreeRTOS task). The documentation also suggests that Bluetooth reserves 64KB by moving memory base. Selecting the Bluetooth option certainly does gives a hit (even if you don't call a library function), I have not checked if this hit is .bss/.data or if moving memory base (& also some .bss/.data).

You can get reports on .bss and .data using:

Code: Select all

make -size-components

and in detail:

Code: Select all

make -size-files

Depending on which components you use.bss and .data (EDIT: & menuconfig options) will cause you to start with free heap of between 290KB and 200KB, probably less if you mix Bluetooth and Wifi and etc, etc (EDIT & then when you start Wifi or Bluetooth mode you will take an instant heap hit & may well then also take a dynamic heap hit from time to time as external factors influence (see my moan on dynamic buffers). You say 300KB which seems possible, I always use Ethernet so I have not checked without. I have not used all components & things like mdns using 2KB plus .bss/.data suprise me (I would have assumed auto & even then the frame buffer seems large).

You can force some .bss into PSRAM BTW but then you need to be careful with ISRs and run time performance.

Heap allocation is harder to track. I resorted to printing the available heap after each system and/or component initialisation call.
Wifi and Bluetooth heap use appear to be well documented but I (for one) still struggle to understand when dynamic frames come into play & why we need as many dynamic frames as static (except if advisory that I should balence the two).

Welcome to resource constrained embedded! It will stop you going senile but may otherwise drive you mad.