• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 545 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: ZED leaving network randomly

Akhilesh Premkumar
Intellectual 995 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Hi,

We have been observing a issue with ZED leaving the network randomly and not rejoining back to the coordinator.
There are mutliple such ZEDs on the same network, but not all of them leave.

We experienced some power cuts and suspected that the issue could be because of that.
However, when we tried to reproduce the issue with the following scenarios :

1. Simulate power cut. ZC and all ZR on network are powered down. ZEDs stll running.
ZEDs go into a rejoin loop(configured to 40s) and rejoin to network when a nearby ZC or ZR powers up.
Tested for time gap of 24hrs b/w power down and power up

2. Simulate ZC down. ZR powered up. ZEDs still running
ZEDs are still in sleep loop(configured to 240s) and poll the nearby parent ZR regularly.
The ZR performs route discovery on pending messages.
When ZC powers up then any further messages are processed successfully.
Tested for time gap of 24hrs b/w ZC power down and power up.

In either of the case we could not reproduce the ZED resetting itself or leaving the network.
The ZC logs have no leave request.
Since the Leave is unpredictable, I cannot sniff for a leave event.

What could the possible cause for ZED leaving the network ?

Please could you outline the possible causes for a ZED to leave the network ?

Thanks
Akhilesh

<Configuration of my ZED>
Rejoin timeout -> 40 seconds
Sleep poll rate rate -> 240 seconds
Minimum time between consecutive message sends  from ZED -> 200 ms

  • 0
    TI__Guru**** 212517 points

    Hi Akhilesh,

    What Z-Stack version are you evaluating?  Do the ZEDs support OTA upgrades?  This behavior could be due to NV memory corruption.  Of course it would be best if the issue could be reproduced to view the sniffer log and see what is being communicated on the network. http://processors.wiki.ti.com/index.php/Zigbee_Known_Issues_and_Proposed_Fixes 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 995 points

    Hi Ryan,

    I am using Z-Stack 3.0.2.

    My ZEDs are not using the OTA cluster.

    I am also not using any Osal_nv memory in my app. This issue never seems to happen with the routers.
    Does the NV memory corruption occur when rejoining a network ? 

    I checked for some changes in the wiki and they are already present. I presume they were fixed in v3.0.2

    Does the scenario,  'ZC sends ZEDs Leave Reqs after MAC Association' , apply to rejoin as well ? I think it wouldn't since rejoin is only to a nearby parent module.

    Thanks
    Akhilesh

  • 0 in reply to Akhilesh Premkumar
    TI__Guru**** 212517 points

    Hi Akhilesh,

    You should have NV_INIT and NV_RESTORE defined regardless for rejoining existing known networks after a reset, and therefore the OSAL NV driver is being used.  ZEDs may have the ZC as their parent and it would be beneficial to increase the number of network layer data buffers on the ZC/ZRs if RAM permits, and stagger ZED (re)joins as to not overwork the routing devices.  Once again, a sniffer log of the issue would help us avoid speculation.  How many devices are commissioned into your network?  Here is an E2E thread to be aware of: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/746836/ 

    Regards,
    Ryan