Rejoin to coordinator problem

Hello,

    Can you attach a packet trace of the issue?

Is the coordinator the SED's perant? If so then when the SED tries to send a data request to the coordinator while it is off it will not get a response and try to look for a new perant.

hello,

this is a packet trace of the issue:
0083.Sniff31052011.psd

We have ZC on and ZED just programmed, so it doesn't have PanID and ShortAddr.

Packets 1 > 12 ZED try to join ZC, but on zC the join is deactivate (NLME_PermitJoiningRequest( 0 );)
Packets 13 > 25  ZED connected
Packets 26 > 57 normal trafic, at the end ZED go to sleep
Packets 59 > 211 wak-e up ZED and normal trafic, at the end ZEd go to off
Packets 212 > 214 ZED in off
Packets 215 > 224  ZED in on, it rejoin with same PanID and ShortAddr.
Packets 225 > 302 normal trafic, at the end ZC go to off
Packets 303 > 320 sent by ZED with ZC in off
Packets 321 > 335 ZC in on, rejoin failed
Packets 336 > 337 ZED in off (ZC stay in on)
Packets 338 > 357 ZED in on and rejoin failed
Packets 358 ZED in off
Packets 359 > 368 ZED in on and succesful joint
Packets 369 > fine normal trafic

Packet periodically sent by ZED are sent using the function:

stat = AF_DataRequest( &dstAddr, &BncOutDescSL,
                         ZCL_CLUSTER_ID_BNC_INPUT,
                         sizeof(BouncerInput),
                         (uint8*)&BouncerInput,
                         &SampleApp_TransID,
                         AF_DISCV_ROUTE,
                         AF_DEFAULT_RADIUS );

Il ZC doesn't reply this function return ZNwkInvalidRequest.

If I use wd to reset ZED in error case, the connection restore correctly, obvously this solution is not applicable because I lost the status of the machine.

ZC is the parent of ZED, I need that ZED reconnect to this device and not to another (that usually doesn't exist).

Thak you TopCat

Maurizio Pandolfini

Maurizio,

    What is the difference between

Packets 336 > 337 ZED in off (ZC stay in on)
Packets 338 > 357 ZED in on and rejoin failed

and

Packets 358 ZED in off
Packets 359 > 368 ZED in on and successful joint

Is there any difference in what you are doing or does it just intermittently work?

You mention "If I use wd to reset ZED in error case, the connection restore correctly, obviously this solution is not applicable because I lost the status of the machine." can you explain? Can you not store all data in NV? This would also protect you against unexpected resets. When you get ZNwkInvalidRequest you could try a ZDApp_LeaveReset.

As part of the orphan rejoin procedure the ED will try to orphan, but if there is not realignment it will fall back to rejoin (so it will beacon req until it gets a beacon rsp then try to re-join if a beacon rsp from same network). The coordinator should reply to the rejoin but is not. Maybe the coordinator ignores this because it did not see the orphan indication and thinks the ED is still its child network... I'll investigate further and update you when I have more info.

One more thing, why do I see AfDataReq when the ED is not part of the network?

Hi TopCat,

Packets 336 and 337 was sent by ZC while ZED is off, this because I've powered off ZED. Then I've powered on ZED and it try to join without success (pck 338 > 357). At this point I switch off ZED again and switch it on. At this point ZED join succesful to ZC.

These are functionality tests.

I'm expecting that when I switch off and on again ZED or ZC they reconnect each other in some seconds without human intervention but this doesn't happen.

In my application there is a state machine that controls some inputs and outputs (this is completly independent from ZigBee stack), when the wd reset the device I lost any variable related with this state machine. I shoud save all variables in nv memory before force a reset and then restore them, this is possible but I don't think that it is a good solution.

There are some orphan notification:

- 216 - in this case ZC is never shutted off and ZED is just restarted

- 311 - in this case ZC is switched off and ZED try to communicate

- 340 - in this case ZC was restarted (pck 321) and ZED was restarted too (pck 338)  but there is not a realignment

- 361 - this is the second switch off/on of ZED,  the pck 361 is the relignment command from ZC, from here all in ok

Actually seems that the ZED send orphan notification when it lost communication whit ZC but this happen just one time.

I don't know if this is correct or not (I think no) but I've seen that communication restarts correctly only if there is a realignment message from ZC, and this message there is only if ZC receive an orphan notification.

I've tryed to use the NLME_OrphanJoinRequest when there is an error but the notification is done just one time.

In the ZC I have disabled the join procedure using NLME_PermitJoiningRequest( 0 );, I activate it just for 150sec using an usb command, so if ZC is switched off and on join is disabled. I've tried to leave enabled the join but the problem still exist (in any case the ZED are already jointed to the network).

Now I'll try to add the ZDApp_LeaveReset and make some tests.

About the AFDataReq.... I don't know, actually I prefer disable that these message because them are not useful for my application but I don't know how I cand do...

Hi Harry,

yes this is the next step.

Next week I'll restart from GeneriApp of 2.4.0 and verify that the issue is not present, then I'll add the code necessary to my application.

I thought something related with compiler options or a kown bug with a workaround, but probably the problem is more complex.

Thank you for your help

Maurizio

I'm having the exact same problem.  

Most situations behave normally except, if a ZED is joined to a ZC and the ZC is reset, the ZED will not rejoin that ZC, or any other ZC(if present).

Using Zstack 2.5.1a, SimpleApp.