CC2530ZNP Mini Kit SimpleApplication router Bug

I found the same issue, any idea how to resolve this? router is not routing msj!!!!

Thanks

hey rico,

i have found a quick fix for this. remove the junks inside main and just let the device boot up as a router.

regards,

ted.

Hello Ted,

Thanks for pointing this out. In simple application every time a device sends a message it waits for AF_DATA_CONFIRM from ZNP. But during this time if a new device joins a network it sends a device announce message (with command value = 0x45C1) . This message is sent as callback to the application processor which all devices in the network recieve while polling (waiting) for AF_DATA_CONFIRM but instead receives device announce and assumes the link is lost and retries to join the network. When this device joins the network again it in the same way kicks out the other device and problem loops. To solve this can you try adding the following code in the while loop marked in the code in the waitForMessage() function in the znp_interface.c file. This ignores the callback message if it is a device announce. Thanks 

Regards,

Suyash Jain

Hello,

   I wrote the examples to be simple (arguable too simple) and you're correct, this does cause a problem. I use the ZNP in a number of projects, but I don't use waitForMessage() since that ties up the processor while waiting. What I do when sending a message is this:

1) send the message using afSendData, modified slightly so that the method returns right after the call to sendMessage() and if znpResult == 0 then it returns the transactionId. This is important because it allows you to match up the AF_DATA_CONFIRM messages.

2) Start a background timer

3) When an AF_DATA_CONFIRM is received, if it has a transactionId that matches the one you sent, then all is ok. If the transactionId doesn't match then there's a problem. Also, if the timer expires and you don't ever receive an AF_DATA_CONFIRM then there's a problem.

Now here's a kicker: there's a ZNP firmware bug with AF_DATA_REQUEST: if you send a message with a payload longer than 85B or so then the transactionId will always return zero. (The bug has been reported to TI for analysis) So that prevents you from doing the transactionId matching if you're using longer messages.

Cheers,

Derek

Hi,

    The problem of reconnection after 2 messages  from the end device has been eliminated by the following code change in router.

The destination address of afSendData (3rd parameter) has been made as 0xFFFC (ALL_ROUTERS_AND_COORDINATORS ) instead of 0.

  afSendData(DEFAULT_ENDPOINT,DEFAULT_ENDPOINT,0xFFFC, INFO_MESSAGE_CLUSTER, msgBuf, getSizeOfInfoMessage(&im));

This solves the end device and router  reconnection problem.

Thanks 

Ram

Even better use this code (ignores all messages sent out to the network that it's not waiting for, which is probably AF_DATA_CONFIRM but could be something else...) The following code is just replacing what's in the red box in Suyash Jain's message.

while( CONVERT_TO_INT(znpBuf[2], znpBuf[1]) != messageType ) {

//end device announce received before ACK
while( SRDY_IS_HIGH() && (counter != timeout) ) {
counter++;
}
if(counter == timeout;) {
return -21;
}
spiPoll();
}