• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 2678 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.

CC1310: Using an Address Table in RX ADV

Chris Carter
Expert 1030 points
Part Number: CC1310

has anyone been able to get the address table to function in CMD_PROP_RX_ADV?

There doesn't appear to be a definition for the table structure anywhere.

Also, Can addresses be any length between 1 and 8, or do they have to be 1, 2, 4, 8 bytes wide?

.pAddr = 0, // INSERT APPLICABLE POINTER: (uint8_t*)

  • 0
    TI__Intellectual 1881 points
    Hi Chris,
    Are you using the EasyLink Layer or the general rf commands? The EasyLink layer has address filtering built in to make this process easier. Addresses can range from 1-8 bytes.
    Thanks,
    AJS
  • 0 in reply to AJS214
    Expert 1030 points

    I'm not using Easy link. I'm using proprietary. I spent the week feeling it out and was able to solve the problem. Here is what I did:

    static uint8_t AddressList[0x10] =
{
// Support for shorter address is enabled (6 byte is being used) but addresses need to be 8 bytes long for evaluation
// Addresses are matched in the order the address bytes are received. Inspect your packet and make sure the left most
// byte is the first address byte
0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x00, 0x00, // First address to match 
0xFF, 0xEE, 0xDD, 0xCC, 0xBB, 0xAA, 0x00, 0x00 // Second address to match
};

    Then you can reference your address table like this:

    .pAddr = (uint8_t*)&AddressList; // Set the address list
.addrConf.addrSize = 0x06, // 6 byte Address or whatever size you want between 1 and 8
.addrConf.numAddr = 0x2, // adjust this to indicate how many addresses are in your table.

    Also, I think its important to note that the reception of a packet with address match when .rxConf.bAppendStatus = 0x1 appears to only describe status results for BLE reception. It is described in Table 23-105. Receive Status Byte Bit Field on page 1650 of SWCU117F–February 2015–Revised June 2016.

    There are two incorrect details in that table for proprietary mode:
    First, bits 0-5 actually indicate the index in the address table that matched. So in my case, if 0xFF-0xAA was matched, the first 6 bits will be: 000001 (indicated index position 1). This is handy if you change operations based on which address was matched.

    Second. it stats that bit 6 indicates if the packet is ignored, and bit 7 indicates CRC failure. This is wrong. Bit 6 indicates CRC failure, bit 7 indicates packet ignored.

  • 0 in reply to Chris Carter
    TI__Intellectual 1881 points
    Chris,
    Great to hear you got the addressing working. Will look into the incorrect details you found.
    AJS
  • 0 in reply to AJS214
    Expert 1030 points
    Thanks. For clarity, the details were in the BLE section, so its possible I missed it in the spec sheet somewhere, but that particular status definition is definitely not correct when: .rxConf.bAppendStatus = 0x1. My notes are accurate when issuing CMD_PROP_RX_ADV or CMD_PROP_RX_ADV_SNIFF
  • 0 in reply to Chris Carter
    TI__Genius 10955 points
    You are right that the table you quote is only relevant for BLE mode. The correct table for proprietary mode is Table 23-143 on Page 1682. I see that the references in the TRM are wrong; it looks like references to Table 23-105 and Table 23-143 have been swapped. I have reported this issue.
  • 0 in reply to hec
    Expert 1030 points

    That Helps!

    Table 23-143 matches my test results.

  • 0 in reply to Chris Carter
    TI__Guru* 85681 points

    There are two different status bytes depending on which PHY you are using. The status byte in table 23-105 is for BLE while the status byte in table 23-143 is for proprietary. The references in revision F of the user guide are switched and this will be fixed in the next revision of the document.

     

    However, when referring to the correct table everything works as expected.

     

    I did a test where I used the following TX command for transmitting the following packet:

     

    #define PAYLOAD_LENGTH     10

    #define HEADER_SIZE_BYTES   4

    // CMD_PROP_TX_ADV

    rfc_CMD_PROP_TX_ADV_t RF_cmdPropTxAdv =

    {

       .commandNo = 0x3803,

       .status = 0x0000,

       .pNextOp = 0,

       .startTime = 0x00000000, // Set in application

       .startTrigger.triggerType = TRIG_ABSTIME,

       .startTrigger.bEnaCmd = 0x0,

       .startTrigger.triggerNo = 0x0,

       .startTrigger.pastTrig = 0x1,

       .condition.rule = 0x1,

       .condition.nSkip = 0x0,

       .pktConf.bFsOff = 0x0,

       .pktConf.bUseCrc = 0x1,

       .pktConf.bCrcIncSw = 0x0,

       .pktConf.bCrcIncHdr = 0x1,

       .numHdrBits = HEADER_SIZE_BYTES * 8,

       .pktLen = PAYLOAD_LENGTH + HEADER_SIZE_BYTES,

       .startConf.bExtTxTrig = 0x0,

       .startConf.inputMode = 0x0,

       .startConf.source = 0x0,

       .preTrigger.triggerType = 0x0,

       .preTrigger.bEnaCmd = 0x0,

       .preTrigger.triggerNo = 0x0,

       .preTrigger.pastTrig = 0x0,

       .preTime = 0x00000000,

       .syncWord = 0x930B51DE,

       .pPkt = packet,

    };

    packet[] = {0x0A, 0xA1, 0xA2, 0xA3, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09 0x0A}

     

    On the receiver side I used the following RX command:

     

    // CMD_PROP_RX_ADV

    rfc_CMD_PROP_RX_ADV_t RF_cmdPropRxAdv =

    {

       .commandNo = 0x3804,

       .status = 0x0000,

       .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx

       .startTime = 0x00000000,

       .startTrigger.triggerType = 0x0,

       .startTrigger.bEnaCmd = 0x0,

       .startTrigger.triggerNo = 0x0,

       .startTrigger.pastTrig = 0x0,

       .condition.rule = 0x1,

       .condition.nSkip = 0x0,

       .pktConf.bFsOff = 0x0,

       .pktConf.bRepeatOk = 0x0,

       .pktConf.bRepeatNok = 0x0,

       .pktConf.bUseCrc = 0x1,

     .pktConf.bCrcIncSw = 0x0,

       .pktConf.bCrcIncHdr = 0x1,

       .pktConf.endType = 0x0,

       .pktConf.filterOp = 0x0,

       .rxConf.bAutoFlushIgnored = 0x0,

       .rxConf.bAutoFlushCrcErr = 0x0,

       .rxConf.bIncludeHdr = 0x1,

       .rxConf.bIncludeCrc = 0x0,

       .rxConf.bAppendRssi = 0x0,

       .rxConf.bAppendTimestamp = 0x0,

       .rxConf.bAppendStatus = 0x1,

       .syncWord0 = 0x930B51DE,

       .syncWord1 = 0x000000,

       .maxPktLen = 0x7D,

       .hdrConf.numHdrBits = 32,

       .hdrConf.lenPos = 0x0,

       .hdrConf.numLenBits = 8,

       .addrConf.addrType = 0x1,

       .addrConf.addrSize = 24,

       .addrConf.addrPos = 8,

       .addrConf.numAddr = 0x3,

       .lenOffset = 0x00,

       .endTrigger.triggerType = 0x1,

       .endTrigger.bEnaCmd = 0x0,

       .endTrigger.triggerNo = 0x0,

       .endTrigger.pastTrig = 0x0,

       .endTime = 0x00000000,

       .pAddr = (uint8_t*)&AddressList,

       .pQueue = &dataQueue,

       .pOutput = 0,

    };

     

    static uint32_t AddressList[] =

    {

    0xA1A2A3,

    0xA3A2A1,

    0xA4A5A6

    };

     

    In this case addressInd will be 1.

    Changing the TX packet to

     

    packet[] = {0x0A, 0xA3, 0xA2, 0xA1, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09 0x0A}

    will give addressInd = 0 and changing it to

    packet[] = {0x0A, 0xA6, 0xA5, 0xA4, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09 0x0A}

    gives addressInd = 2.

     

    BR

     

    Siri