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

CC1352P: ZNP device rejoin have abnormal MT_ ZDO_ LEAVE_ IND message

jia liang
Prodigy 30 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC2530, Z-STACK,

I encountered a problem with znp

Environment: I have a cc2530 sensor and coordinator. When the sensor is at a certain distance from the coordinator (a critical point where normal communication cannot be achieved), the sensor's rejoin process is triggered, and the coordinator also replies to the rejoin resp, but then znp pushes the MT_ ZDO_ LEAVE_ IND message, but no corresponding sensor device

[14:58:36]I (247838714) |RPC|: SOC IN  <-- 18 Bytes: SOF:FE, Len:0D, CMD0:45, CMD1:C9, FCS:34, Payload:
[14:58:36]83 8F 56 CC 59 23 00 4B 12 00 00 00 00
[14:58:36]I (247838729) |MT ZDO|: zdoProcess: MT_ZDO_LEAVE_IND

I repeated the environment several times and found that there was always MT_ ZDO_ LEAVE_ The phenomenon of IND. I wonder if the protocol stack has special handling for this interaction failure?

  • 0
    TI__Guru**** 218577 points

    Hello jia,

    Please provide your sniffer log (with network key).  Also, what hardware and software is your Coordinator?  Is the CC2530 a Z-Stack 3.0.2 ZNP?  How much time has passed since the CC2530 last communicated with the coordinator and what are the contents of the Rejoin Response?

    Regards,
    Ryan

  • 0
    Prodigy 30 points

    1. Coordinator ZNP was cc1352p

    SDK :simplelink_cc13x2_26x2_sdk_5_20_00_52

    sensor was cc2530

    2.Rejoin Response it seems correct

    3.The time is not fixed, but it's not time for him to age,But the communication distance is at the edge of communication and loss of communication

    sniffer：

    nwk key:F0:5C:58:D4:F0:D1:4E:5D:2F:B6:19:CA:F3:3A:19:92

    znp_leave_ind_ch15_panDEBB.zip

  • 0 in reply to jia liang
    Guru 735685 points

    It's strange that there is no ZDO leave or nwk leave packets in your sniffer log but you see MT_ZDO_LEAVE_IND from your MT command recceiver.

  • 0 in reply to jia liang
    TI__Guru**** 218577 points

    What is your CC2530 sensor firmware?  Is it from Z-Stack 3.0.2 and what specific project is referenced?  Have you reviewed the known issues and fixes?

    I can observe a Leave in the sniffer log which comes from 0xFA9D, IEEE address 94:DE:B8:FF:FE:41:E3:34, and cannot determine if this is related.  There are several packets missing from the log as indicated by ACKs without an original message and missing MAC Sequence increments.  0x8F83 (00:12:4B:00:23:59:CC:56) broadcasts an Orphan Notification after none of its Data Requests are ACKed by the ZC after the Rejoin Response.  Both devices may still be too far for steady communication.  You could try hard resetting the sensor device or perform a soft reset or restart the rejoin process if you are able to change the sensor software.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 30 points

    hi Ryan:

    The cc2530 is a third-party device with a long history. I will try to push them to confirm these things. but it is not expected to be too good.

    Do we have a way to debug something from the znp side.thanks

  • 0 in reply to jia liang
    TI__Guru**** 218577 points

    You can move the CC2530 sensor and CC1352P ZNP coordinator closer together and possibly increase the TX output power of both.  The sniffer device should be strategically placed so that it can detect all packets from both devices.  You could enter a CC1352P debug session inside CCS but at the moment there is not enough evidence for further investigation from the ZNP since the issue primarily concerns CC2530 sensor behavior.

    Regards,
    Ryan