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.

CC2530 TIMAC Stop running

Other Parts Discussed in Thread: TIMAC, CC2530

In one of my applications, I use TIMAC with CC2530. My application works very well for ten to 14 times. but if i continue running this application for 15th times or more,the TIMAC will stop.  the program will stop when it wants to execute

 pDataReq = MAC_McpsDataAlloc(msduLength, Security.securityLevel, Security.keyIdMode);

it is a function in MAC layer.

do you have any idea for which reason TIMAC stops

Thank you

  • Hi,

    The reason why your application stops might be because you have a memory leak. Are you freeing or deallocating the data after you allocate it? 

    Hector

  • After the operation I do deallocating the data. so I free the memory but still the program stops running

    Bijan

  • As Hector indicated this is likely an issue with allocating the memory inside the MAC, as it fails consistently after 15 runs.  Can you try to increase the heap size in OnBoard.h:

    // Internal (MCU) heap size
    #if !defined( INT_HEAP_LEN )
      #define INT_HEAP_LEN  2048  // 1.00K
    #endif

    Try 4096 if available. If the theory is correct the program will run for longer.

    Also please check the msduLength by setting a break point before the MAC_McpsDataAlloc. We do not have any any details about your code, so I am not sure if this could be set incorrectly to a very high value.

    Also please clarify:

    Bijan said:
    program stops running

    Do you mean that it never returns after calling MAC_McpsDataAlloc? Does it Assert? Can you pause the execution and check the stack trace (from menu bar select View->Call Stack). What is the call stack?

    Regards, TC.

  • > When we use a heap size of 2600, the compiler can't compile and gives us error  Error[e16]

    but with heap size of 2500, the compiler works. and we can do the test for 18 tries instead of 15. that is 3 times better. so the problem is coming from the memory.

    > we checked the 'msduLength'. it is less than 116.

    > The return of the function 'MAC_McpsDataAlloc' is zero (null)

    > For Call Stack  we got the below image

    > we think that the 'MAC_McpsDataAlloc' does not work very well because when we use this function there is no memory allocate. and since we have not enough memory the system stops running

    What do you think

    Thanks

  • the image is

  • This is typical behavior of a memory leak, which means you are allocating memory from the heap and not freeing it, eventually the heap runs out and you can allocate no more memory. Increasing the heap allows the program to run longer before the heap runs out.

    Bijan said:
    > we think that the 'MAC_McpsDataAlloc' does not work very well because when we use this function there is no memory allocate. and since we have not enough memory the system stops running

    MAC_McpsDataAlloc is working as expected, when the heap does not have any memory left to allocate it returns a NULL pointer. It is good practice to check a pointer has been allocated memory before trying to us it.

    You are calling MAC_McpsDataAlloc in your application to allocate a MAC buffer from the heap. This buffer will be free'ed when pasted to MAC_McpsDataReq, if you do not call MAC_McpsDataReq for some reason then you will need manually to free the buffer allocated by MAC_McpsDataAlloc:

      macMcpsDataReq_t  *pData;
    
      if ((pData = MAC_McpsDataAlloc(dataLength, msa_securityLevel, msa_keyIdMode)) != NULL)
      {          
    
        //Some code that for some reason can decide not to call MAC_McpsDataReq to send the data...
        
        if(pData != NULL)
        {
          osal_mem_free(pData);
        }
    ...    
    

    If this is not the case and you are always calling MAC_McpsDataReq after MAC_McpsDataAlloc  then maybe your application is calling osal_mem_alloc and not freeing the buffer with osal_mem_free.

    Regards, TC.

  • FYI, please refer the "802.15.4 MAC API .pdf" supplied in the TI MAC release (in documents folder).Section 4.3.3 describes the MAC_McpsDataAlloc and explains that if MAC_McpsDataReq() is not call then you must manually deallocate the buffer.

    I apologies for an error in above code snip, you should use mac_msg_deallocate to dealocate the buffer allocated by MAC_McpsDataAlloc, not osal_mem_free:

      macMcpsDataReq_t  *pData;
    
      if ((pData = MAC_McpsDataAlloc(dataLength, msa_securityLevel, msa_keyIdMode)) != NULL)
      {          
    
        //Some code that for some reason can decide not to call MAC_McpsDataReq to send the data...
        
        if(pData != NULL)
        {
          mac_msg_deallocate(&pData);
        }
    ... 

    Also note the messages from the MAC need to be deallocated in the application:

    uint16 MSA_ProcessEvent(uint8 taskId, uint16 events)
    {
      uint8* pMsg;
      macCbackEvent_t* pData;
    
    #ifdef FEATURE_MAC_SECURITY
      uint16       panID;
      uint16       panCoordShort;
      sAddrExt_t   panCoordExtAddr;
    #endif /* FEATURE_MAC_SECURITY */
    
      static uint8 index;
      static uint8 sequence;
    
      if (events & SYS_EVENT_MSG)
      {
        while ((pMsg = osal_msg_receive(MSA_TaskId)) != NULL)
        {
    ...
    
          /* Deallocate */
          mac_msg_deallocate((uint8 **)&pMsg);
        }
    ...

    Regards, TC.

    Regards, TC.