• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 750 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.

CC2652P: ZNP: can’t control the zigbee light

victor xu
Prodigy 90 points
Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK

Chip :CC2652P1F

SDK: CC13x2 / 26x2 SDK

Demo:ZNP

Step:

1. I use CC2652 as a ZC

2. A Zigbee light join in the zigbee network

Z-TOOL reported this warning information. Is the networking successful? And I can’t control this zigbee light yet 

Please see the screenshot below

*** WARNING ***
    Unsupported or unformatted message received.  Raw data: 
    0C 45 CA 7E 9C 53 15 85 04 00 8D 15 00 00 00 

3. Reset ZC,and start the network, We also can see the light join the network, but we still can't control it.

 

BR

Victor

  • 0
    Guru 735515 points

    Are you sure you use correct DestEndpoint? By the way, I suggest you to setup sniffer to check what exactly happens over the air.

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Hi YiKai,

    Which demo should be flashed to the 1352P-2 development board as a monitor  for sniffer log？

     

    BR

    Victor

  • 0 in reply to victor xu
    Guru 735515 points

    I suppose you can use sniffer_fw.hex under C:\Program Files (x86)\Texas Instruments\SmartRF Tools\SmartRF Packet Sniffer 2\sniffer_fw\bin\cc1352p1lp

  • 0
    TI__Guru**** 208047 points

    Hi Victor,

    You can ignore the warning, the fact that the UTIL_GET_DEVICE_INFO_RESPONSE is returned with valid information and you receive a ZDO_END_DEVICE_ANNCE_IND means the network has started successfully.  The issue most likely is that you are attempting to send a AF_DATA_REQUEST using a SrcEndpoint that you haven't registered locally.  Please show how you use AF_REGISTER and refer to the following E2E threads:

    https://e2e.ti.com/f/1/t/1010890 
    https://e2e.ti.com/f/1/t/990334 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    1. I registered it as following:

    <RX>11:29:08.1 COM9 ZDO_SIMPLE_DESC_RSP (0x4584)
    SrcAddr: 0x1C43
    Status: ZDP_SUCCESS (0x0)
    NwkAddr: 0x1C43
    Len: 0x3C
    Endpoint: 0x01
    ProfileID: 0x0104
    DeviceID: 0x0102
    DeviceVersion: 1 (0x1)
    NumInClusters: 0x10
    InClusterList: 0x0000, 0x0004, 0x0003, 0x0005, 0x000A, 0x0102, 0x000D, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300, 0x0403, 0x0405, 0x0402
    NumOutClusters: 0x0A
    OutClusterList: 0x0019, 0x000A, 0x000D, 0x0102, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300

    <TX>11:44:27.25 COM9 AF_REGISTER (0x2400)
    EndPoint: 0x01
    AppProfID: 0x0104
    AppDeviceId: 0x0102
    AppDevVer: 0x01
    LatencyReq: NO_LATENCY_REQS (0x0)
    AppNumInClusters: 0x10
    AppInClusterList: 0x0000, 0x0004, 0x0003, 0x0005, 0x000A, 0x0102, 0x000D, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300, 0x0403, 0x0405, 0x0402
    AppNumOutClusters: 0x0A
    AppOutClusterList: 0x0019, 0x000A, 0x000D, 0x0102, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300

    2. Send AF_DATA_REQUEST

    <TX>11:46:00.5 COM9 AF_DATA_REQUEST (0x2401)
    DstAddr: 0x1C43
    DestEndpoint: 0x01
    SrcEndpoint: 0x01
    ClusterID: 0x0006
    TransID: 0x00
    Options: 0x00
    Radius: 0x00
    Len: 0x03
    Data: ... (0x00, 0x00, 0x02)

    <RX>11:46:00.51 COM9 AF_DATA_REQUEST_SRSP (0x6401)
    Status: afStatus_SUCCESS (0x0)

    <RX>11:46:00.52 COM9 AF_DATA_CONFIRM (0x4480)
    Status: afStatus_SUCCESS (0x0)
    Endpoint: 0x01
    TransID: 0x00

    <RX>11:46:00.53 COM9 AF_INCOMING_MSG (0x4481)
    GroupID: 0x0000
    ClusterID: 0x0006
    SrcAddr: 0x1C43
    SrcEndpoint: 0x01
    DstEndpoint: 0x01
    WasBroadcast: 0x00
    LinkQuality: 0x81
    SecurityUse: 0x00
    Timestamp: 0x00244047
    TransSeqNumber: 0x00
    Len: 0x04
    Data: .... (0x18, 0x00, 0x04, 0x00)

    But it still can't control the zigbee light. Is there a problem with the command? 

  • +1 in reply to victor xu
    Guru 735515 points

    I think you should replace "Data: ... (0x00, 0x00, 0x02)" with "Data: ... (0x01, 0x00, 0x02)"

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Hi YiKai，

    Yes，it worked.

    I don’t have enough experience with zigbee。 Could you tell me how do you recognize that you want to modify it like this? 

    BR

    Victor

  • 0 in reply to victor xu
    Guru 735515 points

    Those payload are well defined in ZCL spec.

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Hi YiKai,

    OK，thanks！

    If I reset the system, reconnect the zigbee light. Do I need to do AF_REGISTER  again? 

    I try to reset the ZC. Looks like it needs to be resent AF_REGISTER.

  • 0 in reply to victor xu
    Guru 735515 points

    Yes, you need to do AF_REGISTER  again after reset.

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Hi YiKai，

    We use Android system to control the sending of UART data. If we integrate ZCL, is there a related lib?

    I see that znp-host-framework uses an MCU for control.

    Whether there is a corresponding reference to the Android system, we can use the related API calls.

    BR

    Victor

  • 0 in reply to victor xu
    Guru 735515 points

    For Android, I would suggest you to use Z-Stack Linux gateway reference design 

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Hi YiKai,

    If I only perform local control and don’t use gateway-related functions, is it better to use ZNP-Host-Framework?

    BR

    Victor

  • 0 in reply to victor xu
    Guru 735515 points

    I would say this depends on your own decision. If you need ZCL and use Android OS, I would suggest using Z-Stack Linux gateway reference design. Otherwise, you can use ZNP-Host-Framework.

  • 0 in reply to YiKai Chen
    Prodigy 90 points

    Got it. Thanks YiKai

    Two more questions：

    1. Reset ZC, ZED keeps on, I found that ZED cannot automatically join the network, I have to restart ZED, ZC will display device access.  Is this situation right?

    2.MT command. 

    Big-endian or little-endian

    When organizing the serial port commands, the two-byte representation（eg. DstAddr/AppProfID） should be based on big-endian or little-endian？

    <TX>03:01:37.61 COM9 AF_REGISTER (0x2400)

        AppProfID: 0x0104
        AppDeviceId: 0x0102

        AppInClusterList: 0x0000, 0x0004, 0x0003, 0x0005, 0x000A, 0x0102, 0x000D, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300, 0x0403, 0x0405, 0x0402
        AppNumOutClusters: 0x0A
        AppOutClusterList: 0x0019, 0x000A, 0x000D, 0x0102, 0x0013, 0x0006, 0x0001, 0x0406, 0x0008, 0x0300

    BR

    Victor

  • 0 in reply to victor xu
    TI__Guru**** 208047 points

    Hi Victor,

    1. TI ZED examples enter a zstack_DevState_NWK_ORPHAN state after their parent does not reply to their data polls.  Then they enter execute the BDB_COMMISSIONING_PARENT_LOST case in the application where it attempts to find and rejoin the parent using beacon requests.  It is up to the developer to determine how long this process is repeated or if the ZED should give up, factory reset, and join a new network.

    2. Fields that are multi-byte fields are transmitted Least Significant byte first (LSB).

    Regards,
    Ryan