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.

CC2650: RNP (2 Originators and 1 Recipient) fake pair operations question.

Part Number: CC2650

I am sorry if this has been covered in other thread. I have done a lot of searching and was not able to find an answer.

I am using two CC2650, both are talking to/from the host using UART, so I can simply send a stream of bytes of user data over ZigBee. I am using the RNP project for LP as my base.

I am able to fake pair the Recipient (R1) with both Originator (O1 and O2). When the host (a serial terminal application on PC) send 5 bytes to the R1, it get sent to the Originators, i.e. 0xE0 0x02 0x03 0x04 0x05 get sent to O1 at pair entry 0, while 0xE1 0x02 0x03 0x04 0x05 get sent to O2 at pair entry 1. Both, at the other side, will be sent using UART to the host (another serial terminal application on PC). Great!

In reverse, O1 can sent the test bytes back to R1, and R1's serial terminal can see the bytes. Also Great!

However, when do the same at O2, I see the packet in the sniffer, and I think it was being ACKed, but nothing happen on the R1, not evening the RCN_CbackEvent get called at the rnp_stack. Thus, nothing is being sent to the Host.

Am I missing something obvious here, that I can have entry 0 working round trip, but not entry 1.... ? Any suggestion is welcome, thanks!

Thank you for reading this post.

  • Hi Ronald, are you able to share the sniffer log and/or the application? I'm also curious on how you did a "fake pair" of O1 and O2 onto R1. Perhaps that pairing didn't go as expected.
  • Hi Tom, thank you for reading and replying to my post. Please find the information you asked for in this post.

    A brief of what I have done, I used the RNP project as my base line, added a user thread/task, that at reset, setup the Configuration Parameters, and State Attributes, and writing my paired table entries for fake pair, with code block similar to the following:

    static uint8_t initRtiPairingTblEntry0[43] = { 0x00, 0xFF, 0x68, 0x27,
    0x00, 0xEF, 0xBE, 0x0F, 0x05, 0xB6, 0xAD, 0x07, 0x00, 0x4B, 0x12, 0x00, 0xAD, 0xDE, 0x34, 0x12,
    0x0C, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x01, 0x01,
    0x01, 0x01, 0x07, 0x00, 0x01, 0x00, 0x00 };

    // Enable this block to write Pairing Entry 0 into the pairing table
    memset(userThreadNpiFrame, 0, sizeof(userThreadNpiFrame));
    memset(userThreadNpiFrame->pData, 0, sizeof(userThreadNpiData));
    thisLen = 43;
    if (myMsg = (_npiFrame_t *)NPITask_mallocFrame(sizeof(_npiFrame_t) + thisLen))
    {
    myMsg->dataLen = thisLen;
    myMsg->cmd0 = RTI_SYNC_REQ;
    myMsg->cmd1 = RTI_CMD_WRITE_ITEM;
    myMsg->pData = &initRtiPairingTblEntry0[0];

    NPIUtil_enqueueMsg(npiSyncRxQueue, syncEvent,
    NPITASK_SYNC_FRAME_RX_EVENT,
    (unsigned char *) myMsg);
    }
    OSIUserTask_events = Event_pend(osiSyncEvent, Event_Id_NONE,
    OSIUSERTASK_REPLY_EVENT, BIOS_WAIT_FOREVER);

    The following is entry index 1:

    static uint8_t initRtiPairingTblEntry1[43] = { 0x01, 0xFF, 0x68, 0x27,
    0x01, 0xEF, 0xBE, 0x0F, 0x05, 0x11, 0xAE, 0x07, 0x00, 0x4B, 0x12, 0x00, 0xAD, 0xDE, 0x68, 0x12,
    0x0C, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x03, 0x02, 0x01, 0x02,
    0x01, 0x01, 0x07, 0x00, 0x01, 0x00, 0x00 };

    // Enable this block to write Pairing Entry 1 into the pairing table
    memset(userThreadNpiFrame, 0, sizeof(userThreadNpiFrame));
    memset(userThreadNpiFrame->pData, 0, sizeof(userThreadNpiData));
    thisLen = 43;
    if (myMsg = (_npiFrame_t *)NPITask_mallocFrame(sizeof(_npiFrame_t) + thisLen))
    {
    myMsg->dataLen = thisLen;
    myMsg->cmd0 = RTI_SYNC_REQ;
    myMsg->cmd1 = RTI_CMD_WRITE_ITEM;
    myMsg->pData = &initRtiPairingTblEntry1[0];

    NPIUtil_enqueueMsg(npiSyncRxQueue, syncEvent,
    NPITASK_SYNC_FRAME_RX_EVENT,
    (unsigned char *) myMsg);
    }
    OSIUserTask_events = Event_pend(osiSyncEvent, Event_Id_NONE,
    OSIUSERTASK_REPLY_EVENT, BIOS_WAIT_FOREVER);

    For the sniffer, I am using the TI packet sniffer 2.18.1, set the protocol to ZigBee RF4CE, data attached as follow: /cfs-file/__key/communityserver-discussions-components-files/667/4505.R1O1O2_5F00_PingPong_5F00_Test.psd

    P.nbr 1: R1 send to O1

    P.nbr 2: O1 ACKed

    P.nbr 3: O1 send to R1

    P.nbr 4: R1 ACKed

    P.nbr 5: R1 send to O2

    P.nbr 6: O2 ACKed

    P.nbr 7: O2 send to R1

    P.nbr 8: O2 send to R1 (auto retry by the stack, because no ACKed)

    P.nbr 9: R1 ACKed

    Also, the following is what I can see at the UART side, when doing the ping pong test, that is, send a packet from R1 to O1 (works), then O1 send to R1 (works); then R1 send to O2 (works), then finally O2 send to R1 (not working). In the working cases, I can see the test packets in sniffers and they are received and "send to host" all the way to the UART, showing up on terminal. On the not working case, I see the packet in the sniffer and it looks like it was being ACKed, but nothing is showing up on the UART terminal.

    /cfs-file/__key/communityserver-discussions-components-files/667/3835.Terminal_5F00_R1.txt

    /cfs-file/__key/communityserver-discussions-components-files/667/8372.Terminal_5F00_O1.txt

    /cfs-file/__key/communityserver-discussions-components-files/667/8171.Terminal_5F00_O2.txt

    We can see all the RTI_SendDataCnf (4A 03) came back with state RTI_SUCCESS (00)

    I am puzzled, as the fake pair seem working half way for the 2nd index, while working both ways for the 1st index, and I think I do them similarly, with different MAC addresses and short addresses.

    I really hope you could spot what I am doing wrong, that I am sure there is something I am missing.

    Thank you very much for your effort!!!