CC2652R: CC2652R ZNP stability problems

Correct link: https://drive.google.com/open?id=1dllSbfp10KryB35pkywuVnogzKmQ9ZZS

Thank you for following up but this will still be hard to reproduce.  Are you still using SIMPLELINK-CC13X2-26X2-SDK v3.10 to witness this behavior?  Do you believe the number or type of connected devices affects the issue?  If I were to send AF data requests continuously from the out-of-box ZNP project do you think I would be able to observe the problem?

Regards,
Ryan

I'm using simplelink_cc13x2_26x2_sdk_3_10_00_53 and believe that the number of devices doesn't matter.

I'm guessing that it has something to do with Xiaomi devices.

To make this easier to reproduce for you, could you provide met a ZNP firmware for the CC2652R (then we are sure we are testing against the same firmware)?

I will then try to reproduce the issue with just only the Xiaomi device in the network.

Why the Xiaomi device?  Is there a specific way in which their OTA communication is different?  Please try to replicate the issue both with and without these devices.  The default ZNP is provided with the other Zigbee examples in the SDK.

Regards,
Ryan

My previous belief that this issue only appears with Xiaomi devices was wrong. I'm now able to replicate it with both a Xiaomi ZNCZ02LM and an IKEA TRADFRI E1603.

Here is a link to a zip file containing the firmware and logs: https://drive.google.com/open?id=1d7k3SYxBfK0ExYl4v_xXHkHe9NO40gPZ 

- The firmware is the out of the box simplelink_cc13x2_26x2_sdk_3_10_00_53 ZNP example

- The AF_DATA_REQUEST are send with an interval of 1 second (I used an auto clicker for this)

- Please also pay attention to the parameters I used for the AF_DATA_REQUEST (can be found in the logs)

When you are not able to reproduce this, could you provide me the logs and the used firmware? (.hex file)

You register the 0x01 source endpoint with AF_REGISTER in Z-Tool, correct?  Otherwise you will get a ZStatus fail message when attempting AF_DATA_REQUEST.  I created a script to automate this test.  First you have to commission the network (APP_CNF_BDB_SET_CHANNEL and APP_CNF_BDB_START_COMMISSIONING) as well as change the shortAddress and comPort variables in the script, after running it will register the endpoint and begin sending Read Attributes (based on the data settings provided).  I used a custom clusterID instead of the General Basic (0x0000) defined by the ZCL.  I also increment the TransID regularly and connect a zr_sw to test with.  Please review and evaluate my setup and let me know if you would expect me to encounter the issue.  I will try to run the test overnight.  znp_test.zjs

Regards,
Ryan

I was able to replicate the behavior after five hours of testing and will work with the Software Development Team to discover the root cause and find a valid workaround.

Regards,
Ryan

Great!!

Thanks for the fast response and fix! I'm currently testing it, will keep you up-to-date.

After 7 days it is still stable (even with zigbee2mqtt) so this seems to fix the problem.

Off topic: are there any updates about the NVOCTP driver issue?

Great to hear, thanks for testing out the fix, we will be sure to include it in our next release.

If you are referring to the NV size limitation of NVOCTP, we are addressing this in the next release as well.

Jason,

When you say next release, do you mean Q3 or Q4? 

We plan to have both of these fixes in the Q3 release.

Great! 

One last question, how can I determine how much memory is left?

I want to scale the device tables as big as possible, it seems that the memory allocation viewer in CCS always shows 100% for flash_nv