Task not launching even with plenty of free internal RAM

[jsam589]

I am running low on internal RAM for task stack usage, but I have around 10000 bytes available and want to launch a task with a stack of only 3072 bytes. However, the task creation fails and returns -1 (memory). Any idea why this would happen?

These are the results on which I base my numbers. At the time I try to call task create:
heap_caps_get_free_size(MALLOC_CAP_INTERNAL); 10428
heap_caps_get_largest_free_block(MALLOC_CAP_INTERNAL); 9808

Code: Select all

ESP_LOGI(TAG, "Launch special LED test");
if (pdPASS != xTaskCreate(led_test_task,"led v5 test", 3072, NULL, 6, &hTsk_LedTest) )
{
     ESP_LOGE(TAG, "LED test task creation failed");
}

Other info:
IDF is v4.0 release/stable
CONFIG_COMPILER_OPTIMIZATION_LEVEL_RELEASE=y
Project is using WiFI, NimBLE and esp-azure

Build-time size info (which does not include runtime-only heap) is:

Code: Select all

idf.py size-components
Scanning dependencies of target size-components
Total sizes:
 DRAM .data size:   21980 bytes
 DRAM .bss  size:   96464 bytes
Used static DRAM:  118444 bytes (   6136 available, 95.1% used)
Used static IRAM:  121095 bytes (   9977 available, 92.4% used)
      Flash code: 1051803 bytes
    Flash rodata:  304700 bytes
Total image size:~1499578 bytes (.bin may be padded larger)

[tvoneicken]

Memory fragmentation? The stack has to be contiguous and there may not be any contiguous chunk of that size.

[jsam589]

Memory fragmentation could explain my issue, but I thought that the call to

heap_caps_get_largest_free_block(MALLOC_CAP_INTERNAL);

tells me the largest contiguous block that can be obtained (9808) and this should be more than adequate.

[ESP_Angus]

Hi jsam,

Internal memory (MALLOC_CAP_INTERNAL) on ESP32 covers both DRAM (8-bit capable) and IRAM (32-bit capable only). Stacks have to be allocated as DRAM. It's possible you have enough free internal memory in total, but not enough is 8-bit capable.

You can substitute the calls as follows:

Code: Select all

heap_caps_get_free_size(MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT);
heap_caps_get_largest_free_block(MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT);

You're correct that a sufficiently high result from heap_caps_get_largest_free_block() should indicate allocation of this size (or very close to it) will succeed, so this covers the case of heap fragmentation.

[jsam589]

ESP_Angus, when I add the 8 BIT option as you suggest, it reports just 648 bytes available, so that makes sense.
Thanks for that very useful tip!