This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652P: ICall_malloc stuck in a neverending loop

Part Number: CC2652P


Hello,

I'm using simplelink_cc13x2_26x2_sdk_5_20_00_52. My application periodically enqueues some data to the BLE application queue, to do so I use Util_enqueueMsg -> ICall_malloc -> ICall_heapMalloc.

From time to time the execution enters in a neverending loop inside ICall_heapMalloc, HEAPMGR_MALLOC in rtos_heaposal.h, do {...} while(1); 

do
{
if (tmp & HEAPMGR_IN_USE)     
{
tmp ^= HEAPMGR_IN_USE;           always enter this block
coal = 0;
}
else
{
if (coal != 0)
{
#ifdef HEAPMGR_METRICS
HEAPMGR_BLKCNT--;
HEAPMGR_BLKFREE--;
#endif // HEAPMGR_METRICS

*prev += *hdr;

if (*prev >= size)
{
hdr = prev;
tmp = *hdr;
break;
}
}
else
{
if (tmp >= size)
{
break;
}

coal = 1;
prev = hdr;
}
}

hdr = (heapmgrHdr_t *)((hmU8_t *)hdr + tmp);

tmp = *hdr;
if (tmp == 0)
{
hdr = NULL;
break;    never enters here and loops again forever
}


}
while (1);

By the way I had other problems with Icall malloc in the past (there are other posts from me about that). Is it mandatory ? cannot I use standard malloc ?

Thanks

Fabio

  • Hi Fabio,

    Thank you for reaching out.

    I am afraid ICall malloc is the only way to allocate memory in a ICall enable (i.e. Bluetooth LE aware) task.

    With regards to your issue, it looks like you run out of free memory. It may be because the device's memory is too small, not optimally shared between the stacks or you have a memory leak. I would recommend to leverage the ROV to assess this (see the debugging guide).

    I hope this will help,

    Best regards,

  • Hi,

    Sorry for a late respond, From what you described I think in your app code you must have changed HEAPMGR_IN_USE somewhere. Please see into that 

  • Hi,

    this is the code I have (never touched it)

    #define HEAPMGR_IN_USE   0x80000000u

    About Clement's answer, if I ran out of memory I would expect ICall_malloc returns NULL, not looping forever.

    BR

    Fabio

  • Hi Fabio,

    I made a mistake, the behavior you are seeing is actually not triggered by the device running out of memory. As you have mentioned in such case a NULL pointer should rather be returned.

    Could you please verify if a specific allocation size is much likely to trigger the issue?

    Best regards,