Part Number: CC2652P SDK 5.20
My coordinator has been powered off for some days. But when I power on it again, It can't send any zigbee-packet, include broadcast. At AF-Data-Confirm message, I have seen "ZNwkNoRoute" when broadcast.
Part Number: CC2538 Other Parts Discussed in Thread: Z-STACK We have a product for proving wireless communications between several Petrol Pumps and a single forecourt controller for Gas Stations.
To do this we are utlizing the CC2538 with Z-Stack 2…
Hi Aries,
0xCD represents ZNwkNoRoute, which appears to be the case with the routing table empty. The missing Link Status broadcasts is also concerning. Can you provide the sniffer log and what has further debugging of the ZR determined about its current…
Hi David,
Given the mesh network capabilities and healing properties of the Zigbee protocol, it is possible for the ZC to not be directly associated with certain ZR nodes. Thus there may be no information locally available, or the routing table could…
Hi Robert,
0xCD is defined as a ZNwkNoRoute error. Hence the short address of the device is not known by the coordinator. The DstAddr of the AF_DATA_REQUEST should be the direct short address of the device without swapping bytes. A long (IEEE) address…
Hi David,
I see no issue with using ZNP firmware for a ZR role. You can use zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND to ensure that messages have been transferred or further determine the reason it failed (ZMacTransactionOverFlow, ZNwkNoRoute, ZMacNoACK…
Hi Rian
Both params in ZGlobals.c were FALSE by default uint8 zgAllowRejoins = FALSE; uint8 zgAllowRejoinsOptions = FALSE;
1.I changed them to TRUE as you suggested. The situation has not inproved drastically. These two params are used in the library…
Hi Jawad,
0xD1 is not a valid afStatus_t return but 0xCD is ZNwkNoRoute and 0xC1 is ZNwkInvalidParam. Be sure to use a short (16-bit) address for dstAddr but IEEE (64-bit) addresses for [Source/Destination]Addr. The [Src/Dst]EP and ClusterID must be…
