On ESP32 what ram is available for application use and how?

[yanshay]

In ESP32 - Looking at https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/ld/esp32/memory.x, it seems like DRAM is split into two memory addresses: dram_seg and dram2_seg.

Can my program use both? Do I need to do anything special to utilize both of them or is it automatic?
I need a large contiguous array, so want to understand how to optimize the memory resources available.

[bjoernQ]

Yes, it's split because there is some RAM reserved for ROM functions which we should not touch.

dram2_seg is automatically used as wifi heap in esp-wifi. If you want to allocate something there you could do the same esp-wifi does: https://github.com/esp-rs/esp-wifi/blob/6f438e33bbac2d37abe522470b3afd648e858573/esp-wifi/src/lib.rs#L145

[yanshay]

I tried using dram2_seg along how it's done in esp_wifi.

For heap usage - I did that by adding #[link_section =".dram2_uninit"] on the relevant HEAP array.
It worked for a basic program for the heap but it didn't when I tried it on more complex program.
After many trials, I noticed that that prior to activating the second core all works well, but right after I activate the second core allocations fail.
Eventually I managed to get it working by reserving 4kb (2kb wasn't enough) placeholder before the actual heap data rea I'm using on dram2_seg.

While it seems to be working now, it's probably not the right way to do it.

I also tried placing the second core stack in dram2_seg. Before the discovery about the need for 4k placeholder, the core just would't start - meaning, the function I provided to start_app_core wasn't called. When I added the placeholder it worked but it wasn't consistent, sometimes things crashed (I use the 2nd thread for wifi, and I'm using embassy). Everything works just fine when the stack is not in dram2_seg.

Any ideas what is casuing that behavior and what's the proper way to allocate memory on dram2_seg w/o conflicting with whatever is there in the early addresses? I wonder how that conflict doesn't happen to the wifi code as well (or maybe it does but only more complex wifi scenarios than I'm using).

[bjoernQ]

#1085 might be related to this

[bjoernQ]

#1289 should fix it