• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 785 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652P: ZNP Coordinator Init problem

Mark Galich
Prodigy 60 points

Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK, SYSCONFIG, UNIFLASH, CC1352P

Hi

I made my own Zigbee coordinator based on CC2652P. 

Several devices worked correctly and were deployed on the objects. Today I tried to make the next one and got some problems.

ZNP from LAUNCHXL-CC1352P-2 Z-Stack was used as an example. SDK - simplelink_cc13xx_cc26xx_sdk_6_30_00_84.

1.Command FE0126046241 [ZB_READ_CONFIGURATION]

Response FE03600001260440

What is 0x6000? I expect 0x6604. 

2.Command FE022540640003 [ZDO_STARTUP_FROM_APP]

SRSP: FE0165400024 - Status = 0x00 [OK]

ASRSP:FE0145C0098D - Status = 0x09 [Started as ZigBee Coordinator]

Right?

Next

FE034F80010200CF - Status = 0x02 - 0x01 BDB_COMMISSIONING_IN_PROGRESS

FE034F80000200CE - Status = 0x02 - 0x00 BDB_COMMISSIONING_SUCCESS

FE064180000200020701C1 [SYS_RESET_IND] - Reason = 0x00 = Power-up 

Device reload. Why? 

3.Command FE00270027 [UTIL_GET_DEVICE_INFO]

Response FE0E670000BB2FD126004B1200FEFF07000055 - Status = 0x00 - DEV_HOLD?

Why DEV_HOLD? Because of Device reload?

4.Command FE052536020000FF00EB [ZDO_MGMT_PERMIT_JOIN_REQ]

Response FE016536C290 - Status = 0xC2 - NWK_INVALID_REQUEST

Why NWK_INVALID_REQUEST? Because of Device reload?

5.Command FE00255075 [ZDO_EXT_NWK_INFO] 

Response FE186550FEFF00FEFFFEFFBB2FD126004B120000000000000000000016

FE18 6550 

Short Address = FEFF

PAN ID = 00FE

Parent Address = FFFE

Channel = 00

Why Channel==0? In SysConfig "Primary channels" = "11"

----

Very strange device behaviour. Tried to change device, reinstall SDK, rebuild the example, mass erase Flash and reprogram - the same result.

SYS_RESET_IND confuses me. I did not get it before. What is its possible reason?

Thanks

  • 0
    TI__Guru**** 220447 points

    Hi Mark,

    1. ZB_READ_CONFIGURATION is a MT_SAPI command which has been deprecated and is not supported on SimpleLink devices.

    2. Not certain for the SYS_RESET_IND but it is likely the cause of the other behavior, as the network does not appear to actually finish formation.  APP_CNF_BDB_START_COMMISSIONING is recommended in place of ZDO_STARTUP_FROM_APP

    3. DEV_HOLD means that the device did not initialize as a coordinator, 0x09, as was attempted during step 2.

    4. As the device is stated DEV_HOLD it has not formed or joined a network and thus cannot send commands over a Zigbee network.

    5. ZDO_EXT_NWK_INFO response is further confirmation that the device has not finished forming or joining a network.

    It may be possible that pre-existing flash NV memory contents is conflicting with device commissioning, in which case you can try clearing the NV through MT commands or erase all device memory in CCS/Uniflash before re-programming.  I would also recommend that you test multiple custom PCBs and consider whether there is a hardware issue involved, for example the device is not receiving enough power or has a faulty external oscillator.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 60 points

    Dear Ryan, thanks for your reply.

    Inspected HW, did not find any anomalies. Continue testing commands. Commands sequenca based on the link.

    1. Clearing NV + Reset

    >>> FE05210903000001032C // Write startup option to clear NV when reset

     <<< FE0161090069 // 0x00 = SUCCESS

     >>> FE0141000040 // Do reset to clear NV

    <<< FE064180000200020701C1 // Reset

    All right.

    2. Set Logical type + channels

    >>> FE0521098700000100AB // Write ZCD_NV_LOGICAL_TYPE to 0 which means coordinator

    <<< FE0161090069 // 0x00 = SUCCESS

    >>> FE052F0801000800002B // Set Primary channel mask to 11

    <<< FE016F080066 // 0x00 = SUCCESS

    >>> FE052F08000000000022 // Set Secondary channel to 0x0 to disable secondary channel mask <<< FE016F080066 // 0x00 = SUCCESS

    All right.

    3. Start

    >>> FE012F05042F //APP_CNF_BDB_START_COMMISSIONING

    <<< FE016F05006B // 0x00 = SUCCESS

    <<< FE034F80010204CB // Progress, Formation <<< FE0145C0088C // Stat 08

    <<< FE064180000200020701C1 // Reset?!? Why?!?

    >>> FE00270027 // UTIL_GET_DEVICE_INFO

    <<< FE0E670000BB2FD126004B1200FEFF07000055 // DEV_HOLD ?

    The same problem with Reset. Is there any idea?

  • 0 in reply to Mark Galich
    TI__Guru**** 220447 points

    If you are able to open an active debug session then you can place a breakpoint inside SysCtrlSystemReset and determine whether the code reaches this function, at which point you can review the call stack to determine the culprit.  If called by the ZDO_DEVICE_RESET event in ZDApp_event_loop then you will need to do the same debug breakpoint for ZDApp_ResetTimerStart.  You can also add SysCtrlResetSourceGet to the ZNP firmware to determine the cause of the reset.  If the hardware is similar enough then you may also be able to further test on a CC1352P LaunchPad.

    Regards,
    Ryan