CC1310: RF_runImmediateCmd returns RF_StatCmdDoneError

Stefan Hauenstein

Part Number: CC1310

Hi,

I'm in wakeonradio receive mode, partial read entry type. If the first 16 bytes of a packet are received I calculate the length of that packet and try to set the true receive length via the PropSetLen command. But RF_runImmediateCmd returns a RF_StatCmdDoneError which explains that I always receive 1184 bytes while the global buffer size is set 1200 bytes.

The callback looks similar like:

void RadioCallback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
{
  if( e & RF_EventNDataWritten)
  {
    WORD wPacketLen;
    if(wRadioRxCount == 0)
    {

      wPacketlen = CalculateLen();    
        
      RF_cmdPropSetLen.rxLen = wPacketLen; // Echte Paketlänge speichern
      status = RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
      // status is always RF_StatCmdDoneError
    }
    wRadioRxCount += 16;
  }
  else if( ( eCurrentMode == RFMODE_WOR) && ( wRadioRxCount == 0) && ( e & RF_EventLastCmdDone))
  {
    RadioWOR(); // Next wor interval
  }
  else if( e & RF_EventLastCmdDone)
  {
    // handle received packet
  }
}

Why is the RF_runImmediateCmd call rejected by the RF core?

Kind regards,

Stefan

over 2 years ago

0 Siri over 2 years ago

TI__Guru* 79101 points

Hi Stefan

One of the things that will make the status return RF_StatCmdDoneError is if the RX command that is running is out of buffer.

I did a test where I used partial read entries, but delayed the calling of the RF_runImmediateCmd until RX mode had been terminated due to PROP_ERROR_RXFULL, and in that case, status where set to RF_StatCmdDoneError

What is the status of your RX command when this is happening?

0 Stefan Hauenstein over 2 years ago in reply to Siri

Intellectual 450 points

Hi Siri,

the callback code I use was an example code from https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/689154/cc1310-require-partial-mode-example-of-cc1310

I think RF_runImmediateCmd is not working, because it is only allowed to be used while a CMD_PROP_RX or CMD_PROP_RX_ADV command is running. In my case I have a CMD_PROP_RX_SNIFF command running. Which actually should be working as well. Is the example code OK at all?

0 Siri over 2 years ago in reply to Stefan Hauenstein

TI__Guru* 79101 points

When I tested, I used the normal RX command and not the sniff command. From the TRM you can see the following:

"CMD_PROP_SET_LEN must only be sent while a CMD_PROP_RX or CMD_PROP_RX_ADV command
is running configured with unlimited packet length."

I checked with R&D, and they can confirm that the SET_LEN command cannot be used when sniff mode is running.

Siri

0 Stefan Hauenstein over 2 years ago in reply to Siri

Intellectual 450 points

Ok, can you then send me the result? How do I change the code not to receive until the buffer is full but rather the true packet length?

+1 Siri over 2 years ago in reply to Stefan Hauenstein

TI__Guru* 79101 points

Not sure I understand what results you are requesting. You state that you are using sniff mode, and I said that the SET_LEN command is not supported for sniff mode. There are no way of getting around this. If you are using the sniff command, and do not have length information as part of the header (first 4 bytes after the sync word) it is not possible to have the RF core automatically stop receiving a packet when it is done.

If this is the case, you need to get the length information from the received data (as you do when using the SET_LEN command), but instead of sending this command, you simply need to cancel the sniff command manually when you have received all the bytes that you want.

Assume the following:

The packet you transmit have 9 bytes after sync and then a length byte, that is 55. After that there are 55 payload bytes and 2 CRC bytes:

---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------

With the SET_LEN command, you will tell the radio how many bytes it is going to receive and it will automatically stop receiving after the CRC bytes (and it will be able to automatically do a CRC check.

When you cannot use the SET_LEN command (not supported for Sniff mode), you can for example get an interrupt every time at least 10 bytes are in the data entry.

After the first interrupt, you read the 10 bytes received and get the info saying that 55 more bytes are coming.

Your packet is 67 bytes long after sync (so you need to receive 10 bytes 7 times, to be sure that you have received everything.

After you have received these 70 bytes, you manually cancel the sniff command (exit RX). Since you have received 3 more bytes in the data entry before cancelling RX (70 instead of 67) you cannot have the radio check the CRC, but you manually needs to calculate the CRC over hte bytes that you know from the length information is part of your packet, and then just ignore the 3 last bytes put in the data entry (noise).

Siri

0 Stefan Hauenstein over 2 years ago in reply to Siri

Intellectual 450 points

I cannot use the auto packet handling because the header is stored in one block with LSByte at the end. I would need a config like hdrConf.noSwap regardless of formatConf.bMsbFirst..

Do you mean exit RX by RF_flushCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, 0) ?

It would be a nice feature that CMD_PROP_SET_LEN not only works while a CMD_PROP_RX or CMD_PROP_RX_ADV command
is running.

Sub-1 GHz

Sub-1 GHz forum

CC1310: RF_runImmediateCmd returns RF_StatCmdDoneError