[ESP32S3] v5.1 consuming up to 30kB of internal RAM more than same example in v4.4 (IDFGH-12234) #13285
Comments
github-actions
bot
changed the title
|
This is just a tip to narrow down the source of the difference: You can use esp-idf-size (https://github.com/espressif/esp-idf-size) (already available in ESP-IDF environments) and with the python -m esp_idf_size.ng build/blink_v5.1.map --diff /tmp/blink_v4.4.mapYou can add arguments to get more details. See |
hello @dobairoland , we are talking about internal RAM usage, not file size. I'll update the name to reflect that |
KonssnoK
changed the title
espressif-bot
added
Status: In Progress
|
After quite some debugging I think I have found the difference between While in #define portFREERTOS_HEAP_CAPS ( MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT )
/*-----------------------------------------------------------*/
void * pvPortMalloc( size_t xWantedSize )
{
void * pvReturn = NULL;
/* All dynamic allocation done by FreeRTOS goes through this function. If
* users need to allocate FreeRTOS objects into external RAM, they should
* use the "static" equivalents of FreeRTOS API to create FreeRTOS objects
* (e.g., queues). */
pvReturn = heap_caps_malloc( xWantedSize, portFREERTOS_HEAP_CAPS );
return pvReturn;
}which forces the allocations to happen on the internal RAM. By placing logs in - return (void *)xQueueCreate(queue_len, item_size);
+ return (void *)xQueueCreateWithCaps(queue_len, item_size, MALLOC_CAP_SPIRAM);I tried to apply a similar modification to I assume this is related to the explanation in the code, but I am not sure I 100% understand the comment /*
* All dynamic allocation done by FreeRTOS should be placed in internal 8-bit
* accessible RAM (i.e., using the MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT flags).
* This is due to the fact that FreeRTOS objects (e.g., task stacks, TCBs,
* queues etc) must be accessible even if the cache is disabled. Therefore, the
* heap that is made available to FreeRTOS for dynamic allocation is a subset of
* the ESP-IDF heap (where all MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT memory is
* made available to FreeRTOS for dynamic allocation).
* */ |
|
what is not clear is why we can write to spi_flash in v4.4 while having tasks allocated in the spi_ram and we cannot do the same in 5.1. For sure there are no hardware limitations, or we would not have been abled in the first place to put our RTOS stuff on SPI_RAM. |
|
@dobairoland @Dazza0 PTAL |
|
@KonssnoK Please take a look at the FreeRTOS section of the IDF v5.1 migration guide. All dynamic memory allocated by FreeRTOS will not default to be being internal memory. This change was intentional in to increase run time safety. For library/user code that need to move memory allocations to external memory. This now needs to be done explicitly (see the |
Hello @Dazza0 , could you please be more specific on what you mean with "increase runtime safety" ? Does this mean that 4.4 is not runtime safe and the change needs to be backported? What is the criticality? Thanks. |
|
@KonssnoK Previously, FreeRTOS would simply use However, we encountered numerous users who ran into a |
|
thanks @Dazza0 . Am I correct saying that the only way to have such a scenario of Because from what I remember on flash operations you always have at least
|
Yes, that's correct
Interrupts created with the |
|
our main doubt is about some espressif closed source code (mesh) that we use extensively. This means that to recover space we'll have to change the esp_adapter file to use @zhangyanjiaoesp could you make an evaluation of:
If 1 is true (used) it means that we should not move mesh queues to spi ram (even if we currently do). If 1 is false (not used) it means we can use the mesh library on the same core of spi flash operations independently from 2, which somehow invalidates #11023 If 1 is false and 2 false (not used) it means we can also move mesh to the second core. @Dazza0 please confirm. Thanks |
|
|
@zhangyanjiaoesp thanks! |
espressif-bot
added
Status: Reviewing
|
Hi, I'm facing the same issue: my project in v5.1 is consuming internal RAM more than same code in v4.4 and always the compilation return "out of region..." |
|
@romocitto88 Please take a look at #13285 (comment) and #13285 (comment) |
|
I read the comments and I changed the functions indicated with "...WithCaps() with MALLOC_CAP_SPIRAM" but nothing is changed. I missed something? |
espressif-bot
added
Status: Done
|
@romocitto88 Could you post a copy of the error log you are encountering? |
|
@Dazza0
|
|
@romocitto88 You are running our of static memory (IRAM to be specific). It's completely unrelated to this issue. Please refer to this guide regarding reducing binary size. |
|
@romocitto88 Yes, more functions have been placed into IRAM between v4.4.2 and v5.1.2. Again, please refer to the reducing binary size guide to determine what is using up your IRAM and what can be moved to flash to reduce IRAM usage. |
Answers checklist.
General issue report
this was tested on esp32s3 devkit-C
using
https://github.com/espressif/esp-idf/tree/master/examples/mesh/ip_internal_network
Changes on v4.4
sdkconfig
Log on v4.4
Changes in 5.1
esp-idf release/v5.1
sdkconfig
Log
See last line of log:
v4.4: 245207 bytes free
v5.1: 214471 bytes free
-> delta ~ 30.7k
FYI @zhangyanjiaoesp
The text was updated successfully, but these errors were encountered: