• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 431 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:

CC1310: When is a node added to the coordinator's frequency-hopping neighbor table?

CC1310: Association Confirm status of 0xEB when trying to join a frequency-hopping network

Eugene Peng
Intellectual 620 points
Part Number: CC1310

Hi,

I have the coordinator (Linux application + TI 15.4 COP) start a frequency hopping network.

When I try to get a node to join, it successfully receives the ASYNC frames PA and PC. But when it sends association request, it receives an association confirm status of 0xEB (no data).

What could be the reason?

If I restart the coordinator, which restores the same network, and then have the node join again, it then associates successfully.

Thank you,

Eugene

  • 0
    TI__Guru**** 217467 points

    Hi Eugene,

    Is the network open for joining and the correct specified channel list selected between both the sensor node and co-processor? Is this a new join on both devices which fails, and simply by restarting the coordinator (without a factory reset) this issue is resolved? Does this similar behavior occur if you use a collector example instead of the co-processor? Which SDK version are you using to evaluate the examples? dev.ti.com/.../frequency-hopping-mode.html

    http://software-dl.ti.com/simplelink/esd/ti15.4stack_linux_x64/2.08.00.04/exports/docs/html/ti154stack-linux/linux-troubleshooting.html 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Hi Ryan,

    Responses to your questions:


    Is the network open for joining and the correct specified channel list selected between both the sensor node and co-processor?
    My understanding is that permit join is not required in frequency hopping networks. I have observed nodes join without permit join being open.

    The frequency hopping channel masks on both the node and the coordinator are configured to be all channels.

    Is this a new join on both devices which fails, and simply by restarting the coordinator (without a factory reset) this issue is resolved?

    This is a new join by one sensor node. When the coordinator starts the first the time with a new network, the sensor node receives association confirm status of 0xEB. The coordinator never reports association indication (so it never saw the assication request from the sensor node). Then if I restart the co-processor and the linux app, which restores the same network, now the same sensor node can associate successfully.

    Does this similar behavior occur if you use a collector example instead of the co-processor?

    My Linux application is based on TI's collector linux example, though not exactly the same. I haven't tried TI's original example. I could try that.

    Which SDK version are you using to evaluate the examples?


  • 0 in reply to Eugene Peng
    Intellectual 620 points
    SDK version:
    Sensor node is built on SimpleLink 2.20. Linux app is based on TI linux example 2.08
  • 0 in reply to Eugene Peng
    Intellectual 620 points
    What is strange in this error state is that when the coordinator receives the Association Request; it sends ACK; but the Association Indication callback is not triggered, and so no Association Response is sent.

    After resetting the coordinator, then it works.

    What could prevent the 15.4 MAC from triggering Association Indication even when it has received and acknowledged Association Request?
  • 0 in reply to Eugene Peng
    Intellectual 620 points
    Oops, turns out I disabled Association Permit unintentionally. That is why the association requests were simply discarded.
  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points

    Glad to see you figured it out, thanks for posting the solution!

    Regards,
    Ryan