• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 264 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1310: EasyLink_transmitCcaAsync call returns success, but operation stops calling txcb after several transmits

Nick Masur
Prodigy 205 points
Part Number: CC1310
Other Parts Discussed in Thread: SYSCONFIG

Hello.

I'm having trouble with an asynchronous transmit with clear channel assessment. It operates fine for several minutes, but eventually it fails to call the txcb. I've checked that the RF_CmdHandle returned by the RF_postCmd function is valid. The call to EasyLink_transmitCcaAsync returns EasyLink_Status_Success, but the txcb is never called after sending or failing to send the packet.

CCA parameters:

//! EASYLINK_CCA_BACKOFF_TIMEUNITS, as a power of 2
#define EASYLINK_MIN_CCA_BACKOFF_WINDOW 5 // min backoff of 8ms

//! \brief Maximum CCA back-off window in units of
//! EASYLINK_CCA_BACKOFF_TIMEUNITS, as a power of 2
#define EASYLINK_MAX_CCA_BACKOFF_WINDOW 8 // max backoff of 64ms

//! \brief The back-off time units in microseconds
#define EASYLINK_CCA_BACKOFF_TIMEUNITS 250 // 0.25ms

//! \brief RSSI threshold for Clear Channel Assessment (CCA)
#define EASYLINK_CS_RSSI_THRESHOLD_DBM -70

//! \brief Time for which the channel RSSI must remain below the specified
//! threshold for the channel to be considered idle
#define EASYLINK_CHANNEL_IDLE_TIME_US 180000 // channel must remain idle for 180ms

// Configure the EasyLink Carrier Sense Command
memset(&EasyLink_cmdPropCs, 0, sizeof(rfc_CMD_PROP_CS_t));
EasyLink_cmdPropCs.commandNo = CMD_PROP_CS;
EasyLink_cmdPropCs.rssiThr = EASYLINK_CS_RSSI_THRESHOLD_DBM;
EasyLink_cmdPropCs.numRssiBusy = 5;
EasyLink_cmdPropCs.startTrigger.triggerType = TRIG_ABSTIME;
EasyLink_cmdPropCs.condition.rule = COND_STOP_ON_TRUE; // Stop next command if this command returned TRUE,
// End causes for the CMD_PROP_CS command:
// Observed channel state Busy with csConf.busyOp = 1: PROP_DONE_BUSY TRUE
// 0bserved channel state Idle with csConf.idleOp = 1: PROP_DONE_IDLE FALSE
// Timeout trigger observed with channel state Busy: PROP_DONE_BUSY TRUE
// Timeout trigger observed with channel state Idle: PROP_DONE_IDLE FALSE
// Timeout trigger observed with channel state Invalid and csConf.timeoutRes = 0: PROP_DONE_BUSYTIMEOUT TRUE
// Timeout trigger observed with channel state Invalid and csConf.timeoutRes = 1: PROP_DONE_IDLETIMEOUT FALSE
// Received CMD_STOP after command started: PROP_DONE_STOPPED FALSE
EasyLink_cmdPropCs.csConf.bEnaRssi = 0x1; // Enable RSSI as a criterion
EasyLink_cmdPropCs.csConf.bEnaCorr = 0x1; // Enable correlation as a criterion
EasyLink_cmdPropCs.csConf.operation = 0x0; //!< \brief 0: Busy if either RSSI or correlation indicates Busy<br>
//!< 1: Busy if both RSSI and correlation indicates Busy
EasyLink_cmdPropCs.corrPeriod = 0x20; // Number of RAT ticks for a correlation observation periods (*4 for us)
EasyLink_cmdPropCs.corrConfig.numCorrBusy = 0x3; //!< \brief Number of subsequent correlation tops with maximum <code>corrPeriod</code> RAT ticks between them
//!< needed to go from Invalid to Busy
EasyLink_cmdPropCs.corrConfig.numCorrInv = 0x2; //!< \brief Number of subsequent correlation tops with maximum <code>corrPeriod</code> RAT ticks between them
//!< needed to go from Idle to Invalid
EasyLink_cmdPropCs.csConf.busyOp = 0x1; // End carrier sense on channel Busy
EasyLink_cmdPropCs.csConf.idleOp = 0x0; // Continue carrier sense on channel Idle
EasyLink_cmdPropCs.csEndTrigger.triggerType = TRIG_REL_START; // Ends at a time relative to the command started
EasyLink_cmdPropCs.csEndTime = EasyLink_us_To_RadioTime(EASYLINK_CHANNEL_IDLE_TIME_US);

Thanks,

Nick

  • 0
    TI__Guru* 79361 points

    Please provide info regarding which SDK version you are running and provide a small example based on one of the EasyLink examples that we can use to reproduce the issue you are seeing.

  • 0 in reply to Siri
    Prodigy 205 points

    Thanks for the response, Siri.

    Note that I've determined that, in this failure mode, the ccaDoneCallback is not being called after scheduling the RF CCA command successfully. The scheduler is still running properly, other events are able to 

    We are using SDK version 3.20.0.23.

    This is running on a custom board, but I will work on packaging it up such that it can be shared easily and operate on the Launchpad.

  • 0 in reply to Nick Masur
    Prodigy 205 points

    Looking at the rfListenBeforeTalk_CC1310_LAUNCHXL_tirtos_ccs project, and looking at the RF.h documentation:

    It looks like RF_cmdPropCs.condition.rule in the example iis set to COND_SKIP_ON_FALSE, but the RF.h documentation states that the RF_postCmd function only supports COND_ALWAYS and COND_NEVER. Wondering if this could be contributing to my issue, as I am using COND_STOP_ON_TRUE, which is also theoretically not supported by RF_postCmd.

    Thanks.

  • 0 in reply to Nick Masur
    Prodigy 205 points

    Siri, still working on getting this into a sharable format, but made another discover. It seems to have returned to normal operation after about 14 minutes of nothing. Wondering if my CCA parameters could be leading to an extremely long timeout. Can you please check the #defined values in the original post and make sure nothing is obviously wrong?

    Thanks.

  • 0 in reply to Nick Masur
    TI__Guru* 79361 points

    I have a few questions/suggestions

    1) Do you see the same problem if updating the SDK to the newest one?

    2) Where in the RF driver documentation is it stated that RF_postCmd function only supports COND_ALWAYS and COND_NEVER? I was not able to find this.

    Not sure how this should create an issue in that example as it uses RF_runCmd, and it is the NOP command that is run, not the CS command.

    Please remember that when you use the EasyLink  API you are not supposed to do any changes to the EasyLink.c file.

    The different functions are written for a special configuration of the of the lower lever PROP RF API, and once you start doing changes to it (like you do with the CS command), the EasyLink API might not work as intended.

    It looks for example as you are using startTrigger.pastTrig = 0. This should be 1.

    Have you tried running the default LBT example for EayLink? Do you experience the same problems there?

    Siri

  • +1 in reply to Siri
    Prodigy 205 points

    1. Have not tried to update to the latest SDK as there are a lot of changes, particularly with the introduction of SysConfig.

    2. See the RF_postCmd function documentation in the link below.

    https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/tidrivers_cc13xx_cc26xx_2_20_00_08/docs/doxygen/html/_r_f_8h.html#a2b0ee444fcb74917df94eefea804ecbb

    I have been tinkering around with the EasyLink.c file, there are things that need to be changed in the timing to make it work with our API. If that's inadvisable, we might just get rid of the EasyLink layer and go direct to the RF layer.

    I seem to have fixed the issue by adjusting usage of the TRIG_NOW and TRIG_ABSTIME options.

    Thanks.