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.

A possible BUG of Z-Stack Protocol.

Other Parts Discussed in Thread: CC2530

------------------------Experiment-----------------------------------

Environment

protocol:ZStack-CC2530-2.5.1a.---------zigbee-pro.

chip: CC2530,

there are three devices: a Coordinator , a router, a enddevice .NV_RESTORE is Enable.

1、establish a connection as follows

2、power of the coordinator, the enddevice's parents will change to be the router automatically.after the change happened,power on the coordinator,the connection will be:

3、now,send a message to the enddevice from the coordinator.BUT the enddevice CAN'T receive the message!


4、i changge the coordinator's code .i clear the AssociatedDevList in the init process using "

 osal_memset(AssociatedDevList ,0xFF ,sizeof(associated_devices_t)*20 );" then redo  the steps as above ,the enddevice CAN receive the message!

 but the way of step 4 cause another problem……
pls help me!

"

  • Hi,

    Is the NV_INIT enabled too?

    If not, include this option too, and then runt this test again.

  • thanks:

    i do the test as you said.but result in the same.

  • 1. If you clear AssociatedDevList, how the coordinator knows the end device's address?

    2. Do you use polling scheme in end device? make sure end device polling cycle matches the persistence time in coordinator after restart.


    Rui


  • If you use tree structure, your observation is normal, the end device already changed its short address by re associating with router, so if you send the packet to its old short address, it won't receive. what you can do is to keep a table to track every device in higher layer(using IEEE or some other ways), update short address associated with device once it rejoined(assuming you will enable end device announcement).

    But if you use stochastic address, I don't have that experience

    Hope it helps

    Cheers

    Rui

  • thank you ,

    i use stochastic address,if  the parent changed ,the enddevice's short adress don't change.i enabled end device announcement.

    i tracked the data ,found that the packet didn't get to the parents(the router).i think, the coordinator still take the enddevice as it's child (in fact,it's not),so the coordinator will not repeat the packet to the router.

  • 1、

    Rui Zhang69778 said:

    1. If you clear AssociatedDevList, how the coordinator knows the end device's address?

    2. Do you use polling scheme in end device? make sure end device polling cycle matches the persistence time in coordinator after restart.


    Rui


    thank you very much!

    1、the "many to one "  feature ,the coordinator will init a "rout discovery procedure" if it can't found the destination in it's AssociatedDevList.

    2、yes i used the AUTO_POLL.but what's do your mean by "matches the persistence time ",,,,,i don't use the beacon.

  • 1. so why the "many to one" fails in your case?

    2. pesistence time is the time within which the data is kept, let' see, your end device polls coordinator every 10s, but coordinator keeps the data to end device only 5s, then data will be lost

  • 1、--------------------

    3、now,send a message   to the enddevice from the coordinator.BUT the enddevice CAN'T receive the message!

    -----

    this time,in my opinion the coordinator mistook the enddevice as it's child ,so the coordinator will wait the enddevice's D_POLL instead of init the router discovery,but,the enddevice's real parent is the router,the enddevice will only send the D_POLL to the router but the coordinator,i'm not sure if i were wrong.

    ---------------------

    2、i config the polls every 1s (all as the factory set) 

  • But you said you already erase the associate table in coordinator side, so how it mistook end device as its child?

    Also I am not so sure whether stochastic addressing completely wipe out tree style parent/children relationship or it still keeps it

  • 1、yes.i said that if i didn't clear the coordinator's associate table,is it abnormal?.after i clear the coordinator's associate table,anoter problem occured:

    a、i use only two  device ,a COOD and a ED.build a link.the packet can send to the ED nomally.

    b、if i restart the coordinator ,the enddevice can't detect the link disconnect and it won't init a rejoin or resume procedure,but this time,the COOD's associate table is clear,so it can't find the destination ,……the ED can't receive the packet again.

  • thank you for your patient answer ,but it's too late now,i have to go to sleep know ,see you tommorrow

  • As your problem, the end device did rejoin router, so it should not poll coordinator anymore,right?

  • Greetings to all.  Sorry if I was posting in wrong place. I was interested in learning how to trace the packet as you did.  Unfortunately I did not found any related zstack documentation. Could you please guide me on this?  Thanks in advance.

  • no,i think the end device joined another router,but the pre-router saved the association of the enddevice and didn't update(clear it).

  • i have the same problem too, and I don't enable the nv_restore.

    in my opinion, the route should rejoin the coordiantor after the CO reset. but from the log, the route do anything after the CO reset. 

    the end device will konw the coordiantor die and try to rejoin.

    if the route try to rejoin and success, the communication between ED and CO will be ok.

    but it seems that the zstack not have this feature.

  • i'm confused about that the ED join the route. the route can not establish one network, what the ED will join?

  • Peter Yin said:

    i'm confused about that the ED join the route. the route can not establish one network, what the ED will join?

    a router can keep the network which established by the COOR,more,the NVrestore is enable ,the device will try restore the pre-network if it's restarted.

  • oh, my god, it is.

    I set the ZDAPP_CONFIG_PAN_ID=0x1234, and at first the ZR join the Pan, but after the Co reset, the Co establish one network that PanId is 0x1235, for the route keep the network that PanId is 0x1234,

    that is to say, if there is any route in the network, I must enalbe the NV_RESTORE. Oh,  There is some issue for me.

    Do you know can we disable this feature? I think it is not very useful.

    thanks for your reply.

  • In your former figure, only one router is there, right?

    If you have two routers,  the pre router can not reach end device and it will broadcast RREQ, the current router will response, new routes established

    if you enable end device annoucement, it could eliminate itself(coordinator knows the current path by receiving end device annouce)

    However, I agree there are some pitfalls

    Rui

  • 1、yes,only one router.yestoday,i did some more test,that time ,i use two router,one enddevice ,and a cood,if i use endeviceZStack-CC2530-2.5.1a.---------zigbee-pro(define -DZIGBEEPRO in f8wConfig.cfg,change the include libs,enable the nvstore,nothing else changed!),in a well network:do change as follows:

                cood                                                                                                           cood

       /                   \                                                                                                   /                    \

    router1        router2                 =====reset router1=======》  router1         router2

       |                                                                                                                                           |

    endevice                                                                                                                         endevice

    the cood's packets can't reach the enddevice some times after the change happened.

    if i use endeviceZStack-CC2530-2.5.1a.---------zigbee(not define -DZIGBEEPRO in f8wConfig.cfg,change the include libs,enable the nvstore,nothing else changed!),in a well network:do change as above,everything works well.

    ========================= 

    i think the pre router can't judge if the packet can reach the enddevice or not.do the PREQ has something with the Enddevice (which is always a sleep device)?

    i don't know why the cood didn't clear the old path,but the problem did exist. could you test it?

  • Peter Yin said:

    Do you know can we disable this feature? I think it is not very useful.

    sorry! i click a wrong place.--------------------.

    there is someway to disable it ,change some code which can fixed the PANID, it will be never changed

  • En, hope some TI guys can answer, The key problem is:

    If end device is removed and re associate some other routers, the old parent router still keeps the end device information and the old routes keep, how to detect ?

    checking the code, the indirect Tx will only expire, not forcing a route error.

  • Rui Zhang69778 said:

    En, hope some TI guys can answer, The key problem is:

    If end device is removed and re associate some other routers, the old parent router still keeps the end device information and the old routes keep, how to detect ?

    checking the code, the indirect Tx will only expire, not forcing a route error.

    absolutely right!

  • Guanqiang Chen said:

    1、yes,only one router.yestoday,i did some more test,that time ,i use two router,one enddevice ,and a cood,if i use endeviceZStack-CC2530-2.5.1a.---------zigbee-pro(define -DZIGBEEPRO in f8wConfig.cfg,change the include libs,enable the nvstore,nothing else changed!),in a well network:do change as follows:

                cood                                                                                                           cood

       /                   \                                                                                                   /                    \

    router1        router2                 =====reset router1=======》  router1         router2

       |                                                                                                                                           |

    endevice                                                                                                                         endevice

    the cood's packets can't reach the enddevice some times after the change happened.

    if i use endeviceZStack-CC2530-2.5.1a.---------zigbee(not define -DZIGBEEPRO in f8wConfig.cfg,change the include libs,enable the nvstore,nothing else changed!),in a well network:do change as above,everything works well.

    ========================= 

    i think the pre router can't judge if the packet can reach the enddevice or not.do the PREQ has something with the Enddevice (which is always a sleep device)?

    i don't know why the cood didn't clear the old path,but the problem did exist. could you test it?

    Hi chen,

    did you only change the end device's software? 

    in my test, only change the route's software that disable the zigbeepro, the communication is ok, but the route's function that relay frame disappeared.