Understanding free heap memory

artkeller
Posts: 2
Joined: Sat Feb 03, 2018 8:11 am

Understanding free heap memory

Postby artkeller » Sun Sep 09, 2018 11:42 am

I have long wondered why - in contrast to other MCUs architectures - there is so much discussion and speculation about free memory management on ESP32. This seems to be not only a compiler problem, as discussed here, but above all a general memory management problem and the understanding of the internal structure and its limits. Not only after compilation the memory usage is relevant, also during runtime the memory limits must be dynamically recognizable. I realize that this thread is not the best place for my question, but there is a strong inner relationship to the discussion in this thread, since there is obviously no really reliable information. There is too much speculation.

My question seems old but still unanswered: What exactly is the difference when calculating the heap with esp_get_free_heap_size() or with esp_get_minimum_free_heap_size()? I don't think the heap return value with esp_get_free_heap_size() is realistic enough, but when the value is used to allocate memory, there are crashes that indicate that apparently more than the largest possible allocable memory is mentioned. So why esp_get_free_heap_size()?

Any idea what the memory secrets are?

ESP_igrr
Posts: 2072
Joined: Tue Dec 01, 2015 8:37 am

Re: Compiler does not report space taken by big char arrays??

Postby ESP_igrr » Sun Sep 09, 2018 2:47 pm

Please see esp_get_free_heap_size and esp_get_minimum_free_heap_size. Former returns current free heap size, which is the sum of sizes of every free block in heap. The latter returns the minimum free heap size that was ever seen during program execution.

Because blocks are not contiguous, the maximum size you will be able to allocate from the heap will always be smaller than the value returned by esp_get_free_heap_size. To get the size of the largest available block of heap memory, you can call heap_caps_get_largest_free_block.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Compiler does not report space taken by big char arrays??

Postby ESP_Angus » Mon Sep 10, 2018 1:35 am

Hi artkeller,

In addition to Ivan's answer, you may find this summary of heap information functions useful:
https://docs.espressif.com/projects/esp ... nformation

And there's an explanation of "heap capabilities" here: https://docs.espressif.com/projects/esp ... alloc.html

I deleted the duplicate copy of this question in another thread. Please don't post duplicates.

petersanch
Posts: 15
Joined: Mon Sep 10, 2018 8:58 am

Re: Compiler does not report space taken by big char arrays??

Postby petersanch » Tue Sep 11, 2018 9:30 am

I have the same problem with large arrays and heap limitations.
heap_caps_get_largest_free_block(8) returns 113K bytes and ESP.getFreeHeap() returns 285K bytes.
ESP_igrr wrote: Because blocks are not contiguous, the maximum size you will be able to allocate from the heap will always be smaller than the value returned by esp_get_free_heap_size. To get the size of the largest available block of heap memory, you can call heap_caps_get_largest_free_block.
If the largest contiguous heap block is 113KB does this mean making 2 arrays of 60KB with malloc is possible? I tried splitting a 115200 byte array into 2 half size arrays in my program but I get the same exception as having 1 large array .

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Compiler does not report space taken by big char arrays??

Postby ESP_Angus » Tue Sep 11, 2018 11:44 pm

I've split these posts into a new thread because they're not really related to the original posts (which were about static memory usage).
petersanch wrote: If the largest contiguous heap block is 113KB does this mean making 2 arrays of 60KB with malloc is possible? I tried splitting a 115200 byte array into 2 half size arrays in my program but I get the same exception as having 1 large array .
Maybe. There isn't enough information to know this for certain. If the largest contiguous free heap block is 113KB then you can definitely allocate one 60KB block, but this single block is not large enough for two 60KB to fit in it (60+60=120, 120>113). The second 60KB may have to fit in the second largest free block, and you don't know how big the second largest free block is. So you'd need to check the largest contiguous heap block a second time (after the first allocation) to make sure you have enough room.

The simpler way to do this is to just call malloc(60*1024) twice and then check if either pointer is NULL. If either pointer is NULL, allocation failed as there wasn't a large enough free block.

Who is online

Users browsing this forum: No registered users and 66 guests