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.

CC2538: Message sending failing with result 0xCD ( ZNwkNoRoute or afStatus_NO_ROUTE )

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.6.2, the forecourt Controller is the ZC and all of the pumps are ZR, there are no ZE devices in our system.

The reason for this that due to the layout of the gas station forecourt more distant pumps can use closer pumps to relay messages to the controller.

For sites of upto 4 or 5 pumps ( ZRs ) this works fine, and we have over a thousand sites installed like this.

However if we have ten pumps ( ZRs ) or more the zigbee network can get very unstable.

The AF_DataRequest request works fine as follows

res = AF_DataRequest( & EZApp_DstAddr,
& EZApp_epDesc ,
EZAPP_CLUSTERID,
Len ,
pMsg->Source ,
&EZApp_TransID,
AF_DISCV_ROUTE , // AF_ACK_REQUEST , AF_TX_OPTIONS_NONE
5 ) ;

However the delivery confirmation ( AF_DATA_CONFIRM_CMD ) sometimes returns a sent status ( afDataConfirm->hdr.status ) of 0xCD, which is ZNwkNoRoute or afStatus_NO_ROUTE.

It appears as the the routing tables are not always doing their job.

The MAX_RTG_ENTRIES is defined as 40.

This problem mainly occurs when sending messages from the ZC to the ZRs, but does also happen in the reverse direction.

Is there a way I can force a network discovery for the destination device and retry sending the message ?

Has anybody else had a similar problem ?

Is the Z-Stack 3.0 likely to be of any help ?

Regards Kelvin

  • Hi Kelvin,

    That stack version is quite old and there has been many bug fixes and improvements to the stack, due to this, in most of the cases is recommended to migrate to the latest version of the stack if possible.

    Are you sure that the routers are in RF proximity all the time?

    If you can provide an OTA capture log of what is happening, with details on where in the capture log the issue is happening or if you see something odd, that would allow you to receive more accurate help to solve your issue.
  • As Luis suggested, you can try to use Ubiqua Packet Analyzer to check what happens.