CC2530: No communication between End Device and Coordinator for extended period of time

Jack Loop

Part Number: CC2530
Other Parts Discussed in Thread: CC2531,

Hi,

I have been running multiple end device modules for a day, and I am testing if the end device will still be able to communicate with the coordinator after inactivity (no commands sent from coordinator to end device; i.e. on/off) for an extended period of time. I have noticed that 50% of the modules will no longer communicate with the coordinator when I test under these conditions. I verified this when I sent an on/off command to the end devices and they didn't turn on/off. I have found some possible solutions such as, "When device joins Zigbee network but security is not matched with Zigbee network..." and "This restart is usually caused by incorrect security settings." So incorrect security matching/settings may be the cause of my problem, but I am no 100% sure.

So how can I make sure the end device will always have communication with the coordinator, even under an extended period of inactivity?

If it is security, how can I "match security" / "correct security settings"?

over 7 years ago

0 JasonB over 7 years ago

TI__Expert 8950 points

Do you have a sniffer log of when you try to send the On/Off command to some of these devices?

When you say period of inactivity, do you mean that the ZED devices are turned off or outside of radio range of ZC, i.e. do the ZED devices lose their parent? If so, you will need to make sure that they are able to rejoin the network before you attempt to communicate with them. In Z3.0, ZED parent loss is a case which is handled by the ZED application (search for BDB_COMMISSIONING_PARENT_LOST in a sample app), I think that by default a ZED which has lost its parent will send out a beacon request once every 10 seconds to attempt to rejoin.

0 Jack Loop over 7 years ago in reply to JasonB

Guru 17870 points

When I say period of inactivity, I mean that I don't send any commands to my ZED modules. My ZED modules are within range of my coordinator, and so they shouldn't lose their parent.

0 JasonB over 7 years ago in reply to Jack Loop

TI__Expert 8950 points

I would use a sniffer to check to see if the ZEDs are still sending data requests to ZC at the time when you try to send the command from ZC to ZED. Do your ZED nodes have BDB_REPORTING enabled? If so, please refer to 2.3 on this wiki page:

processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes

0 Jason Cole26 over 7 years ago in reply to JasonB

Intellectual 710 points

Do your end devices implement "leave and rejoin"? It's likely that the co-ordinator will change keys, telling end devices to update.

0 YiKai Chen over 7 years ago

Guru 735685 points

What is the poll rate of your device? I agree with Jason that sniffer log is necessary to better understand your problem.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

I will have the log uploaded soon. But as for now, I have found that when I enable ZCL_LEVL_CTRL, the problem is gone. Can you explain a possible reason for this?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

Without sniffer log, I cannot judge anything.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Ignore the previous post I made. Here is the log. The issue can be seen towards the end of the log. How can I fix this?

Day Log.zip

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

Can you specify which device short address you have problem with?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

All the below stop communicating with the coordinator

ZED2 - 0x8C1D
ZED3 - 0X7BCF
ZED4 - 0X1AC4
ZED5 - 0XBE05

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

Using 0xBE05 as example, does coordinator send any command or message to 0xBE05 after packet number 102156. I see device 0xBE05 keep sending report until to the end and it seems work fine.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

No.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

So, what's your problem. Can you elaborate it with your sniffer log?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Right after the iterative, power config reports + active endpoint requests, at the end of the log, all the modules stop communicating with the coordinator then. So my question is: how can I make sure the end device will always have communication with the coordinator, even under an extended period of inactivity (meaning the coordinator doesn't send any on/off commands)?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

What is your coordinator? Do you turn off your devices after packet number 111378?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

My coordinator is 0x0000. I don't turn off any of my devices. I left them untouched for a whole day.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

I know coordinator has short address 0x0000. I mean where is coordinator from. Is it based on TI example?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

It is Smartthings.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

If you use TI's coordinator, do you see this issue?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Yes. The logs have same results with the Smartthings coordinator.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

Do you apply fix of "Soft Reset/Freezing/Stack Overflow due to BDB_REPORTING on CC2530/CC2531" in processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes to test again?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Yes.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

I suggest you connect debugger to test again and check where the device get stuck.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Can you explain the iterative power config reporting + active endpoint requests at the end? What happened here?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

I think you should check you device code to see why your end device keeps doing reporting and active endpoint requests. The strange thing is that your SmartThings hub deosn't response to active endpotint request which is incorrect behavior.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

If you add a filter of "lenth is 48", you can see that the Smartthings hub does respond to active endpoint requests. That is....until the very end, where my ZED devices go crazy. I am not sure why this is. I will attach my code soon, so you can look and see what is wrong with it.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735685 points

If you use original SampleSwitch example, do you still see the same issue?

Zigbee & Thread

Zigbee & Thread forum

CC2530: No communication between End Device and Coordinator for extended period of time