• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 348 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.

CC2530: Z-Stack 3.0.2 / Linux Gateway does not find IEEE address for new device / TI ZED Issue (?)

Mario DW
Genius 3145 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Summary

1. The Linux Gateway is failing on this query, apparently because it does not find the IEEE Address, which is strange because the Gateway was up and running for a while already without any devices associated to it.  It is failing for a newly associated device!

Question:

- What can be done to make the Linux Gateway's work for this case.

Detail

I am developing an End Device and carefully checking that it is correctly implemented.

I noticed during the association process that the End Devices sends an "Identify Query" to the Coordinator without a payload.

The End Device sends a Identify Command, apparently during its BDB procedure:

ZStatus_t bdb_SendIdentifyQuery( uint8 endpoint )

Which send a query to the Broadcast Endpoint 0xFF, which is exactly what is sniffed:

ZigBee Application Support Layer Data, Dst Endpt: 255, Src Endpt: 1
    Frame Control Field: Data (0x08)
        .... ..00 = Frame Type: Data (0x0)
        .... 10.. = Delivery Mode: Broadcast (0x2)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Destination Endpoint: 255
    Cluster: Identify (0x0003)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 6
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x11)
        .... ..01 = Frame Type: Cluster-specific (0x1)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...1 .... = Disable Default Response: True
    Sequence Number: 1
    Command: Identify Query (0x01)

This command is time-correlated to the next messages in the Linux Gateway Log that reports that the command fails because the IEEE Address is not found for this newly (!) associated device:

[2020-10-16 21:17:09] [21:17:06.835,127] [Z_STACK/HNDL] INFO   : [DBG] Clearing                 @ 0xB6A00678 (processed 36 messages)...
[2020-10-16 21:17:09] [21:17:06.835,156] [Z_STACK/HNDL] INFO   : [MUTEX] Wait for AREQ semaphore
[2020-10-16 21:17:09] [21:17:06.835,390] [Z_STACK/MAIN] INFO   : ...sent 60 bytes to Client
[2020-10-16 21:17:09] [21:17:06.835,604] [GATEWAY/READ] INFO   : Received 56 bytes, subSys 0x51, cmdId 0x92
[2020-10-16 21:17:10] [21:17:06.835,688] [GATEWAY/READ] INFO   : RPC_CMD_AREQ cmdId: 0x92
[2020-10-16 21:17:10] [21:17:06.835,716] [GATEWAY/READ] INFO   : [DBG] Allocated        @ 0xB6A00560 (received  9 messages)...
[2020-10-16 21:17:10] [21:17:06.835,742] [GATEWAY/READ] INFO   : Filling new message (@ 0xB6A00560)...
[2020-10-16 21:17:10] [21:17:06.835,804] [GATEWAY/HNDL] INFO   : [MUTEX] Mutex for AREQ unlocked
[2020-10-16 21:17:10] [21:17:06.835,845] [GATEWAY/HNDL] INFO   : [DBG] Processing       @ 0xB6A00560
[2020-10-16 21:17:10] [21:17:06.835,872] [GATEWAY/HNDL] INFO   : [MUTEX] AREQ Calling asynchMsgCback (Handle)...
[2020-10-16 21:17:10] [21:17:06.835,897] [GATEWAY/HNDL] INFO   : [DBG] asyncCB: subSys:0x00000011, cmdId:0x00000092, len:0x00000038, pData:0xB6A00568
[2020-10-16 21:17:10] [21:17:06.836,048] [GATEWAY/HNDL] MISC1  : Processing Af Incoming Message Indication
[2020-10-16 21:17:10] [21:17:06.836,111] [GATEWAY/HNDL] DEBUG  : isEndpointClusterExistOnGw(1, 0x0003, ClientToServer)
[2020-10-16 21:17:10] [21:17:06.836,145] [GATEWAY/HNDL] DEBUG  : isEndpointClusterExistOnGw(): EP/Cluster Found
[2020-10-16 21:17:10] [21:17:06.836,170] [GATEWAY/HNDL] DEBUG  : zcl_HdlIncoming: Processing abstracted ZCL command
[2020-10-16 21:17:10] [21:17:06.836,196] [GATEWAY/HNDL] DEBUG  : zcl_HdlIncoming: Processing generic ZCL command
[2020-10-16 21:17:10] [21:17:06.842,796] [GATEWAY/HNDL] INFO   : preparing to send 6 bytes, subSys 0x19, cmdId 0x00, pData:
[2020-10-16 21:17:10] [21:17:06.842,936] [GATEWAY/HNDL] INFO   : [MUTEX] Lock SRSP Transaction Mutex
[2020-10-16 21:17:10] [21:17:06.843,017] [GATEWAY/HNDL] PKT_HEX: [                           NWK_MGR<<GATEWAY         ] [SREQ] 06:00:39:00:08:00:10:E6:CD:02
[2020-10-16 21:17:10] [21:17:06.843,132] [GATEWAY/HNDL] PKTTYPE: [                           NWK_MGR<<GATEWAY         ] SrvrGetIeeeAddressReq
[2020-10-16 21:17:10] [21:17:06.843,194] [GATEWAY/HNDL] PKTBODY:                                                          cmdId = SRVR_GET_IEEE_ADDRESS_REQ
[2020-10-16 21:17:10] [21:17:06.843,233] [GATEWAY/HNDL] PKTBODY:                                                          shortAddress = 0x0000A6E6 (42726)
[2020-10-16 21:17:10] [21:17:06.843,482] [GATEWAY/HNDL] INFO   : Waiting for synchronous response...
[2020-10-16 21:17:10] [21:17:06.843,526] [GATEWAY/HNDL] INFO   : [MUTEX] Lock SRSP Mutex
[2020-10-16 21:17:10] [21:17:06.843,554] [GATEWAY/HNDL] INFO   : [MUTEX] Wait for SRSP Cond signal...
[2020-10-16 21:17:10] [21:17:06.844,578] [NWK_MGR/LSTN] INFO   : Receive message...
[2020-10-16 21:17:10] [21:17:06.844,744] [NWK_MGR/LSTN] MISC1  :
[2020-10-16 21:17:10] SRVR_GET_IEEE_ADDRESS_REQ: shortAddr: A6E6
[2020-10-16 21:17:10] [21:17:06.844,962] [NWK_MGR/LSTN] PKT_HEX: [                           NWK_MGR>>GATEWAY         ] [ucst] 0D:00:79:01:08:01:10:01:19:00:00:00:0
[2020-10-16 21:17:10] [21:17:06.845,021] [NWK_MGR/LSTN] PKTTYPE: [                           NWK_MGR>>GATEWAY         ] SrvrGetIeeeAddressCnf
[2020-10-16 21:17:10] [21:17:06.845,070] [NWK_MGR/LSTN] PKTBODY:                                                          cmdId = SRVR_GET_IEEE_ADDRESS_CNF
[2020-10-16 21:17:10] [21:17:06.845,109] [NWK_MGR/LSTN] PKTBODY:                                                          status = STATUS_FAILURE
[2020-10-16 21:17:10] [21:17:06.845,147] [NWK_MGR/LSTN] PKTBODY:                                                          ieeeAddress = 00:00:00:00:00:00:00:00
[2020-10-16 21:17:10] [21:17:06.845,305] [NWK_MGR/LSTN] INFO   : ...sent 17 bytes to Client
[2020-10-16 21:17:10] [21:17:06.845,356] [NWK_MGR/LSTN] INFO   : !Done
[2020-10-16 21:17:10] [21:17:06.845,583] [GATEWAY/READ] INFO   : Received 13 bytes, subSys 0x79, cmdId 0x01
[2020-10-16 21:17:10] [21:17:06.845,665] [GATEWAY/READ] INFO   : [MUTEX] SRSP Cond signal set
[2020-10-16 21:17:10] [21:17:06.845,692] [GATEWAY/READ] INFO   : Client Read: (len 17):
[2020-10-16 21:17:10] [21:17:06.846,799] [GATEWAY/HNDL] INFO   : [MUTEX] Unlock SRSP Mutex
[2020-10-16 21:17:10] [21:17:06.846,902] [GATEWAY/HNDL] MISC1  :
[2020-10-16 21:17:10] P2P: Get IEEE Address Failed, status: 1
[2020-10-16 21:17:10] [21:17:06.846,975] [GATEWAY/HNDL] MISC1  : ZCL Process Message Failed, Message Status: 8
[2020-10-16 21:17:10] [21:17:06.847,018] [GATEWAY/HNDL] INFO   : [MUTEX] AREQ (Handle) (message @ 0xB6A00560)...
[2020-10-16 21:17:10] [21:17:06.847,048] [GATEWAY/HNDL] INFO   : [DBG] Clearing                 @ 0xB6A00560 (processed 9 messages)...
[2020-10-16 21:17:10] [21:17:06.847,080] [GATEWAY/HNDL] INFO   : [MUTEX] Wait for AREQ semaphore
[2020-10-16 21:17:10] [21:17:06.840,635] [OTASRVR/READ] INFO   : Received 51 bytes, subSys 0x51, cmdId 0x92
[2020-10-16 21:17:10] [21:17:06.850,220] [OTASRVR/READ] INFO   : RPC_CMD_AREQ cmdId: 0x92
[2020-10-16 21:17:10] [21:17:06.850,276] [OTASRVR/READ] INFO   : [DBG] Allocated        @ 0xB6B004B0 (received  1 messages)...
[2020-10-16 21:17:10] [21:17:06.850,305] [OTASRVR/READ] INFO   : Filling new message (@ 0xB6B004B0)...
[2020-10-16 21:17:10] [21:17:06.850,408] [OTASRVR/HNDL] INFO   : [MUTEX] Mutex for AREQ unlocked
[2020-10-16 21:17:10] [21:17:06.850,457] [OTASRVR/HNDL] INFO   : [DBG] Processing       @ 0xB6B004B0
[2020-10-16 21:17:10] [21:17:06.850,484] [OTASRVR/HNDL] INFO   : [MUTEX] AREQ Calling asynchMsgCback (Handle)...
[2020-10-16 21:17:10] [21:17:06.850,510] [OTASRVR/HNDL] INFO   : [DBG] asyncCB: subSys:0x00000011, cmdId:0x00000092, len:0x00000033, pData:0xB6B004B8
[2020-10-16 21:17:10] [21:17:06.856,803] [OTASRVR/HNDL] INFO   : [MUTEX] AREQ (Handle) (message @ 0xB6B004B0)...
[2020-10-16 21:17:10] [21:17:06.856,938] [OTASRVR/HNDL] INFO   : [DBG] Clearing                 @ 0xB6B004B0 (processed 1 messages)...
[2020-10-16 21:17:10] [21:17:06.856,975] [OTASRVR/HNDL] INFO   : [MUTEX] Wait for AREQ semaphore
[2020-10-16 21:17:10] [21:17:06.960,394] [Z_STACK/READ] INFO   : Received 14 bytes, subSys 0x45, cmdId 0xFF
[2020-10-16 21:17:10] [21:17:06.960,562] [Z_STACK/READ] INFO   : RPC_CMD_AREQ cmdId: 0xFF
[2020-10-16 21:17:10] [21:17:06.960,594] [Z_STACK/READ] INFO   : [DBG] Allocated        @ 0xB6A00490 (received  37 messages)...
[2020-10-16 21:17:10] [21:17:06.960,655] [Z_STACK/READ] INFO   : Filling new message (@ 0xB6A00490)...
[2020-10-16 21:17:10] [21:17:06.961,171] [Z_STACK/HNDL] INFO   : [MUTEX] Mutex for AREQ unlocked
[2020-10-16 21:17:10] [21:17:06.961,249] [Z_STACK/HNDL] INFO   : [DBG] Processing       @ 0xB6A00490
[2020-10-16 21:17:10] [21:17:06.961,281] [Z_STACK/HNDL] INFO   : [MUTEX] AREQ Calling asynchMsgCback (Handle)...

The BDB Specification says first:

Set IdentifyTime to ≥ bdbMinCommissioningTime

which IMHO refers to the duration of the "self-identification" and is likely unrelated to the above observations.

It further says

Broadcast identify query

In the simplified Figure for the Finding&Binding procedure for an initiator endpoint.
This seems to match, as the query to sent to all nodes using the Broadcast address 0xFFFF.

It seems that this resumes to the Linux Gateway is misbehaving for a reason that still needs to be identified.

Note, this question was edited to correct myself because the Identify Query Command #1 does not have a payload, the queried device replies with a payload.  Teh specification has the same title for figure 3-6 as 3-8 which is confusing.  the title for 3-6 is obviously wrong.  In fact the copy/paste error is repeated several times in 3.5.2.3.1.1.

  • 0
    TI__Guru**** 202226 points

    Hi le_top,

    Since the gateway has received the Identify Query message, Processing Af Incoming Message Indication, and found an EP/Cluster, isEndpointClusterExistOnGw(): EP/Cluster Found, for which to respond I don't believe this behavior has to do with the Identify procedure.  Instead I recommend we focus on why the gateway does not have the IEEE address of the ZED for which it needs to send a SRVR_GET_IEEE_ADDRESS_REQ, then why it immediately responds with a STATUS_FAILURE in the SRVR_GET_IEEE_ADDRESS_CNF (as if it does not recognize shortAddress 0xA6E6).  Can you provide a sniffer log of the joining process?  Does your end device complete the TC Link Key update and broadcast a Device Announce?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Hi Ryan

    I agree to focus on the short to long address mapping issue - I forgot to update the title in the end.

    The attached zip file has the sniffer log as well as the gateway log.  The sniffer log covers 24 hours (my setup sniffs around the clock and the logs are split every 1MB or every 24h whicever comes first).

    The End Device made the Device Annoincement at 22:17:06

    address0forNewDevice.zip

    Mario

    tt

  • 0 in reply to Mario DW
    TI__Guru**** 202226 points

    Hi Mario,

    The join process appears to be fine with the exception of the TC Link Key not being updated by the ZED.  The gwPb_SrvrGetIeeeAddress -> SRVR_CMD_ID_T__SRVR_GET_IEEE_ADDRESS_REQ -> nmPb_processSrvrGetIeeeAddressReq -> nwkMgrDb_GetIeeeAddr -> sdb_get_record is failing.  nwkMgrDb_AddDevice should have been called from nwkSrvAddDeviceTcInfoCB after processZdoTcDeviceInd except that this never occurs since the ZED does not initiate a TCLK update process.  The gateway is expecting all Zigbee 3.0 devices which use the Identify F&B process to also update the TC Link Key, but this is not the case in your instance.  I recommend that your ZED complete the TCLK update procedure or you move the nwkMgrDb_AddDevice reference from ZSTACK_CMD_IDS__ZDO_TC_DEVICE_IND to ZSTACK_CMD_IDS__ZDO_DEVICE_ANNOUNCE.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Hi Ralph

    If the TCLK update process by the ZED is a Z-Stack 3.0 requirement, than this is what should be "implemented" in the ZED.

    The ZED is based on TI's Z-Stack 3.0.2.  Is this something that has to be implemented as the developer of the End Device or is this something that is already implemented in the Z-Stack itself?

    If this is an expectation of the gateway and not a Z-Stack 3 requirement, then I need to update the gateway.

    The ZED's Flash is completely erased on every SW update.

  • 0 in reply to Mario DW
    TI__Guru**** 202226 points

    A quick explanation of Trust Center Link Key updates is provided in SWRA615.  They are automatically implemented by Z-Stack 3.0.2 ZEDs unless requestNewTrustCenterLinkKey (defined in ZDSecMgr.c) is set to FALSE (not the default value), this would only be done to allow backwards compatibility with Zigbee HA/R20 networks.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    While this thread holds a lot of explications how things should function, I have not identified anything that I have to change in the ZED implementation (built on ZStack 3.0.2 =.  This meas that the cause of the observed behavior is not fixed.

     In case this happens again, I'll either append to this question (if possible) or create a new one. .