• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 507 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.

CC2530: Association Successful, Device Does not join network

sdb@23
Prodigy 135 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, CC2538

Hello,

Versions used

ZR - zstack 3.0.2 (samplelight cc2530)

ZC - zstack 3.0.2 (znp cc2530)

Test setup: 

1 ZC 

85 ZRs (3 set of approx 30 ZRs placed in 3 locations)

During network formation, we observed that

  • Few ZRs were sending Beacon Request, and the association request and association was successful
  • But after Association response, the network joining procedure ( Device Announcement, Match Descriptor, Transport key check) did not happen
  • This behaviour was observed for different ZRs randomnly
  • The same ZR after sometime would Join the network successfully, (without factory reset, reboot)

What might be causing this behavior (randomnly) ?

Could it be a fault with ZC

I have attached a filtered sniffer log where ZR1 (00124b001fe5d0a5) is trying to join network through ZR2 (00124b001f9e24d3, short addr:930b) several times

Key: 00:01:02:03:04:05:06:07:08:09:0A:0b:0c:0d:0e:0f

Regards,

Suhrith

  • 0
    TI__Guru**** 217867 points

    Hi Suhrith,

    I'm having difficulty parsing your sniffer log.  It would appear that some command is sent from the ZR2 to the ZC but I don't understand why four are sent in quick succession when the ZC appears to ACK the message, plus the data is not correct for the expected Update Device command.  Either way the ZC never tunnels the NWK key.  I've mentioned in a previous E2E thread that supporting 85 nodes with a Z-Stack 3.0.2 CC2530 ZC will not be possible.  You may be able to pick up some more useful network configurations from the Known Issues E2E post depending on the amount of network traffic being processed by the ZC.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 135 points

    Thanks Ryan,

    Q: Is the NWK key transported to the ZR and is an Update Device command sent to the ZC along with a TCLK tunnel afterwards?

    In  this case none of these activities takes place,

    The node will be in Beacon request -> Association successful -> Beacon request cycle

    Whatever is available in the sniffer logs I have shared

    2) supporting 85 nodes with a Z-Stack 3.0.2 CC2530 ZC will not be possible

    It might take some time for us to move to CC2538, the above problem was faced during the test mentioned in the previous thread

    If we avoid the TCLK exchange procedure in Z stack 3 with cc2530 ZC, can we accommodate 85 nodes ?

    3) Yes we have referred to the post,

    Few points related to ZC explicitly mentioned when ZEDs are used (have not been added to code), will make those changes in the ZC and check if the problem is resolved

  • 0 in reply to sdb@23
    TI__Guru**** 217867 points

    I recommend switching to a CC2538 ZC immediately, the other nodes can be CC2530 devices.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 135 points

    Hello,

    My understanding of a ZR A trying to join the network through intermediate ZR B

    1) ZR A sends Beacon Request

    2) ZR B and ZC send Beacon

    3) ZR A sends Association request to ZR B once it completes scanning channels

    4) On ZR B, Association is successful, it assigns a Short Address to ZR A and send Update Device to ZC

    (Until this stage the NWK Key is not checked, any node with Network key A,B,C can send Association request to a ZR with Key X)

    5) The ZC initiates NWK key tunneling through ZR B

    6) ZR A checks for the key received, broadcasts device announcement 

    7) Match Descriptor 

    8) TCLK exchange

    In which scenarios can step 5, i.e ZC not initiate transport key (nwk key exchange) ?

    Regards,

    Suhrith

  • 0 in reply to sdb@23
    TI__Guru**** 217867 points

    Your understanding of the joining sequence is accurate.  Insufficient RAM resources in the heap could be causing your CC2530 ZC to not respond, however you could evaluate behold's suggestions from this relevant E2E post and determine whether it resolves your issue.  Otherwise you may consider debugging ZDSecMgrUpdateDeviceInd -> ZDSecMgrDeviceJoin to gather more information.

    Regards,
    Ryan