SIMPLELINK-CC13X2-26X2-SDK: sdk_5_20_00_52 Memory overflow

mingwei yang

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

After I use the official demo: ZR_LIGHT and configure Touchlink->TARGET（BDB_TL_TARGET）, it has a memory leak.

After the ZR device joins the centralized network, the coordinator continues to be powered off for 3 minutes, and then powered on for 30 seconds. After a period of time (1 hour), the ZR device's memory is full.

uint32_t tmpArr[10] = {0};
OsalPort_heapMgrGetMetrics(&tmpArr[0], &tmpArr[1], &tmpArr[2], &tmpArr[3],&tmpArr[4], &tmpArr[5]);

When the ZR device first entered the network: Bmax=110,Cnt=100,F=18,A=2368,MMax=3332,U=3564
after an hour: Bmax=168,Cnt=159,F=30,A=5188,MMax=5812,U=6140

After the memory is full, the device cannot operate normally.
But if the ZR project does not configure Touchlink->TARGET（BDB_TL_TARGET）, there will be no such problem.

over 2 years ago

0 mingwei yang over 2 years ago

Prodigy 110 points

I found that if the coordinator continues to Mgmt_Permit_Join_req, the ZR device will leak memory...

0 mingwei yang over 2 years ago

Prodigy 110 points

The cause of the problem has been found:

the task_id was judged when the TOUCHLINK task（touchLinkTarget_event_loop） was executed. There is no problem with this operation itself, but when stackTaskFxn calls this task, the task_id is written to 0.

This problem is more serious, and it exists in the 4_40 and 5_20 versions of the SDK.

0 Ryan Brown1 over 2 years ago in reply to mingwei yang

TI__Guru**** 202856 points

Hi mingwei,

Thank you for alerting me of this issue, it appears similar to observations made in https://e2e.ti.com/f/1/t/1053970 and thus I am working with the Software Development Team to find the root problem and recommend a solution or workaround.

Regards,
Ryan

0 mingwei yang over 2 years ago in reply to Ryan Brown1

Prodigy 110 points

I have fixed the problem and tested it normally.

I did not find this problem in the SDK of version 4_40 because the maximum memory usage is different.

sdk4_40： Bmax=926, Cnt=917, F=28, A=44636, MMax=45040, U=45456

sdk5_20： Bmax=168, Cnt=159, F=30, A=5188, MMax=5812, U=6140

I would like to know how to adjust the maximum peak value of heap memory, thank you~

0 Ryan Brown1 over 2 years ago in reply to mingwei yang

TI__Guru**** 202856 points

The heap size is no longer dynamically allocated due to a broadening portfolio of SimpleLink devices with different RAM sizes. Thus HEAPMGR_SIZE variable can be changed in app.cfg, this is further described in the Z-Stack User's Guide. However, this will only further delay the time it takes for device failure due to a memory leak. Have you implemented any other project modification to resolve the issue for the SIMPLELINK-CC13X2-CC26X2-SDK v5.20?

Regards,
Ryan

+1 Ryan Brown1 over 2 years ago in reply to Ryan Brown1

TI__Guru**** 202856 points

Hi mingwei,

Just to close on this, the root cause of this issue was that the task IDs for the TL imitator/target devices were not being used to dequeue OSAL messages. This led to a leak of 60 bytes every time a ZDO Message Callback of type zdoIncomingMsg_t was triggered. Below are the official changes to Z-Stack which will be applied to the SIMPLELINK-CC13XX-CC26XX-SDK v5.40 once it releases.

From bdb_touchlink_initiator.c:

uint32_t touchLinkInitiator_event_loop( uint8_t task_id, uint32_t events )
{
  if(events & SYS_EVENT_MSG)
  {
    OsalPort_EventHdr *pMsg;
    ZStatus_t stat = ZFailure;

    //if((pMsg = (OsalPort_EventHdr *)OsalPort_msgReceive(task_id)) != NULL)  //LINE REMOVED
    (void)task_id;  // Intentionally unreferenced parameter  //LINE ADDED

    if((pMsg = (OsalPort_EventHdr *)OsalPort_msgReceive(touchLinkInitiator_TaskID)) != NULL) //LINE ADDED
    {
      switch(pMsg->event)
//...

From bdb_touchlink_target.c:

uint32_t touchLinkTarget_event_loop( uint8_t task_id, uint32_t events )
{

  (void)task_id;  // Intentionally unreferenced parameter  //LINE ADDED

  if ( events & SYS_EVENT_MSG )
  {
    OsalPort_EventHdr *pMsg;

    if ( (pMsg = (OsalPort_EventHdr *)OsalPort_msgReceive( task_id )) != NULL )  //LINE REMOVED
    if ( (pMsg = (OsalPort_EventHdr *)OsalPort_msgReceive( touchLinkTarget_TaskID )) != NULL )  //LINE ADDED

Regards,
Ryan

0 Shuyang Zhong over 2 years ago in reply to Ryan Brown1

TI__Expert 3925 points

Hi Ryan,

Could you elaborate on the purpose of the intentionally unreferenced parameter please? Why do we need it?

(void)task_id; // Intentionally unreferenced parameter //LINE ADDED

Thanks.

Best regards,

Shuyang

0 Ryan Brown1 over 2 years ago in reply to Shuyang Zhong

TI__Guru**** 202856 points

Hi Shuyang,

It isn't necessary except for internal static analysis checks. Other Z-Stack task loop functions have similar unused parameters that otherwise have no functionality or purpose.

Regards,
Ryan

0 Shuyang Zhong over 2 years ago in reply to Ryan Brown1

TI__Expert 3925 points

Thanks for clarifying.

BR,

Shuyang

0 Aries Lord over 2 years ago

Genius 5280 points

In CC2652's zstack, task_id in every "event_loop" is invalid.

Zigbee & Thread

Zigbee & Thread forum

SIMPLELINK-CC13X2-26X2-SDK: sdk_5_20_00_52 Memory overflow