• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 191 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CC2652P: The network creation failed after the coordinator was powered on for more than 10 minutes

CC2652P: The network creation failed after the coordinator was powered on for more than 10 minutes

senjin
Intellectual 260 points
Part Number: CC2652P
Other Parts Discussed in Thread: CC1352P, UNIFLASH, Z-STACK

Tool/software:

sdk:           simplelink_cc13xx_cc26xx_sdk_7_41_00_17

example:   \examples\rtos\CC1352P_2_LAUNCHXL\zstack\zc_sw

tools:         CCS 12.7.1.00001 

steps:

1,  Erase entire falsh with UniFlash

2,  Modify the source

3, Debug online, Set breakpoints, as shown in the figure above.  

    Open the putty tool, switch to the commission option, and press enter.

    Typically, you will receive a device status update notification that contains case zstack_DevState_DEV_ZB_COORD, which means that the zb network has been successfully created. If you wait 10 minutes after the device is powered on before creating the network, it will fail。

  • 0
    TI__Guru**** 214227 points

    Hi Senjin,

    Thank you for reporting, I've noticed similar behavior in the past as well.  It can occur regardless of the modifications noted above and is not dependent on UI usage.  There are workarounds, such as auto-starting the ZC commissioning, resetting the device on a 10-minute timeout, or resetting the device on a timeout if zstack_DevState_DEV_ZB_COORD is not observed inside of zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND after a few seconds of starting commissioning.  Regardless, this does indicate a flaw inside of Z-Stack and I am syncing with Zigbee R&D to determine the proper course of action.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    Hi Ryan,

    If I do not make the above changes, I cannot reproduce this problem.  The purpose of the above changes is to not output data through the serial port when the device status is changed, which takes time. I think the R&D team can further analyze this clue.

  • 0 in reply to senjin
    TI__Guru**** 214227 points

    It's interesting that you're observing such behavior only after applying specific changes to the application's UI.  I assume you are continuing to use SimpleLink F2 SDK v7.40 whereas I can witness similar issues without any changes to the latest v8.30 SDK.  Zigbee R&D has also confirmed the same for a ZR role after I filed an internal ticket so they are now aware that there is a bug which needs to be addressed.

    Regards,
    Ryan