This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: ZNP stability problems

Part Number: CC2652R
Other Parts Discussed in Thread: SIMPLELINK-CC13X2-26X2-SDK, Z-STACK, CC2530, LAUNCHXL-CC26X2R1

Hi,

we are starting to evaluate using a CC2652 as a zigbee coordinator with the ZNP firmware. From the first tests we are seeing some stability problems that were already reported in this thread 

I see that the thread was locked without a solution; are there updates on this issue? Was this solved with a newer version of the sdk?

Regards,

Daniele

  • If I remember correctly, this issue has been fixed in latest SDK 4.30. Which SDK version do you use?

  • Hi Daniele,

    That post was over a year and a half ago, Z-Stack has updated to a NVOCMP solution since the SIMPLELINK-CC13X2-26X2-SDK v3.40 release.  Which SDK are you using, what issues have you observed with your setup, and what system configuration changes have you made to the ZNP project?

    Regards,
    Ryan

  • Hi Ryan,

    we are using v4.30 release. We are seeing the same behaviour as reported in that post:

    • znp works fine for about 2-3 days
    • then it stops working, no response on any AF data request serial command
    • only way to resolve is to reset the chip (via SYS_RESET_REQ command)

    This is with the official znp firmware with no modification. Looking at the old post, the issue didn't seem to be connected to the NVOCMP driver, so I think that it was never fixed (also looking at the last messages on that thread).

    Regards,

    Daniele

  • Hi Daniele,

    Thank you for providing the additional details.  I need to know more about the network you are maintaining. 

    • How many nodes are directly connected to the ZNP and how many total have joined the network? 
    • Are all devices Zigbee 3.0 or are there some legacy Zigbee HA as well? 
    • Is the ZNP taking a Coordinator role in a Centralized-type network?
    • Is there any unusual device behavior worth noting during this time period (devices leaving/rejoining multiple times, end devices not polling and aging out,  routing broadcast storms, etc)? 
    • What is your host application?  How many devices are bound to the ZNP and report attributes to it?
    • Does the ZNP send any OTA messages (Link Status, responses to ZCL requests, etc.) while not responding to MT serial commands?

    If you are able to debug the device then using the TI-RTOS Object Viewer for viewing task stack activity and HEAPMGR_METRICS for monitoring heap sizes, as well as putting break points at an unsuccessful return status of AF_DataRequest will greatly aid in identifying the issue.

    Regards,
    Ryan

  • Hi Ryan,

    ZNP is a coordinator in a centralized network, there are 19 devices connected, all joined:

    • 17 routers with zstack 3.0.2 (CC2530)
    • 2 off the shelf legacy end devices with Zigbee HA

    All devices are bound and are reporting attributes to the coordinator. Occasionally some commands are sent through the znp to the devices (for example light on/off commands).

    I will keep monitoring and provide you with additional details when I have them (it takes some time to debug this and gather informations).

    Thanks for the debugging infos. Regarding this, our software that communicates with the ZNP will do a SYS_RESET_REQ during the startup procedure, do you know if we can keep the debugger connected after this or to attach it after the reset? In all my tests I need to start the debug session before our software and the reset command makes the debugger session on the IDE terminate. Is the only way to debug not to reset the znp?

    Regards,

    Daniele

  • Hello Daniele,

    This setup should be fine, if you were to increase the number of nodes then I recommend you further consider the SWRA650 stack configurations.  Are the device reporting multiple attributes, and are they analog report values or otherwise?  The debugger can remain connected during a software reset, but you can also go to the ZNP project's Debug Configurations -> Program -> Load symbols only to debug an actively running target.  If you could provide an abbreviated sniffer/gateway log immediately before/after device failure then this might also help.

    Regards,
    Ryan

  • Hi Ryan,

    thanks for the follow up.

    Unfortunately I am still having problems in order to setup the debugging session, after a software reset code composer stops the debugging session with an error and I am unable to keep the target running or to attach the debugger after that. I am using a xds100v3 debugger, is it possible that I need to change some debugger settings or that I need to connect the debugger to the target in a specific way? It seems that the debugger keeps the target reset until I start the debugging session on the ide. Have you any documentation that might be useful?

    I am also working to skip the software reset in order to avoid this problem.

    Regards,

    Daniele

  • I don't have any comments on the debugger but here is the XDS100 documents page, you may also have better results with an XDS110 from a LAUNCHXL-CC26X2R1.

    Regards,
    Ryan