• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 2674 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.

Coordinator Restarting

Luka Newton
Prodigy 50 points

Other Parts Discussed in Thread: Z-STACK

Hello

Just after some advice on what to do in the following situation.

My coordinator creates a network with a specific extended PANID and several routers / end devices join this network. If after X seconds a router / end device fails to communicate with the coordinator then the device is reset and all being well reconnects to the network as it assumes something has gone wrong. However if the coordinator resets for some reason e.g. watchdog / power cut  / user , then I'm unsure of what to do.

The problem:

If while the system is up and running the coordinator resets then the first thing it will try and do is try and create a new network. Unfortunately this network already exists i.e. the routers and end devices. It appears that a new network is created but with a different PAN ID (not extended). Now the routers / end devices will reset themselves after X seconds because they have not sent anything to the coordinator (its on a different network now). However when a device restarts how does it decide which  network to join? There are two, the one created by the coordinator and the one that previously exists (routers / end devices)? They both have the same extended PANID.

I was thinking about killing the network quickly with DEV_NWK_ORPHAN state change. When the coordinator reset, the routers connected to it receive  the DEV_NWK_ORPHAN state change and reset, devices connected to those routers then receive the DEV_NWK_ORPHAN state change and they reset,  and so on and so on. Although for some reason I'm not receiving the DEV_NWK_ORPHAN state change. Not even sure if thats the best way to do it anyway.

Luka

 

  • 0
    Guru 31280 points

    Hi Luka,

     

    Try the NV_RESTORE and NV_RESET features (section 9.6 in

    Zstack developer's guide), so when the coordinator is down

    (reset, power down, earthquake...) it'll power up in its previous

    state (with the same PANID, without trying to establish a new

    ZigBee network).

    Is this answers your question?

     

    Br,

    Igor

  • 0 in reply to Igor Sherer
    Prodigy 50 points

    Hi Igor

    Thanks for your help.

    I can't seem to find the NV_RESET feature in the Z-Stack developer's guide, did you mean NV_INIT? We are using the firmware found on the CC2530ZNP mini kit so I'm not sure if the NV_RESTORE and NV_RESET (NV_INIT) compile flag are set. Can anyone confirm this either way? Makes it difficult to tell if it not working because I'm doing something wrong or because the feature is not compiled in :)

    In terms of usage.

    As soon as the coordinator resets, the Z-Stack will automatically rejoin the network and I just need to wait for the ZDO_STATE_CHANGE_IND to indicate it has? Theres no need to do anything else e.g.  set callbacks, register generic application, start application?

    Luka

     

     

  • 0 in reply to Luka Newton
    Guru 31280 points

    Hi Luka,

     

    My bad, there's no such thing as NV_RESET, NV_INIT it is! Sorry for

    that! :)

     

    I'm not sure if am the right person to tell you whether those features

    compiled or not in ZNP FW (my guess the answer is negative).

     

    Regarding terms of usage:

    Once ZigBee device starts, after unexpected reset, with compiled NV_RESTORE

    and NV_INIT items the Z-stack will be restored to prior to shut-down state (routing

    tables, children, parent, binding tables, PANID, channel etc.) In that case, no rejoin will

    be initiated and as a side effect the ZDO_STATE_CHANGE_IND stays unchanged.

    The tricky part is the application (your application). You should design it in that way

    where unexpected shut downs of the system won't  be affecting the application.

    In other words, after the restart the application will enter to a known and  desired

    state.

    Br,

    Igor

  • 0 in reply to Igor Sherer
    Prodigy 50 points

    Well I assume NV_INIT and NV_RESTORE are compiled in as it appears to be working.

    Couple of things I did notice:

    1. If I start the coordinator (from cold) and reset it before another device connects then the coordinator creates a new network. However if a device connects to it and then I reset the coordinator, it does infact rejoin the network. Is this how it works?
    2. It also appears I do infact need to register and start the application otherwise the device state is constantly DEV_HOLD, although I can see that the network settings that they have been restored.

    Other than that everything seems good.

    Many thanks

    Luka

  • 0 in reply to Luka Newton
    Guru 31280 points

    Hi Luka,

     

    Regarding your first question:

    From my experiments, once the coordinator initiated a network,

    it will power up as the coordinator in the previously established network.

    Are you sure that until no other device/s joins to network, it won't power up

    in the same previously established network?

    Regarding your second question:

    What is the name of a variable holding this state??

     

    Igor

  • 0 in reply to Igor Sherer
    Prodigy 50 points

    Hi Igor

    Regarding the first  question - Thats what I'm seeing.

    Note: Once any device has connected, everytime I boot up the coordinator it restores itself, regardless of whether or not  a device was connected at the time of reset.

    Regarding the second question - Command ZB_GET_DEVICE_INFO (0x2606) parameter 0.

    Thanks

    Luka

     

  • 0 in reply to Luka Newton
    TI__Mastermind 19575 points

    This is good. You can use the ZB_GET_DEVICE_INFO to find out about the device state with parameter 0.
    You also have the OSAL NV interface that is used to restore the pertinent network parameters of  the node.

    This is what used when you have NV_RESTORE enabled.

    LPRF Rocks the World

  • 0 in reply to Morten Braathen
    Prodigy 50 points

    Has anyone else experienced the coordinator not remembering it's networking settings until a router/end device has connected?

    Although its not preventing our system from working I'd still like to get to the bottom of it.

    Thanks

    Luka

  • 0 in reply to Luka Newton
    TI__Mastermind 19350 points

    "If a tree falls deep in the woods and there is no one there to hear it, did it make a sound?" The architects of the ZStack have definitively answered, "no", and a network of one is not a network - there is nothing to "restore". So if a ZC has setting -DZDAPP_CONFIG_PAN_ID=0xFFFF in f8wConfig.cfg, then it will continue to randomly generate a PanId every time it is power cycled, even when it has NV_RESTORE, until one or more ZED and/or ZR joins it.