CC2652R7: malloc memory allocation fails || Heap is getting full

Divya Barathi

Part Number: CC2652R7
Other Parts Discussed in Thread: SYSCONFIG,

I am trying to allocate 23kB memory for two buffers in our thread using malloc in runtime

We are reallocating the same 23kB for two buffers once after freeing the previous memory

For getting the heap size below was included in our code,

ICall_heapStats_t stats;
ICall_getHeapStats(&stats);
gcam_printf(LOGD,"Heap stats: Total Heap Size: %lu, Largest Free Size: %lu " \
"Total Free Size: %lu\r\n",
stats.totalSize,
stats.largestFreeSize,
stats.totalFreeSize);

Below are the logs of allocating and freeing . On the 6th iteration We are not able to allocate the memory and RS_ENOMEM error is occures

Heap stats: Total Heap Size: 93808, Largest Free Size: 67040 Total Free Size: 68996
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 43524 Total Free Size: 45480
handle @20005578 size 23504 size_handle 4

handle_deinit after free @00000000
handle_deinit after free @00000000
Heap stats: Total Heap Size: 93808, Largest Free Size: 67040 Total Free Size: 69404
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 43524 Total Free Size: 45888
handle @20005578 size 23504 size_handle 4

handle_deinit after free @00000000
handle_deinit after free @00000000
Heap stats: Total Heap Size: 93808, Largest Free Size: 67040 Total Free Size: 70092
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 43524 Total Free Size: 46576
handle @20005578 size 23504 size_handle 4

handle_deinit after free @00000000
handle_deinit after free @00000000
Heap stats: Total Heap Size: 93808, Largest Free Size: 67040 Total Free Size: 106800
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 43524 Total Free Size: 83284
handle @20005578 size 23504 size_handle 4

handle_deinit after free @00000000
handle_deinit after free @00000000
Heap stats: Total Heap Size: 93808, Largest Free Size: 47024 Total Free Size: 143508
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 23508 Total Free Size: 119992
handle @20005578 size 23504 size_handle 4

handle_deinit after free @00000000
handle_deinit after free @00000000
Heap stats: Total Heap Size: 93808, Largest Free Size: 46872 Total Free Size: 160480
handle @2000557c size 23504 size_handle 4
Heap stats: Total Heap Size: 93808, Largest Free Size: 23356 Total Free Size: 136964
handle @20005578 size 23504 size_handle 4

RS_ENOMEM is occured,

Here we are freeing and only trying then why still heap memory is not getting released?

free(handle);
handle = NULL;

Can you please help here and let us know what can fix this issue?

over 1 year ago

0 Clément over 1 year ago

TI__Guru** 101460 points

Hi,

Thank you for reaching out.

I have a few questions to well understand your case:

can you specify which example and SDK versions are being used?
can you help understanding why dynamic allocation is used for such large buffers instead of static allocation? I am especially curious because you mentioned the same size of buffer is being repeatedly assigned.
can you specify the API function used to allocate and free the memory? I would have expected you use ICall_malloc() and ICall_free() but it does not seem to be the case.

Best regards,

0 Divya Barathi over 1 year ago in reply to Clément

Prodigy 130 points

SDK verison : simplelink_cc13xx_cc26xx_sdk_7_10_01_24

1. Earlier I used //*handle = malloc(1 * 23k);

and as per your command i changed as below,

*handle = ICall_malloc(23k);

But still I face an issue

2. We are using this because of the our requirement and sequence

0 Clément over 1 year ago in reply to Divya Barathi

TI__Guru** 101460 points

Hi,

Thank you for telling me.

To me the issue on your first test was the fact the Total Free Size keeps growing - even over the Total Heap Size value. When using ICall_malloc, are you still facing the same issue?
If yes, could you please use the ROV to check if it provides the same values? (use the "heap" section of the ROV, see here for details on the ROV https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.10.00.98/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html?highlight=icall_heapstats_t#ti-rtos-object-viewer)

The issue causing the allocation to fail is actually kind of expected as the Largest Free Size is smaller than the space you attempt to allocate. We can discuss ways to address this last element, but I would prefer we address the other issue first.

Best regards,

0 Divya Barathi over 1 year ago in reply to Clément

Prodigy 130 points

yeah . We are facing the issue even with the function which you have suggested

Are you asking the below setting while the issue is occuring?

0 Divya Barathi over 1 year ago in reply to Divya Barathi

Prodigy 130 points

In that case the context value is not changing.

Am I following the correct thing which you are expecting?

0 Divya Barathi over 1 year ago in reply to Divya Barathi

Prodigy 130 points

Heap stats: Total Heap Size: 93808, Largest Free Size: 23044 Total Free Size: 200088

The above is the last print before the heap crash

Can you please check and let us know

0 Clément over 1 year ago in reply to Divya Barathi

TI__Guru** 101460 points

Hi,

May I ask if HeapMem is enabled? It does not seem to be the case. I would like to suggest you to enable it so you can have more debug information.

Here are the steps:

1- Open SysConfig > TI RTOS > BIOS > Default Heap Settings and set "Default Memory Heap Type" to "HeapMem". Set HeapSize to 0x16E00 (~93808).

2- Build and flash the code

3- You should have a new view in ROV called "HeapMem"

4- Run your program again and monitor the values in "HeapMem" both in the "Detailled" and "FreeList" views

Here is what it should look like:

Best regards,

0 Divya Barathi over 1 year ago in reply to Clément

Prodigy 130 points

I followed the steps which you have provided but I am facing below issue

"../cc13x2x7_cc26x2x7_app_tirtos7.cmd", line 286: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. run placement with alignment fails for section ".stack" size 0x1fb8. Available memory ranges:
SRAM size: 0x23021 unused: 0x29c9 max hole: 0x1f28
error #10010: errors encountered during linking; "pnrj_gcam_CC2652R7.out" not built
tiarmclang: error: tiarmlnk command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [pnrj_gcam_CC2652R7.out] Error 1
gmake: *** [all] Error 2
makefile:221: recipe for target 'all' failed

**** Build Finished ****

But one more inference which I analysed is when I allocated some less memory the build was succeeded but Our board was not booting properly.

When we enable this HeapMem does anything else need to be taken care?

0 Clément over 1 year ago in reply to Divya Barathi

TI__Guru** 101460 points

Hi,

Thank you for telling me - you were right to reduce the amount of memory allocated for the heap to make the program link properly. However, I am surprised the program was not working afterwards. The closest I got from this problem, is actually the program was entering an error loop after reflashing the board with the updated image. Closing the debug session and power cycling the device "fixed" the issue.
To continue the analysis, I would suggest referring the following - if not already done - https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.40.00.77/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-common-heap-issues

To be honest, I am pretty sure what is going on here, and I would like to offer my analysis even if I do not have all the elements to prove it.
My theory is that you are suffering memory fragmentation. This issue is pretty likely to occur in systems where memory allocation with various sizes occur. In your case, given the size of the allocation, the issue causes pretty quickly some side effects.
There is quite some literature out there talking about this problem and I can further elaborate if you are interested.

A common way to fix the issue is to use static allocation for recurring same-sized allocations. I guess I suggested this in a previous message, but I understand it may not be a solution for you - let me know here too if you want me to develop.

Other elements you may want to consider are:

disable the large (23 kB) allocation to ensure no other part of the program is causing a memory leak. Such memory leak could speed up the memory fragmentation.
try allocating and freeing the 23-kB table at the same time (and several times in a row). If the memory fragmentation still occurs, then there might be other elements at play we have not considered so far

I hope this will help,

Best regards,

0 Divya Barathi over 1 year ago in reply to Clément

Prodigy 130 points

Please find the results as per your suggestion,

disable the large (23 kB) allocation to ensure no other part of the program is causing a memory leak. Such memory leak could speed up the memory fragmentation. -> There is no problem with this
try allocating and freeing the 23-kB table at the same time (and several times in a row). If the memory fragmentation still occurs, then there might be other elements at play we have not considered so far -> Even I have checked this and there is no issue. I tried in a for loop for 50 times and there was no issue on that. Please find the logs below for this case

Heap stats Before allocating: Total Heap Size: 93808, Largest Free Size: 70376 Total Free Size: 70424

1 . Addr 0xA84A28870BC1 Reg Sts 1
Heap stats After allocating: Total Heap Size: 93808, Largest Free Size: 70376 Total Free Size: 70424

Initialized
Heap stats After Freeing: Total Heap Size: 93808, Largest Free Size: 70376 Total Free Size: 70424

ID Addr: 0xCC037BDD0B4F
Heap stats Before allocating: Total Heap Size: 93808, Largest Free Size: 45616 Total Free Size: 68416

RP Addr: 0x4981996939BD
Heap stats After allocating: Total Heap Size: 93808, Largest Free Size: 45616 Total Free Size: 68416

Adv Set 0 Enabled
Heap stats After Freeing: Total Heap Size: 93808, Largest Free Size: 45616 Total Free Size: 68416

Adv Set 1 Enabled
Heap stats Before allocating: Total Heap Size: 93808, Largest Free Size: 45664 Total Free Size: 68460

Heap stats After allocating: Total Heap Size: 93808, Largest Free Size: 45664 Total Free Size: 68460

Heap stats After Freeing: Total Heap Size: 93808, Largest Free Size: 45664 Total Free Size: 68460