• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1540 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Handling Easylink Error Conditions

Saycoda
Expert 1580 points
Other Parts Discussed in Thread: CC1310

PART I

I'd like to know the best way of handling the following error conditions that could arise in a) a receive callback and b) changing the state of the CC1310 (going in and out of receive mode). Below is an enumerated list of possible returned statuses from a receive callback. I noticed that if encountered a "EasyLink_Status_Rx_Error" and did not handle it, the link would hang and the devices (receiver & transmitter) would need to be reset. I improved the performance by adding an Easylink_abort(), then and Easylink_receiveAsync() when that condition occurred. Although it improved the performance I still get hang ups.

So again, what is the best way of handling the following error conditions that could arise:

EasyLink_Status_Config_Error

EasyLink_Status_Param_Error

EasyLink_Status_Mem_Error 

EasyLink_Status_Cmd_Error

EasyLink_Status_Tx_Error

EasyLink_Status_Rx_Error

EasyLink_Status_Rx_Timeout

EasyLink_Status_Rx_Buffer_Error

EasyLink_Status_Busy_Error

EasyLink_Status_Aborted

PART II

ALSO WHAT IS THE BEST TECHNIQUE IN THE EVENT THAT THESE CHANGE OF STATE CONDITIONS FAIL?

if(EasyLink_abort() != EasyLink_Status_Success)

{

}     

if(EasyLink_receiveAsync(rxDoneCallback, 0) != EasyLink_Status_Success)

{

}

 

  • 0
    TI__Genius 9180 points

    Hi,

        In our examples we used an System_abort to highlight to any one developing their application from the examples that something went wrong. Many of the errors should should not happen in an application that has been tested/debugged and working properly.

    I would be interested to know the use case where an EasyLink_Status_Rx_Error will cause a lock up.

    An explanation of the return codes is:

    EasyLink_Status_Config_Error - Coding issue, API's used before init. Should not happen in working code

    EasyLink_Status_Param_Error - Coding issue. Should not happen in working code

    EasyLink_Status_Mem_Error - Semaphore could not be allocated from heap during EasyLink_init. Increase heap size. 

    EasyLink_Status_Cmd_Error - Coding issue. There was an error returned from RF Core command, check the smartrf_settings.c/h if you are using the EasyLink_Phy_Custom. If the issue is not in the rf settings report to TI on E2E, this could be a bug with the EasyLink Layer or RF Driver.  

    EasyLink_Status_Tx_Error - Tx could not complete as expected. Should not happen unless there is a bug in the Tx RF command (check rf settings if using EasyLink_Phy_Custom). Resubmit the command (if EasyLink_transmitAsync returned this error code call EasyLink_abort first).  

    EasyLink_Status_Rx_Error - The Rx command did not complete successfully, but did not end due to timeout or abort. This is expected to happen during run time for things like Rx CRC errors due to interference. Depending on application you may want to return to Rx (iffEasyLink_receiveAsync returned this error code call EasyLink_abort first).

    EasyLink_Status_Rx_Timeout - The Rx timed out due to EasyLink_getCtrl(EasyLink_Ctrl_AsyncRx_TimeOut, x) in case of EasyLink_receiveAsync. Or rxPacket->rxTimeout in case of EasyLink_receive.

    EasyLink_Status_Rx_Buffer_Error - Rx data was bigger than the Rx Buffer. This should only happen when using EasyLink_Phy_Custom mode if the maxPktLen is set incorrectly.

    EasyLink_Status_Busy_Error - This is more than likely a Coding issue. An Async API is running and using the EasyLink resource. Other API's will return EasyLink_Status_Busy_Error during this time. Be sure to understand why this has happened, but the likely action is to call EasyLink_abort and recall the API that failed.  

    EasyLink_Status_Aborted - This will be returned in the Async callback (Tx/Rx) if an abort is issued during command execution.

    Saycoda said:

    ALSO WHAT IS THE BEST TECHNIQUE IN THE EVENT THAT THESE CHANGE OF STATE CONDITIONS FAIL?

    if(EasyLink_abort() != EasyLink_Status_Success)

    {

    }  

    Likely cause is that the command you are trying to abort has already completed. So you can ignore.

    Saycoda said:

    if(EasyLink_receiveAsync(rxDoneCallback, 0) != EasyLink_Status_Success)

    {

    }

    EasyLink_Status_Config_Error: Make sure you have call EasyLink_init

    EasyLink_Status_Busy_Error: Call EasyLink_abort and retry

    EasyLink_Status_Rx_Error: We should probably make this a EasyLink_Status_Cmd_Error, the only cause for EasyLink_receiveAsync returning EasyLink_Status_Rx_Error is that there was an issue with the command. Call EasyLink_abort and retry.

    Regards, TC.