• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 447 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.

Original question:

RTOS/LAUNCHXL-CC1310: cc1310 Easylink_abort() pending problem

RTOS/LAUNCHXL-CC1310: cc1310 Easylink_abort() pending problem

xuntai zheng
Prodigy 70 points
Part Number: LAUNCHXL-CC1310

Tool/software: TI-RTOS


I am a bit confused. You said you had 2 nodes and 1 concentrator. But in your explanation and within your code, there are two destination addresses or concentrator addresses. Can you describe more on what exactly are you trying to achieve. 
The reason that it is stuck in RF_pendCmd is that it is waiting for a packet to be received for a address (on a second concentrator) that does not exist and is stuck there forever. 
Regards,

Hi ,

What's the mean of The reason that it is stuck in RF_pendCmd is that it is waiting for a packet to be received for a address (on a second concentrator) that does not exist and is stuck there forever. Do you mean that we could not change the Rx filter otherwise it would stuck  in RF_pendCmd ?  If we only allow to call the EasyLink_enableRxAddrFilter  one time?

  • 0
    TI__Intellectual 1040 points

    The confusion lies in your initial set up.

         (no. 1)

         source addr: 0xaa

         destination addr: 0x00

        (No.2)

         source addr: 0xbb

         destination addr: 0x11


    Since the destination address for No.1 and No. 2 are different you actually have two concentrators configured. Therefore, you are either sending a packet to a destination that does not exist (No.1 node -> No. 1 conc & No. 2 node -> No. 2 conc which might not exist) or you are not transmitting to the right destination (No. 1 node -> No. 1 conc & No. 2 node -> No. 1 conc). The second option would be what would cause the RF_pendCmd to wait forever since No. 2 conc would never receive a packet with the correct destination address. 

  • 0 in reply to AJB
    Prodigy 70 points
    thanks, I see.
    Now I meet the problem is that :
    1. I enable the RX addr filter and set the addr length is 4, the filter num is 1, and set change the
    #define EASYLINK_MAX_ADDR_SIZE 4
    #define EASYLINK_MAX_ADDR_FILTERS 3
    2. I call EasyLink_transmit to send data
    3. I call the EasyLink_receiveAsync to receive data.
    4. I call the EasyLink_abort to abort receiving. and I struck in the RFCDoorbellSendTo to wait the CM0 starts to parse the command。

    // Wait until the CM0 starts to parse the command
    while(!HWREG(RFC_DBELL_BASE + RFC_DBELL_O_RFACKIFG))
  • 0 in reply to xuntai zheng
    Prodigy 70 points
    I find the cause of the problem is the addrFilterTable is not aligned 4 byte .