• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 413 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.

CC2538: How to handle MT_ZDO_TC_DEVICE_IND while joining a device in to the network.

shiv patil
Genius 3356 points

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Hello Community,

I am working on the CC2538 ZNP device & the znp host framework application.

When I am sending a permit joining request to the device,

the device is sending the MT_ZDO_TC_DEVICE_IND instead of the MT_ZDO_END_DEVICE_ANNCE_IND.

Will you please help me to know,

what is use case of the MT_ZDO_TC_DEVICE_IND  & when it is occures ?

How do I handle this response while adding devices to the network ?

&

How do I get the MT_ZDO_END_DEVICE_ANNCE_IND from the device while joining it in to the network ?

 

Regards,

Shiv Patil.

  • 0
    TI__Guru**** 222607 points

    Hello Shiv,

    The MT_ZDO_TC_DEVICE_IND response indication message occurs on a ZC device and is sent from the Z-Stack Thread whenever the Trust Center allows a device to join the network.  The MT_ZDO_END_DEVICE_ANNCE_IND should follow shortly once the ZED has been properly initialized inside the network and sets its device state accordingly.  Please provide a sniffer log of the failed joining if you would like more assistance in debugging this issue.  If you are attempting to join a 3.0 device to a 1.2.2a HA network then this will fail if the 3.0 device is expecting a Link Key update: http://www.ti.com/lit/swra615 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3356 points

    Hello ,

    First of all I would like to know,

    I am using CC2538 device as a znp & end device, the ZNP HOST FRAMEWORK Application as a host.

    How I am able to know which network I am working on 3.0 OR 1.2.2a HA network?...

    Also 

    I am also need to know that if the MT_ZDO_TC_DEVICE_IND received from the end device should I need to process it?

    OR send some request/response to end device after this received indication (the device which is getting added to the network).

    becouse I am not able to add the device in to network becouse of this. I am sending you the znp host framework & sniffer logs to understand the problem.

    [2020-02-06T18:58:02.65+05:30][INFO]-   comm_send_permit_join: sending permit join request
[2020-02-06T18:58:02.651+05:30][INFO]-  SOC OUT --> LEN :03, SOF :FE, CMD0 :26, CMD1 :08, Payload :00:00:1E, FCS :33
[2020-02-06T18:58:02.659+05:30][INFO]-  SOC IN  <-- LEN :01, SOF :FE, CMD0 :66, CMD1 :08, Payload :00, FCS :6F
[2020-02-06T18:58:02.659+05:30][INFO]-  comm_process_permit_join: Status SUCCESS.
[2020-02-06T18:58:02.659+05:30][INFO]-  comm_process_permit_join: Requested join time 30
[2020-02-06T18:58:02.659+05:30][INFO]-  SOC IN  <-- LEN :03, SOF :FE, CMD0 :45, CMD1 :B6, Payload :00:00:00, FCS :F0
[2020-02-06T18:58:02.659+05:30][INFO]-  app_json_request_event_fd_handler : repetative call @ current_app_req : 2
[2020-02-06T18:58:02.659+05:30][INFO]-  zdoProcess: MT_ZDO_MGMT_PERMIT_JOIN_RSP
[2020-02-06T18:58:02.659+05:30][INFO]-  mtZdoMgmtPermitJoinRspCb : SrcAddr: 0x0000
[2020-02-06T18:58:02.659+05:30][INFO]-  mtZdoMgmtPermitJoinRspCb : Status: 0x00
[2020-02-06T18:58:08.201+05:30][INFO]-  SOC IN  <-- LEN :0C, SOF :FE, CMD0 :45, CMD1 :CA, Payload :A6:A5:D3:41:3C:19:00:4B:12:00:00:00, FCS :6E
[2020-02-06T18:58:08.201+05:30][ERROR]- zdoProcess: CMD0:45 CMD1:CA not handled

    Regards,

    Shiv Patil.

  • 0 in reply to shiv patil
    TI__Guru**** 222607 points

    Hi Shiv,

    There are no clues provided during device joining to help you determine what specification of Zigbee network you are connecting to, it is only afterwards that you can figure this out through the network behavior.  For example, the sniffer log screen shot indicates that the ZC has formed a 3.0 network for which a TC Link Key update is expected and therefore asks the ZED to leave after it does not initiate this process.  In Z-Stack 3.0 this is controlled by the BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE and BDB_DEFAULT_TC_NODE_JOIN_TIMEOUT in bdb_interface.h.  MT_ZDO_TC_DEVICE_IND should not be processed by ZR/ZED nodes.

    Regards,
    Ryan