MC1312x SRB stops receiving data

[wareagle]

    I'm working on a simple two-node network (1 SRB, 1 NCB), and today we came close to a working solution but ran into a problem.  After successfully receiving approximately 5 messages from the NCB, the SRB will no longer receive or transmit messages.  The problem consistenly occurs after the receiving between 4 and 6 messages.  Our codebase is Beestack and our solution is a lightly modified version of the Beestack Generic App.  Can anyone suggest possible problems?  It seems like the device is running out of message buffers, but we call MSG_Free() at the end of the data indication.  Resetting the device allows it to receive messages again, but of course it stops receiving (and will no longer transmit) after the 5th message. The code for BeeAppDataIndication() is shown below.

Code:

void BeeAppDataIndication(void){  apsdeToAfMessage_t *pMsg;  zbApsdeDataIndication_t *pIndication;  uint8_t myAuthCode;  while(MSG_Pending(&gAppDataIndicationQueue))  {    /* Get a message from a queue */    pMsg = MSG_DeQueue( &gAppDataIndicationQueue );    /* ask ZCL to handle the frame */    pIndication = &(pMsg->msgData.dataIndication);    /*      Note: if multiple endpoints are supported by this app, insert       endpoint filtering here...      This app assumes only 1 active endpoint. APS layer has already      filtered by endpoint and profile.      Note: all multi-byte over-the-air fields are little endian.      That is 0x1101 would come in byte order 0x01 0x11.    */    /* is the cluster for accelerometer— */    if(pIndication->aClusterId[1] != appDataCluster[1]) {      MSG_Free(pMsg); /* no, free it and we're done */      continue;    }    /* handle the command */        if(pIndication->aClusterId[0] == appDataCluster[0])     {            //turn on LED2      LED_SetLed(LED2, gLedOn_c);          // create packet and send to computer terminal for testing purposes      (void) UartX_Transmit(pIndication->pAsdu, pIndication->asduLength, NULL);                //myAuthCode = *pIndication->pAsdu;      FLib_MemCpy(&myAuthCode, pIndication->pAsdu, pIndication->asduLength);                  if (myAuthCode == 'G')       grantAccess();            else if (myAuthCode == 'D')      denyAccess();           }    /* Free memory allocated by data indication */    MSG_Free(pMsg);  }}

 

Thanks


Message Edited by wareagle on 2008-03-09 03:41 AM

[wareagle]

I have confirmed that when this problem occurs, the device has run out of memory.  I confirmed this by reading the returned code from the call of AF_DataRequest().  When things are working fine, this returns 0x00.  When the problem occurs, attempting to transmit from the device returns code 0x02, which, according to comments in the code, signifies the device is out of memory.  What needs to be done besides a MSG_Free() when data comes in in order to free memory?  Or, am I calling MSG_Free() incorrectly? Thanks.

[Mads]

Hi wareagle,

First of all I would recommend that you try build the Custome application that the Beestack Application developers user's guide describes step by step. When you got that working you can then add your own code.

Regarding to your code below. you do not have a "MSG_Free" problem, but you have the problem that the UART will access the data in the message after it got freed.

Try replacing your uart code with the following:

        if (UartTxFlag == FALSE) // only transmit if we are not already transmitting...
        {         
          UartTxFlag = TRUE;       
          FLib_MemCpy(UartTxBuffer, pIndication->pAsdu, pIndication->asduLength);           
            (void) UartX_Transmit(UartTxBuffer, pIndication->asduLength, UartTxCallBack);
        }  

And then add the following extra code :

uint8_t UartTxBuffer[20]; // NOTE must be the bigger than the maximum size telegram you can receive.
bool_t  UartTxFlag = FALSE;

static void UartTxCallBack(unsigned char const *pBuf) {
  (void) pBuf;
  UartTxFlag = FALSE; // Signal that Tx is done by setting tx flag to false
}            

Br,

Mads

[wareagle]

Thank you, Mads, for the advice.  We did figure out yesterday that that was the problem and we managed to fix it.  The code you posted looks like it could be a better implementation of the UART, though. Thanks again.