CC2652R: cc2652 ZED device losses connection after paired to cc2538 coordinator.

What SDK version and example do you run on CC2652R? When this issue happens, all application on CC2652R is dead or only RF part?

Hi YK,

1. SDK 3.10 for ZEd

2. Only the RF, because button can work. By right, it shuld be rejoining but not.

Regards,

Walter

I had seen similar issue on old SDK. I would suggest you to try latest SDK 3.30.

Hi YK,

1. Sure, SDK 3.10? Any description of the phenomenon? 

2. Is TI can confirm this issue?

Regards,

Walter

Actually, I see similar issue on SDK 2.40 and rev.C chip. I am not sure if your case is the same to me. I can only suggest you to try latest SDK to see if you still see this trouble.

Im  using RevE and SDK 3.10.

Any response from TI? 

You might need to provide complete sniffer log to TI to help on this issue.

Hi,

I don't recall any issues related to what you've reported on the 3.10 SDK.

A sniffer log could be useful.

Some debug points:

• Since this sounds like a memory leak, try to monitor the heap usage. 
• When you say that the "button can work", do you mean that when this issue is present, the device enters the function to process the button press?
• When this issue is present, what value do you see for devState ?

How would you expect the ZC to detect connection loss?
Note that the default aging timeout END_DEV_TIMEOUT_VALUE is 8 (256 minutes). If the ZC ages out a child, then it will queue a Leave Request for that child. However, if this child does not poll, then you won't see any Leave Requests over-the-air.

Regards,
Toby

Hi Toby,

When you say that the "button can work", do you mean that when this issue is present, the device enters the function to process the button press?

- Correct

This device has poll rate of 500ms.

Regards,

Walter

Please provide answers/feedback to my other points.

Additionally, does the issue remain if you reset the device?

Hi Toby,

Here is the update:

We connected the coordinator CC2538(zstack3.0.2 ) and CC2652 ZEDs (SDK3.10) for a couple of days.
It was working initially. Adding ZEDs, sending report, re-join.

1. After about 2 days, the power cycle hub but the the ZEDs did not notice disconnection (By right, ZEDs should be re-joining(blinking LEDs like the original code)). But the ZEDs is not hang because it can control manually IO to drive an led.

2. If we power cycle the ZEDs, still not re-joining to coordinator. Not re-joining.

I attached the sniffer logs.

Network key: d4:21:5f:b8:b9:72:b1:45:37:93:d7:cd:9f:35:29:77

Thanks

Regards,

Walter

Hi 

It seems we are getting the leave request from hub and leave response success. What is the purpose of this?

Regards,

Walter

I cannot access the file sharing site; can you attach the sniffer log directly?

Do you see the same issue if you power cycle the hub before 2 days has passed?

If the ZC power cycles while the ZED is on the network, then the ZED should detect this pretty quickly... after all, while the ZC is powered off, it would not be able to ACK the ZED's data requests. Then when the ZC is on, the ZED may rejoin (ZED will attempt the rejoin every SAMPLEAPP_END_DEVICE_REJOIN_DELAY ms).

Can you try adding a non-modified ZED (CC2652) to the network and re-test? You may continue to use the modified ZEDs on the other CC2652 devices.

Toby I can download Walter's log. I zip it and attach it for you.

sniffer log after coordinator power cycle.zip

Hi Toby,

We are almost going production but this issue is blocking us. Need expert advice on this issue.

1. We know already the original sample code is not dropping.

2. The application code where I put poll rate to zero is not dropping too.

3. The application code where it is dropping, the poll rate changed to 500ms from 1000ms. Is this an issue of aging out?

https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/725702?tisearch=e2e-sitesearch&keymatch=leave%20request#pi320995=2

Regards,

Walter

Based on this description, we can focus debug effort on the ZC side:
Since POLL_RATE of original sample code is 1000ms, and your code works with 1000ms, 1., 2., and 3. indicate that it could be the faster poll rate (500 ms) that is causing this. Is there a reason you need to poll this frequently?

Can you describe what changes you've made to the ZC?

From the sniffer log, the Parent Annce messages sent by the ZC indicate that the children the ZC keeps track of is not consistent.
Can you try increasing heap/stack, and nwk buffer sizes on the ZC? You can refer to how this is done in https://processors.wiki.ti.com/index.php/Zigbee_Known_Issues_and_Proposed_Fixes 

Also, since the ZED had received a Mgmt Leave Request, the ZED would've cleared its NV. In this case, after restarting the ZED (eg. power cycle, reset), it would act as a factory new device; try to trigger commissioning on the ZED to join the network again.

Hi Toby,

I want to mention ZED application with re-join issue changes:

1. Poll rate from 1000 to 500ms

2.SAMPLEAPP_END_DEVICE_REJOIN_DELAY from 10000 to 1000. Do  you think this one will cause this problem also or only the poll rate?

Regards,

Walter

Hi Toby Pan

The ZC coordinator configuration changes 1.DNWK_INDIRECT_MSG_TIMEOUT=70(default value=7).

                                                                     2. channel from 11 to 26.

                                                                    3.change the ZC Network capacity(no router)NWK_MAX_DEVICE_LIST=79 and BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE=FALSE;

                                                                    default value: NWK_MAX_DEVICE_LIST=20 and BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE=TRUE(bdb_interface.h);

Thanks for sharing this.

The only number I think could cause the issue is NWK_MAX_DEVICE_LIST.
Since you see these symptoms after a power cycle of the ZC, please see this related post (issue after power cycle when large number of devices is required): https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/846699/3138548#pi320995=1
It offered the solution of increasing the NV area.

Hi Toby Pan

Thanks for your reply,our zigbee system(Coordinator and end device ,no router),and Walter test end device just 1 or 2 even less than 10 devices.

This is a problem when the a number of end device run on the same time,But this is not this post  key,

OK, This is a potential issue.Base our system(Coordinator and end device ,no router),I think the zigbee network contain 80 devices.

So,I can modify these parameters what specific value to use. 

Thanks!

this issue post are going,if you had other suggestion,guide me,Thanks!

Please try the values as outlined in the link I mentioned before.
https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/746836/2799808#2799808

For convenience, I've copied it below. Try it while keeping NWK_MAX_DEVICE_LIST == 79.

The issue is resolved for CC253x devices once increasing HAL_NV_PAGE_CNT to 12 and OSAL_NV_PHY_PER_PG to 2 as well as modifying NV_MEM and FLASH in the CC2538.icf:

FLASH = mem:[from 0x00200000 to 0x002797FF];
NV_MEM = mem:[from 0x00279800 to 0x0027F7FF];

Another helpful thing to do is to change NWK_MAX_DEVICE_LIST back to the default value (20), and see if the issue you see stops. This would give us some information on whether the issue is related to this macro.

Thanks for Toby Pan reply,I have set it:1.define region SRAM = mem:[from 0x20000000 to 0x20007FFF]; 

      2 in the linker file (Z-Stack 3.0.2\Projects\zstack\HomeAutomation\GenericApp\CC2538\Coordinator\List         GenericApp.map).

"A0": place at start of [0x00200000-0x0027c7ff] { ro section .intvec };

"A1": place at start of [0x0027ffd4-0x0027ffdf] { ro section .cca };
"P1": place in [from 0x00200000 to 0x0027c7ff] { ro };
"A9": place at start of [0x20004000-0x20007fff] { section VTABLE };
define block HEAP with size = 256, alignment = 8 { };
"P2": place in [from 0x20004000 to 0x20007fff] { rw, block HEAP };
do not initialize { section .noinit };
place at end of SRAM { section .noinit };
initialize by copy { rw };

 3.NWK_MAX_DEVICE_LIST =79;

 4.ZDSECMGR_TC_DEVICE_MAX=80;

5.bdbTrustCenterRequireKeyExchange=FALSE;

6.HAL_NV_PAGE_CNT = 12 ;OSAL_NV_PHY_PER_PG =2;

7. FLASH = mem:[from 0x00200000 to 0x002797FF];
   NV_MEM = mem:[from 0x00279800 to 0x0027F7FF];

result:bulid successfully.

Have a question:what SRAM and FLASH are the respective uses and storage. 

I can learn more detail,

Thanks!

Hi Toby,

Child Device Management Child management is a procedure for which parent devices must now age out neighbor table entries for unresponsive end device children by a pre-configured default timeout. This aging timeout can be changed per end device upon request from that end device using the End Device Timeout Request command. MAC data polls are sent from a child end device to reset the parent's aging counter. But once the timeout value is exceeded and the child is aged out, the parent will send the device a Leave Request with the rejoin attribute set so that the device may be allowed to rejoin the network through a new parent device.

We changed the config to original values as zed sdk 3.10.

But our sniffer log says leave request from ZC with rejoin false.

Leave Request.docx

Correct, and this is exactly the aging behavior seen on the unmodified examples.

Reverting the ZED to default will not directly affect the ZC's configuration of the leave request; in other words, some changes should be made on the CC2538 ZC. Can you confirm that this issue only happens if you reset the ZC?

Have you already increased the size of NV? (post I mentioned before: )

Have you followed Ryan's suggestions in the post he referred to? 

Hi Toby,

By right it should be rejoin true so ZED can rejoin back coordinator.

But, our experience is rejoin false, that s why completely removed. 

Regards,

Walter

Hi Walter 

the CC2538 had just support 40 devices, you can expand it post above.

Thanks!

userjiabo Walter's issue is about ZED cannot rejoin network. Not much related to max number of devices.

These two issues that are discussed in this thread could be related:
1. Join more devices to the ZC
2. ZED unable to rejoin ZC after ZC power cycles (due to Rejoin bit set to false)

To join more devices to the ZC, you've increased NWK_MAX_DEVICE_LIST.
--> In addition to this, you should also consider increasing the NV memory region.

In the post I've mentioned before, there have been cases in the past where, after modifying the ZC to join a large number of devices, resetting this ZC resulted in strange behavior (eg. PANID changed after each reset). This issue was resolved by increasing the NV memory region.
I'm not sure if you're already implemented the increase to the NV region, but doing so may resolve the issue. Can you confirm whether or not you have inreased the NV memory region?