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.

CC1312R: ti15.4-Stack purges data from sensor tx queue

Part Number: CC1312R


Hello community

I am using the sensor and collector example with the non-beacon mode. If the connection is lost and the sensor enter orphan state, I want to clear the sensors tx queue to reduce the used memory space.

Therefor I use the function: ApiMac_status_t ApiMac_mcpsPurgeReq   (uint8_t msduHandle) with a callback function. But the data in the queue is not discarded.

The status in the callback function is: 0x18 ApiMac_status_unsupported -> /*! The operation is not supported in the current configuration */

So my question is, how can I purge the sensors tx queue and in which configuration?

 

**** some additional information: how I call the purge request *****

uint8_t msduHandle = deviceTxMsduHandle; 

   

    // decrement because it was already incremented when sending data

    if(msduHandle == 0) // counter is 0

    {

        msduHandle += MSDU_HANDLE_MAX;

    }

    else

    {

        msduHandle--;

    }

    /* Add the App specific bit */

    msduHandle |= APP_MARKER_MSDU_HANDLE;

 

    /* Add the sensor specific bit */

    msduHandle |= APP_SENSOR_MSDU_HANDLE;

 

    ApiMac_mcpsPurgeReq(msduHandle);

  • Hi Mischa,

    I don't think that I understand what you mean with reducing the used memory space in this context. Could you elaborate on that? Furthermore, where are you executing the code snippet that you provided?

    Also, just so that we understand each other, which SDK version are you using?

    BR,
    Andres

  • Hi Andres

    To transmit data the ApiMac_mcpsDataReq(&dataReq) function is called in sensor.c. Memory is allocated for this data frame by the MAC layer on the heap. If this is done several times, the data is queued until it was sent over radio. I want to clear this data queue (Free the allocated memory on the heap). I send you attached a screenshot of the TI 15.4-Stack API Guide where this data queue is mentioned.

     

    I tried different places to execute that code snipped. At the moment the code snipped is executed after the connection is lost and the orphan notification starts. In jdllc.c -> static void sendScanReq(ApiMac_scantype_t type)

     

    I use the SimpleLink CC12x2 26x2 SDK [4.10.0.78]

     

    Thank you for the help.

    KG

    Mischa von Rüti

  • Hi Mischa,

    Thanks. I think that I understand better now.

    I’m guessing that the code snippet that you provided was based on getMsduHandle() in sensor.c. Am I correct?

    What is the return status when you make a call to ApiMac_mcpsPurgeReq()? Does it return a success status or a no resources status?

    And can you share some code showing how the callback is being used?

     

    BR,
    Andres

  • Hi Andres

    Yes you are correct. The code snippet is based on getMsduHandle().

    The return status of ApiMac_mcpsPurgeReq() is always success. Independent of the msduHandle.

    But the status of the Callback isn’t success. It is 0x18 ApiMac_status_unsupported. The returned msduHandle_purge is always 0.

    static void purgeCnfCB(ApiMac_mcpsPurgeCnf_t *pPurgeCnf){

        uint32_t status_purge = pPurgeCnf->status;

        uint8_t msduHandle_purge = pPurgeCnf->msduHandle;

        …. Do some other code

    }

    The call back function is successfully called after the ApiMac_mcpsPurgeReq() is done.

    The description of ApiMac_status_unsupported is: /*! The operation is not supported in the current configuration */. Do you know which configuration this status is talking about?

    Thank you for the help.

    KG

    Mischa von Rüti

  • Hi Mischa,

    Since you are using the sensor/collector example as base point, would you mind sharing the project files, so that I can better reproduce what you are seeing. 

    BR,
    Andres

  • This thread is being handled internally, so I'll close it.

    BR,
    Andres