End device capacity = 0

rami rosenbaum

Other Parts Discussed in Thread: Z-STACK

Hi,

My scenario: after ZC is "full" (21 ZEDs are associated to him, then next one fails) I reboot the ZC, but none of the ZEDs can rejoin.

Looking at the Superframe Specification, before and after:

Before (association success):

association permit subfield of the superframe specification = 1

Router capacity = 1

End device capacity = 1

After (association fail):

association permit subfield of the superframe specification = 0

Router capacity = 0

End device capacity = 0

I'm using ZStack-CC2530-2.3.1-1.4.0. I was advised to upgrade to 2.5.1, but is it necessary? In ZC, ZR and ZED, or only ZC is enough? I prefer not to, due to time restrains.
I just moved the ZC and ZR to ZIGBEEPRO. ZEDs are still without the ZIGBEEPRO. I prefer not to change them - will that be a problem?

I'm trying to figure out how to plat with the number of allowed ZEDs in a ZC.NWK_MAX_DEVICE_LIST in nwk_globals.h doesn't really work.

Thanks.

over 13 years ago

0 launix over 13 years ago

Expert 1835 points

Hi rami,

This issue has been fixed since Zstack 2.4.0 if I remember. This is present in a library, so you must update your coordinator and router in a last Zstack.

Launix.

0 rami rosenbaum over 13 years ago in reply to launix

Expert 1120 points

Hi launix,

Good to hear it's a Z-Stack bug. It's been driving me crazy!

I downloaded the ZStack-CC2530-2.5.1 stack and updated IAR to Embedded Workbench 6.0, 8051 - 8.10.4 (8.10.4.40412).

I build my project quickly, hoped I didn't miss any important compilation flag, etc, but the bug persisted!!!

My ZC still looses it's Coord' abilities when associating more ZEDs than he can handle.

I decrease the # of ZEDs using #define NWK_MAX_DEVICE_LIST XXX, in nwk_globals.h.

After this happens, I 'clean' the NV rami using:

        NLME_InitNV();
        NLME_SetDefaultNV();
        // clear NWK key values
        ZDSecMgrClearNVKeyValues();
        SystemReset();

What do you think?

Thanks

0 launix over 13 years ago in reply to rami rosenbaum

Expert 1835 points

Hi rami,

Maybe I didn't understand your problem.

When your coordinator is full, you can't associate anymore devices. This is normal.

If you want to associate another devices, you must leave old device.

When you reset your coordinator, if you have NV_RESTORE you will keep all association table.

Launix.

0 rami rosenbaum over 13 years ago in reply to launix

Expert 1120 points

I'll describe the problem in details:

1. My ZC is configured to accept 20 ZEDs (in nwk_globals.h, I have the following define: #define NWK_MAX_DEVICE_LIST 20).

2. I turn on my ZC

3. I turn on 20 ZEDs, 1 at a time. My ZC application receives a Device_annce for each. all ZEDs can send messages to ZC. All is well.

4. I turn on ZED # 21. My ZC application doesn't receive a Device_annce. In the Zigbee-sniffer I see a different Superframe Specification:

association permit subfield of the superframe specification = 0

Router capacity = 0

End device capacity = 0

This seems correct - ZC cannot accept any more EDs.

5. At this point all 20 ZEDs can still send messages to ZC.

6. I reboot ZC. None of the 20 ZEDs can send messages to ZC. They have all sent Orphan notifications and when trying to connect to the ZC, the ZC replays with the same problematic Superframe Specification from #4: no Coordinator capabilities.

7. At this time I have no choice but to 'clean' the NV-RAM. I do that by calling:

NLME_InitNV();
NLME_SetDefaultNV();
ZDSecMgrClearNVKeyValues();
SystemReset();

8. After 'cleaning' the NV-RAM, the ZC boots with a new PAN-ID and the ZEDs need to be rebooted as well, to loose their old PAN-ID and join the 'clean' ZC.

0 zhong ren over 13 years ago in reply to rami rosenbaum

Intellectual 500 points

ok, this is also a bug for the zstack ,and i find it on 2.3.0/

i guess ,when the assicate table is full,and if you can not to maintain it .so when your device to resume to the coordinator ,the coordinator will show no position on the table .

but i confused that ,the resume is not same with rejoin.and the position is the position for the previous device .why it can not accept the previous resume device.if you just test 19 devices .i think it is ok.because ,it always have a free position on the table.

the worst bugs for TI STACK is the unhandy table mechanism .i have do more time for this ,and ever crazy many times .but because of lack of the open code ,i just can repair it on application.

and i just see the 2.5.1 bugs fix.it seems that TI guys have repair some bugs for the table .such as the "hold on message problem" and the "no reuse of the address table problem" and i have not to test ,but i think ,TI have no ability to resolve it completely.

0 dan spacek over 13 years ago in reply to zhong ren

Prodigy 50 points

I have this same problem with the device capacity equal to 0 and devices not being able to join but was told by a TI rep via email that it is not fixed in 2.4.0 but seems to be fixed in 2.5.1? Where is the TI rep comments on this one? Come on TI let us know whats going on with this one and what work arounds may exist.

0 Cetri over 13 years ago in reply to dan spacek

TI__Genius 9325 points

Hi All,

That's a bug on Z-Stack. End devices should be able to attempt to rejoin the same parent regardless of capacity bit's value.
Following are the fixes on the end device side based on Z-Stack 2.4.0 or higher:

<ZDApp.c>

networkDesc_t* ZDApp_NwkDescListProcessing(void)
{

.
.
.

if ( pNwkDesc->chosenRouter != _NIB.nwkCoordAddress )
{
// check that network is allowing joining
if ( ZSTACK_ROUTER_BUILD )
{
if ( stackProfilePro == FALSE )
{
if ( !pNwkDesc->routerCapacity )
{
continue;
}
}
else
{
if ( !pNwkDesc->deviceCapacity )
{
continue;
}
}
}
else if ( ZSTACK_END_DEVICE_BUILD )
{
if ( !pNwkDesc->deviceCapacity )
{
continue;
}
}
}

.
.
.

}

void ZDO_beaconNotifyIndCB( NLME_beaconInd_t *pBeacon )
{

.
.
.

if ( ( (capacity) || ( pBeacon->sourceAddr == _NIB.nwkCoordAddress ) ) && (selected) )
{
// this is the new chosen router for joining...
pNwkDesc->chosenRouter = pBeacon->sourceAddr;
pNwkDesc->chosenRouterLinkQuality = pBeacon->LQI;
pNwkDesc->chosenRouterDepth = pBeacon->depth;
}

if ( pBeacon->deviceCapacity )
pNwkDesc->deviceCapacity = 1;

if ( pBeacon->routerCapacity )
pNwkDesc->routerCapacity = 1;

.
.
.

}

0 Felix Bruckmüller over 12 years ago in reply to Cetri

Intellectual 835 points

Hi,

after experiencing similar problems during development with z-Stack 2.5.1 I applied Cetris changes and ran into other problems.

During joining the device always tried to join the first network available, even if joining wasn't allowed for this network. To solve this the following changes where made over Cetris changes:

if ( pNwkDesc->chosenRouter != _NIB.nwkCoordAddress ) -->

if((pNwkDesc->chosenRouter != _NIB.nwkCoordAddress) || (_NIB.nwkCoordAddress == 0xFFFE))

Furthermore I found the second change is not accurate enough in an multinetwork environment and to solve this I changed the second change too:

if ( ( (capacity) || ( pBeacon->sourceAddr == _NIB.nwkCoordAddress ) ) && (selected) ) -->

if(((capacity) || (osal_ExtAddrEqual(ZDO_UseExtendedPANID, pBeacon->extendedPanID))) && (selected))

Until now this works a lot better for me.

Zigbee & Thread

Zigbee & Thread forum

End device capacity = 0