ESP32 Free Heap

[ESP_Sprite]

ICACHE and DCACHE are instruction and data 'windows' into the cached SPI flash. The ICACHE is indeed 3.5M, the DCACHE 512K. The ICACHE can execute code, but can only be accessed in 32-bit increments, the DCACHE is byte-accessible and cannot execute code.

[WiFive]

How does the separate IRAM and SPI cache affect the ability of threads/tasks/ISRs to run on both cores dynamically? Thanks

[tvoneicken]

ICACHE and DCACHE are instruction and data 'windows' into the cached SPI flash. The ICACHE is indeed 3.5M, the DCACHE 512K. The ICACHE can execute code, but can only be accessed in 32-bit increments, the DCACHE is byte-accessible and cannot execute code.

Do you really mean that the instruction cache is 3.5MBytes in size? Or rather that it's much smaller but can cache a 3.5Mbyte size portion of flash?

[ESP_Sprite]

WiFive: It does, somewhat. That is one of the reasons we will slightly change the memory map. SMP is possible on the ESP31 (I've already got a SMP-enabled FreeRTOS prototype on my machine) but it comes with a few disadvantages. The new memory structure of the ESP32 solves that. You can still do AMP on the ESP31 very well, by the way.

tvoneicken: The second. If memory serves, the cache memory itself is 32K. The ICACHE/DCACHE will use that transparently; aside from performance hits in the case of a cache miss, you can view the ICACHE and DCACHE memory regions as a direct view on the SPI flash.

[abruin]

Re: ESP32 Free Heap
Postby Sprite_tm » Tue Dec 15, 2015 5:21 pm

Sure. I have no docs I can release of that, but very quickly: The ESP31 has three regions of RAM: an IRAM for the first cpu at 0x40040000 (which is 128K), an IRAM for the second CPU at 0x3ffa8000 (64K) and a shared RAM at 0x3FFD8000 (192K). The IRAMs actually are 32K bigger than that, but if SPI cache is enabled on the corresponding CPU, that region is not usable. (The addresses I mention are the addresses I know of by which the 1st CPU can addres the memory; they're slightly different for the 2nd CPU and they're also not the only address ranges the RAM is mapped to.)

The SDK puts most of the program code in the IRAM of the first CPU, and the heap+stack in the shared RAM. This means there is still some memory that isn't used by default on the end of the IRAM segment of the 1st CPU. Also, with the 2nd CPU not used as it is in the current SDK, there is 92K of RAM in its IRAM region that is usable but not used by default.

Re: ESP32 Free Heap
Postby rojer9 » Wed Dec 16, 2015 5:41 am

thanks for the explanation of the memory map Jeroen, it makes sense, except for this:
in your reply you mention that the region at 0x3FFD8000 is the shared 192K segment.
but there's only 144K between 0x3FFD8000 and 0x40000000 which is where ROM starts.
does it mean that there is 48K before that that can be used?

@Sprite_tm

Not sure about the above. If the shared RAM is 192K (0x30000) and starts at 0x3FFD8000 then it would end at 0x40008000.
However as Rojer9 points out the on-chip ROM seems to start at 0x40000000 if the exception vector addresses in the SDK are correct.

If the shared ROM starts at 0x3FFD8000 and finishes at 0x3FFFFFFF then it's size would be 0x28000 (160K).

However according to eagle.pro.v7.ld in the SDK it's length is 0x24000 (144KB)
dram0_0_seg : org = 0x3FFD8000, len = 0x24000

So is the shared ROM 144K, 160K, or 192K or are some of the addresses wrong?

Also if the IRAM for the 2nd CPU was 64K + 32K SPI Cache that adds up to 96K instead of the 92K given. Is there a mistake here or am I missing something?

So according to what you have said and eagle.pro.v7.ld this is what I think is the resultant RAM memory map according to the 1st CPU.

IRAM 1st CPU = 128K + 32K SPI Cache = 160K @ 0x40040000
IRAM 2nd CPU = 64K + 32K SPI Cache = 96K @ 0x3FFA8000
DRAM Shared = 144K @ 0x3FFD8000
Total RAM = 400K

The total RAM neatly agrees with the press releases. Is the above memory map correct for ESP31?

Need to know because the amount of DRAM is very important for the application I am working on (Ideally I require a 100K buffer for an incoming stream but I can settle for less).

Thanks, Andy

[rudi ;-)]

finally got the board run.

btw, which ESP board you have?
(8MB, 16MB, 32MB, 1Mbit)

ESP318_spi_1MB.JPG (48.03 KiB) Viewed 19299 times

best wishes
rudi

[ESP_Sprite]

Not sure about the above. If the shared RAM is 192K (0x30000) and starts at 0x3FFD8000 then it would end at 0x40008000.
However as Rojer9 points out the on-chip ROM seems to start at 0x40000000 if the exception vector addresses in the SDK are correct.

Sorry, that was a brain fart from me, the 192KB is pretty much entirely wrong. According to the docs I have, there should be 160KB there; I'll ask around to see if I can find out why the linker scripts only have 144K configured.

Edit: The 'missing' 16K is used for ROM code bss and data and CPU stack.

[ESP_Greg]

iram and cache still need 32-bit aligned, same as ESP8266; but dcache can be read as 8-bit aligned
rodata is in dcache by default in current SDK.

icache used 32KB ram; dcache mapped to spi flash. instruction stored in icache, and data is stored in dcache.

[kolban]

I think this may be a very fundamental question ... I had assumed that when I read that the ESP32 had "512K" of RAM, I could write applications that use 512K minus the amount needed for ESP32 operation itself. However, on a fresh boot of an ESP32 and I ask "What is the amount of heap space free using the esp_get_free_heap_size, I seem to see less than 150K available to me (sorry, I'm not in front of a real system to test ... actual number maybe somewhere between 100K - 200K). My core question is "How is RAM utilized in the ESP32?". What is the expected amount of RAM that would be available for "heap" in a "normal" application both today and in the future?

[WiFive]

I think this may be a very fundamental question ... I had assumed that when I read that the ESP32 had "512K" of RAM, I could write applications that use 512K minus the amount needed for ESP32 operation itself. However, on a fresh boot of an ESP32 and I ask "What is the amount of heap space free using the esp_get_free_heap_size, I seem to see less than 150K available to me (sorry, I'm not in front of a real system to test ... actual number maybe somewhere between 100K - 200K). My core question is "How is RAM utilized in the ESP32?". What is the expected amount of RAM that would be available for "heap" in a "normal" application both today and in the future?

I think I have seen free heap return up to ~250kB out of a total 320kB configured as data RAM with no services started. With wifi running it drops to ~180kB. Now there are a lot of things that are not optimized yet so hopefully we can get some of that back. Then we have 64kB of cache and 128kB of instruction RAM. The instruction RAM is not fully used or optimized so there should be some available there. It also may be possible to reclaim up to half of the cache memory in desperate times.

I think WiFi and bluetooth each use 64kB? Not sure if that is accurate or optimized.