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.

CC1352P: Infinite loop within malloc with DMM with Zigbee and BLE

Part Number: CC1352P
Other Parts Discussed in Thread: SIMPLELINK-CC13X2-26X2-SDK, Z-STACK

Hello

I have a DMM project with Zigbee and BLE, but that in itself it not important.

The TI supplied task, with base function stackTaskFxn(), makes a call to OsalPort_msgAllocate(() which in turn calls OsalPort_malloc(), then OsalPort_heapMalloc(), which ends up in HEAPMGR_MALLOC(). Within this function, it appears as if the heap is already in use (HEAPMGR_IN_USE), then it loops until any other task exits the heap code.

This is fine, other than the fact this task is also the highest priority (TI defined), so no other task can pre-empted and exit...

Is this a known problem?

Kind regards

Gary Partis

  • Hello Gary,

    Which SIMPLELINK-CC13X2-26X2-SDK version are you referencing?  I'm looking at stackTaskFxn of zstackstartup.c in the v5.10 SDK's dmm_zr_light_remote_display_app example project for the LAUNCHXL-CC1352P-2 and not seeing a call to OsalPort_msgAllocate.  Otherwise the application only uses this function in zstackapi.c and z-stack uses it in multiple locations, but I do not see any issue regardless.  Can you further expand on how a problem could be present?

    Regards,
    Ryan

  • Hello Ryan

    The stackTaskFxn performs call backs based on raised events. The ROV call stack dump unfortunately doesn't indicate which call back function was called so will add some debug to establish this.

    The SDK is 4.30.0.54.

    Kind regards

    Gary

  • Hello again

    It appears to be the function ZMacEventLoop() which is being called from the zstackTasksArr table, used by stackTaskFxn().

    Again, there is no apparent direct call to OsalPort_msgAllocate(), but with aliasing of function names being rife, it may well be obfuscated.

    Kind regards

    Gary

  • Hey Gary,

    The HEAPMGR_IN_USE byte indicates that a particular heap block is in use, inside the header for a specific heap element.  It is not referring to the heap as a whole, just a particular block as it iterates through the heap looking for free space.  You can can add HEAPMGR_METRICS to further debug your application but there are no inherent issues if the stack is not freezing or locking up.

    Regards,
    Ryan

  • Hi

    The root cause of the issue(s) I was seeing were due to calling a BLE API (for notify/indicate) from a non-icall-BLE task.

    Kind regards

    Gary