• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 8030 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.

CC2538: What causes my coordinator to loose all routing infos for all devices?

Thomas Hartwig
Expert 1460 points
Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Hello,

im using the CC2538 via the ZNP Firmware from the Z-Stack 1.2.2a. 

The network consists out of around 20 Routers and some End Devices eventually. What happens is that for no apparent reason at some point my coordinator seems to forget everything. No device can be reached anymore. The status I get if I send a data request always says ZNwkNoRoute. Is there anything I can do if I get this kind of return value from a data request? Why this happens suddenly to all of my devices? 

Regards, 

Thomas

  • 0
    TI__Expert 8950 points
    Hi,

    Is this issue reproducible? If so, do you have/can you produce a sniffer log from when this issue occurs?
  • 0 in reply to JasonB
    Expert 1460 points

    Hello,

    thanks for your reply!

    Sadly I can not reproduce this so far. It happens very randomly and only for some of our devices at the customers. I tried to switch to the new stack but there are general networking issues with the 3.0.0 stack ZNP2.7.0 (see here).

  • 0 in reply to Thomas Hartwig
    Guru 735685 points
    To better understand your problem, you have to provide Sniffer log. I suggest you to do the test again and make sure you sniff everything.
  • 0 in reply to JasonB
    Expert 1460 points

    Hello,

    I have some other news on this topic. I still can't reproduce the Issue but what I've seen is that this happened when I wanted to start the Network operation.

    I did the usual setup procedure:

    - configure device type coordinator

    - configure channel list

    - configure PAN ID creation

    - register for direct callbacks

    - register HA App

    - send ZDOStartupFromApp

    What usually happens is that I get a "restored network state notification" an the network starts. But this time all of a sudden I got a new network state and it did behave like after a network parameter reset. This clearly explains why the coordinator doesnt know any routes anymore. But how did it happen? What caused my device to drop its network information?

  • 0 in reply to Thomas Hartwig
    Guru 735685 points
    ZNP won't clear its own network state. You should check if your ZAP sends network clear to ZNP.
  • 0 in reply to YiKai Chen
    Expert 1620 points
    Hi Thomas,

    Is this an out-of-the-box firmware or have you done some changes to the ZNP firmware?, do you have enabled NV_INIT and NV_RESTORE flag?
  • 0 in reply to Luis Luna
    Expert 1460 points

    Hi,

    I've done some minor changes to the firmware, but only something like raise number of maximum associated devices define. No changes to the actual code itself.

    Right now I had some interesting findings. I can now reproduce it reliably. It happens when I do send a ZDOmgmtLeaveReq with a invalid IEEE address as parameter (0x000000000000).

    What happens exactly is that all of a sudden all included network devices will reset themselves to factory new (I saw it because some bulbs blink on a factory reset) and the coordinator itself will boot up without restoring its previous network state. The coordinator behaves like a factory new one, selecting a new network PAN ID and a frequency channel for the network. This way its clear that it doesn't know any routes anymore.

    I will make sure that the application is not sending 0x0000000000000000 as a parameter for the leave, but is this behavior intended? Is it known? Can I find somewhere documentation about it?

     

  • 0 in reply to Thomas Hartwig
    Guru 735685 points
    Can you elaborate complete parameter ZNP/MT command you use to send ZDOmgmtLeaveReq? I suspect that you send a MGMT leave request with remove children enable so all of devices are removed and ZC reset too.
  • 0 in reply to YiKai Chen
    Expert 1460 points

    I send the request with the following parameters:

    DstAddr: 0x0000 (coordinator short address)

    DeviceAddress: 0x00000000000000 (due to application failure)

    RemoveChildren_Rejoin: 0x02 (no rejoin - remove children)

  • 0 in reply to Thomas Hartwig
    Guru 735685 points
    short address 0x0000 means command would be sent to coordinator and 0x02 means remove child. This is why they are removed and ZC reset.
  • 0 in reply to YiKai Chen
    Expert 1460 points

    The specification (ZNP interface specification) document states the following explanation for DstAddr:

    > Specifies the network address of the device generating the request.

    I understand this like this is the short address of the device wich tells the device with the target IEEE to leave the network. Since my coordinator is telling the devices to leave I chose 0x0000. 

    Did I misunderstood the specc?

  • 0 in reply to Thomas Hartwig
    Expert 1620 points
    Hi Thomas,

    You are right, this is probably a miss leading comment in the documentation.
    The ZDO mgmt leave request is used to generate a nwk leave request command to remove a device from the network. This nwk leave command have some restrictions in its acceptance and processing (Ej. End Devices will not process nwk Leave request from non-parent devices), therefore in order to remove an EndDevice, you must tell its parent to remove the child; in the context of the ZDO command, the field DstAddr is meant for the parent device, the DeviceAddress is the IEEE address of the device being removed and the options are for the removed device.
    If you generate a ZDO mgmt leave request which DstAddr is 0x0000 with IEEE = 0x00's, then you are telling your device to generate a Nwk leave command to remove the device which IEEE is 0x00's, unfortunatly for your case Zigbee spec defines for this case that a null address (0x00's) is meant to be the local device, which will cause your own device to remove itself from the network as YiKai said.

    Hope this helps!
  • 0 in reply to Luis Luna
    Expert 1460 points

    Hi,

    thank you very much for the clarification on this! You mentioned that there are "some restrictions" and gave one example. Where could I find a comprehensive list of restrictions and rules which apply in this case? I have a couple of devices (Philips hue bulbs in this particular case) which ignore all of my leave requests so far. I thought its a bug (or maybe intentional) at the philips side of things. But im now considering that I generate wrong leave requests. But other lamps from other manufacturers do accept my requests usually and behave accordingly. 

  • 0 in reply to Thomas Hartwig
    Expert 1620 points
    Hi Thomas,

    You would have to refer to Zigbee Specification version supported by the devices in question, in R21 you could request the node descriptor and the version would be under the Stack version fields on the response, prior this, I'm not aware of any mean to request this.
    Z-Stack 3.0 supports R21 which is described in 05-3474-21 zigbee document.
    ZDO commands are referenced in section 2.4 (Mgmt Leave request is 2.4.3.3.5), while the processing of a nwk leave request is described in section 3.6.1.10.3.1

    Hope this helps!
  • 0 in reply to Luis Luna
    Expert 1460 points

    Thanks for the name of the document, but I seem to have trouble finding this document. The alliance website is terrible if you want to find documents. Is there any particular place where all the documents are available of which I'm not aware? Maybe the member area? Do I need to be an alliance member in order to get full access to all the documents?

    I also have a follow-up question regarding the leave request:

    How do devices behave which parent got removed? Lets say I have a network of 3 bulbs of which 2 were too far to have direct contact with the coordinator when they entered the network. So they are child nodes of bulb 1. Meanwhile their location changed and they do have direct contact with the coordinator. If I remove bulb 1 without the remove child flag set, will the 2 other bulbs remain in the network?

  • 0 in reply to Thomas Hartwig
    Guru 735685 points
    1. Spec R21 is in member area and you have to be alliance member to get it.
    2. If you remove bulb1 without the remove child flag set, the other bulbs would remain in the network.
  • 0 in reply to Thomas Hartwig
    Expert 1620 points
    Hi Thomas,

    This question is kind of tricky to answer and this is because it depends on the type of devices that these bulbs are.
    If those are Router devices (which is the most logic election for these devices as they are expected to have main power), then as YiKai says, those will remain in the network operational regardless of the remove child nodes flag being set. If those are End Devices, then the flag will be taken into consideration, if the flag is set to False, it will be up to the child devices to find a suitable parent in the network that they can join and remain in the network this way, otherwise these devices will be excluded of the network if no parent is found.

    Hope this helps!