CC1310 repeatedly calling RF_runCmd hangs after ~250 seconds

David Schmidt3

Hello,

I have a test application with a single task containing a loop that calls RF_runCmd() to repeatedly execute a radio receive command with a time-out of one second. The loop runs for between 250 and 260 seconds, and then RF_runCmd() hangs for about 10-15 minutes before it returns again before it starts running again for another 250 to 260 seconds. The exact timing is variable, but it is 100% repeatable and always close to the same amount time. It doesn't matter if I change the receive time-out to 1/4 second; it just loops for more iterations, but still stops after the same total time. It doesn't matter if I pause execution with debugger, it will still stop at after the expected number of loops that corresponds to the total time running.

What could be causing this and how should I troubleshoot further? Here is the code:

Task_Struct rfSimpleTask; /* not static so you can see in ROV */

#define RF_SIMPLE_TASK_STACK_SIZE 1024
#define RF_SIMPLE_TASK_PRIORITY 2
static uint8_t rfSimpleTaskStack[RF_SIMPLE_TASK_STACK_SIZE];

static int num_loops = 0;

RF_Handle rfSimpleHandle;

RF_Object rfSimpleObject;

static void rfSimple_TaskFxn(UArg arg0, UArg arg1)
{

RF_Params rfParams;
RF_Params_init(&rfParams);

RF_EventMask em;
rfSimpleHandle = RF_open(&rfSimpleObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);

/* Set the frequency */
RF_runCmd(rfSimpleHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);

while (1) {

RF_cmdPropRx.pQueue = NULL; /* (Changed to NULL to troubleshoot the problem) -- Set the Data Entity queue for received data */
RF_cmdPropRx.rxConf.bAutoFlushIgnored = 1; /* Discard ignored packets from Rx queue */
RF_cmdPropRx.rxConf.bAutoFlushCrcErr = 1; /* Discard packets with CRC error from Rx queue */
RF_cmdPropRx.maxPktLen = 124; /* Implement packet length filtering to avoid PROP_ERROR_RXBUF */
RF_cmdPropRx.pktConf.bRepeatOk = 1; // don't stop at first packet
RF_cmdPropRx.pktConf.bRepeatNok = 1; // don't stop at first crc error

RF_cmdPropRx.startTrigger.triggerType = TRIG_ABSTIME;
RF_cmdPropRx.startTrigger.pastTrig = 1;
RF_cmdPropRx.startTime = 0;

RF_cmdPropRx.endTrigger.triggerType = TRIG_ABSTIME;
RF_cmdPropRx.endTime = RF_getCurrentTime() +(1000*(4000000/1000)); // 1 second timeout

em = RF_runCmd(rfSimpleHandle, (RF_Op*)&RF_cmdPropRx, RF_PriorityNormal, NULL, 0);

num_loops++;

}

void rfSimple_start() {

Task_Params rfSimpleTaskParams;

Task_Params_init(&rfSimpleTaskParams);
rfSimpleTaskParams.stackSize = RF_SIMPLE_TASK_STACK_SIZE;
rfSimpleTaskParams.priority = RF_SIMPLE_TASK_PRIORITY;
rfSimpleTaskParams.stack = &rfSimpleTaskStack;

num_loops = 0;

Task_construct(&rfSimpleTask, rfSimple_TaskFxn, &rfSimpleTaskParams, NULL);

}

int main(void) {

/* Call board init functions. */
Board_initGeneral();

rfSimple_start();

/* Start BIOS */
BIOS_start();

return (0);

}

over 8 years ago

0 Firefighter over 8 years ago

TI__Genius 12480 points

What TI-RTOS version are you using?

0 Richard W. over 8 years ago

TI__Genius 14860 points

Hi,

your start and end triggers might be valid in theory, but are not good for the scenario that you describe. If you intend to start the RX command immediately and you want it to timeout 1s after starting, then you should use the following settings:

// Convenience macro
#define RF_convertMsToRatTicks(milliseconds) \
    ((uint32_t(milliseconds)) * 1000 * 4) 

RF_cmdPropRx.startTrigger.triggerType = TRIG_NOW;

RF_cmdPropRx.endTrigger.triggerType = TRIG_REL_START;
RF_cmdPropRx.endTime = RF_convertMsToRatTicks(1000); // 1 second timeout

Use TRIG_ABSTIME for the start trigger only if you want the command to start the command at a certain time in the future.

Why did the error above happen? I guess that it interferes with the RF driver's automatic power-management. The RF driver looks at RF operation commands with startTrigger.triggerType == TRIG_ABSTIME and powers down the RF core if the startTime is far enough in the future. In your case, it sees a startTime of 0 and pastTrig = 1. But how should it decide whether 0 is a time in the future or in the past? The RF driver assumes, that a time with (startTime - currentTime) below a certain threshold, is in the future and bigger values must be in the past. I think it was 1/2 RAT cycle in until TI-RTOS 2.21, but that will change in the next release. Commands in the past with pastTrig set are immediately dispatched to the RF core. Commands that are assumed to start in the future, are kept on the M3 and the RF driver defers them until the start time is reached.

So, for the first few minutes, startTime = 0 is assumed to be in the past and the command executes immediately. After that, it's assumed to be in the future and the RF driver waits until the RAT reaches 0.

0 David Schmidt3 over 8 years ago in reply to Richard W.

Prodigy 70 points

Thank you so much, that solved the problem!

David

0 David Schmidt3 over 8 years ago in reply to Firefighter

Prodigy 70 points

It looks I was using TI-RTOS 2.20.0.6. I see there is a 2.21 available now.

However, the problem was solved by Richard's suggestion.

Sub-1 GHz

Sub-1 GHz forum

CC1310 repeatedly calling RF_runCmd hangs after ~250 seconds