CC2530: Problem reconnecting ED when Router/Repeater is joined

Hi Tomas,

I need the NWK key in order to decrypt the sniffer log packets.  Which Z-Stack version are you using and is the CC2530 ZC the only TI device in the network?

Regards,
Ryan

Hi Ryan, 

Sorry, my keys are what I think are the default ones (5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 and 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D).

For our prototype, I am using a Radiocraft RC2411HP which is based in the CC2530 so I am not sure about the Z-Stack version but I would suppose that it is the last one. I will have our own hardware in a few weeks with a CC2530 with the Z-Stack default firmware but at the moment I need to develop the application with this kit.

Currently, this is the only TI device in the network. The ED is a Konke magnetic and the Router is a Heiman Alarm Siren, both of them from Silicon Labs I believe.

Thanks!

Hi Tomas,

Neither of those keys are effective in decrypting the packets, you may need to capture the network formation and device joining with a sniffer in order to get the correct keys.  Based on your setup description I would assume Z-Stack 1.2.2a but it is not possible to tell for sure.  How are you interfacing with the RC2411HP device?  There are no configuration or network changes before the coordinator goes offline but it will be more difficult to debug this issue if you are unable to access any firmware.

Regards,
Ryan

Hi Ryan!

I did not make any changes in the Transport Key, this is what I see in the sniffer when the transport key massage is sent during network joining (I am also attaching the log):

And this is what I see in any massage:

I am interfacing sending commands through the USART and following TI specifications as shown in https://radiocrafts.com/uploads/CC2530ZNP%20Interface%20Specification.pdf

And for application messages, I am using mostly ZCL 

The problem is that for our application we need to use the default firmware of CC2530 and that is why accessing the firmware is not a possibility.

For what I am seeing, I guess this is some problem with the routes? It seems the sensors now sends its messages to the repeater. Is there maybe a way to send a broadcast message from the coordinator so as to tell other devices to talk to him or something like that?

Thanks!

joiningnetwork.7z

I apologize for the confusion, I can view the packets now.  In the 1-ed-router the ZC does not send any link status messages after packet 35 (13:23:14) so it is off for the duration of the sniffer.  In 2-reconnect-fail I can only assume that the ZC has not updated its routing table with the new route since the ZC's Link Status outgoing cost is 0 (non-existent) and it therefore has no way of requesting new route information.  But the ZR had no link to the ZC up until the ZC's Link Status shown so an elongated sniffer log may be able to explain more.  I don't know how long the ZC has been on or why the ZR is not re-broadcasting the NWK Address Request.

Regards,
Ryan

Hi! I had the coordinator ON for a few hours and the log does not change. It keeps sending the same Link Status (and the ED the same NWK Addr Req) but nothing changes.

However, I would like to say that all the devices are in a short distance (all of them in 1 meter), so it should not be necessary for the ZR to repeat the broadcast NWK Address Request, as the coordinator should be able to receive it and answer it itself, right?

Thanks!

PS: I will attach later a log of a few hours of this situation.

If the ZC Link Status is unchanged then I suppose it never tries to communicate with the ZR.  The ZR doesn't know that the ZED is close to the ZC or what other devices are in the network and should re-broadcast the NWK Addr Req regardless.  Perhaps the extended sniffer log will provide further insight.

Regards,
Ryan

Hi Ryan!

Thanks for your answers! I still don't understand why the ZC doesn't answer the NWK Addr Req.

Attached is the extended log:

From 19:48:53 until 19:49:54 is the joining of the Heiman Alarm Siren (0xF743).
Then, from 19:49:31 until 19:49:54 is the joining of the Konke magnetic sensor (0xDACD).
At 19:50:05 I turn off the ZC and tried to send a change notification from the sensor (at 19:50:10).
Then at 19:50:25 I turned on the ZC and you can see what follows...
At 19:58:36 I tried again to send a Change Notification.
And then again at 21:28:22.

The sniffer is still capturing packets, so if you need the continuation of this log please tell me.

The only things that are new (I have never seen it in last attempts) are those "Node Descriptor Request" in the sniffer. And also, through the USART I have received some messages like this "7E 05 45 C4 CD DA 01 43 F7" which are "ZDO_SRC_RTG_IND". How are these related?

Thanks!

PS: you may see some messages from device 0xF01E, please ignore them as they are from a motion sensor: it has no problem because I did not try to send a change notification while ZC was off. If I would have tried, it would have had the same behavior as the magnetic.extended.7z

I don't know why the ZC is failing to respond to the Node Descriptor Requests or send out any commands of its own.  The ZED should not be sending Node Descriptor Requests directly to the ZC when it has already rejoined through the ZR.  The only activity I see from the ZC are Link Status, MAC ACKs, and APS ACKs.  You may want to speak with the Radiocraft RC2411HP manufacturer for their thoughts as there is no control of the firmware.  Are you able to communicate with the ZR (AF_DATA_REQUEST)?  The ZDO_SRC_RTG_IND are most likely from the ZR Route Records.

Regards,
Ryan

Hi Ryan,

I can still communicate with the ZR (it is a siren and I can make it sound) but on the other hand if I send a AF_DATA_REQUEST to the ED I get an AF_DATA_CONFIRM failure response with reason ZMacTransactionExpired (0xF0).

I will try to speak with Radiocraft, however, if you think of something else, please let me know and I'll try it.

Thanks!

Hi Ryan,

This is great, I sent the ZDO_MGMT_LEAVE_REQ with my ZR short address as the first argument and MAC address of the ZED as the second argument and it worked! The ZR sent a "Leave" to the ZED and therefore then the sensor sent a Beacon Request followed by a Rejoin Request to the ZC.

However, you will understand that this may not be as practical enough if I have multiple repeaters and sensors. It would mean that I have to send (blindly) multiple ZDO_MGMT_LEAVE_REQ with all sensors MACs to all ZR, as I am not aware of which parent has each sensor chosen while the ZC was off.

Is there a way to ask the ZR its child list (or route list)? so to personalize the ZDO_MGMT_LEAVE_REQ and be more efficient.

Thanks!!

Hi Ryan!

Radiocraft informed me that the version that they use in the coordinator Is Z-Stack 2.5.1a. Would that explain the issues that I have with the coordinator - router?

And two other question:

1- Where can I find a log change of all Z-Stack version?

2- Where can I find all command that this ZNP accepts? because I have received from the coordinator more commands that the ones showed in https://radiocrafts.com/uploads/CC2530ZNP%20Interface%20Specification.pdf and I cannot find this kind of Zstack documentation in TI web.

Thanks!

Hi!

Thanks for your answers. We are developing now our own prototype with CC2530 so that brings me to my last question:

- If I buy a CC2530 to mouser or some other supplier... which Zstack would it have? is there a way to know which Zstack a specific CC2530 has? Because upgrading firmware is not a possibility at the moment so I need to know that all default firmwares in my devices works.

Thanks!

Hi Ryain,

In that case, is there a way to buy programmed CC2530 (with Zstack) directly from TI?

Thanks!

That's ok. Then I would like to ask you which firmware should I use, as our hardware design is based on the CC2530-CC2592 reference design of TI.

Thanks!!