• State Verified Answer
  • Locked Locked
  • Replies 27 replies
  • Subscribers 25 subscribers
  • Views 1977 views
  • Users 0 members are here
Attachments (5) Download All
Nordic Case Info
  • Case ID: 277459
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

user84718

Hello,

During my evaluation of nRF52840 I discovered an issue which prevents the device from joining a Zigbee network successfully.

I'm using out of the box zigbee/light_bulb with some logging enabled. When I initiate the network joining on Samsung Smartthings coordinator, ziboss function calls  zb_osif_abort and causes the fatal halt.

I'm using nRF Connect v3.7.1.

Some additional information you might find useful:

* I have a coordinator from other vendor and if I use a dedicated channel used by that coordinator, the light bulb successfully and quickly joins it.

* You can see the call stack on the screenshot below:

* I'm attaching the log messages I see before the device halts.

 

Parents
  • 0

    Hi,

    Is the Samsung Smartthings coordinator Zigbee 3.0 compatible, or is it a legacy device? Please try calling zb_bdb_set_legacy_device_support(1) on the light bulb after ZBOSS is initialized, for example in ZB_BDB_SIGNAL_DEVICE_FIRST_START or ZB_BDB_SIGNAL_DEVICE_REBOOT. This will enable support for legacy devices.

    If this does not solve the issue, can you get a sniffer log of this behavior and upload it here as a pcap file?

    Best regards,

    Marte

  • 0 in reply to user92402

    Hi Marte,

    Thank you for your quick feedback and the suggested fix!

    As you suspected, Samsung Smartthings hub I'm using does not support Zigbee 3.0.

    So I tried to add zb_bdb_set_legacy_device_support(1) call and, indeed, the light bulb was successfully found by the hub and joined the network. But when I tried to remove it from the network, the same halt with identical call stack was triggered (zb_nlme_network_discovery_confirm -> zb_nwk_neighbor_clear -> zb_osif_abort).

    I'm attaching the sniffer log you asked. It should contain all the moments from joining the network, toggling on/off, and, finally, leaving which ended up in the halt.

    The log might be a bit polluted with communications with other network devices I've got connected, but if you need a clear one, just the hub and the light bulb example, please let me know and I'll try to produce one. 

    Best regards,

    Sergey

    Log

  • 0 in reply to user84718

    Hi Sergey,

    Thank you for this information! Knowing that the problem appeared first in v1.6.0 will hopefully help narrow it down. I hope you will be able to work with v1.5.1 for now, and I will keep you updated on the progress of this issue.

    The cases regarding zb_address_unlock are from the nRF5 SDK for Thread and Zigbee v4.1.0, which use an older version of the stack, ZBOSS v3.3, while nRF Connect SDK use newer versions of the stack, with ZBOSS v3.5.0.0 for nRF Connect SDK v1.5.0 and ZBOSS 3.8.0.1 for nRF Connect SDK v1.7.0. This issue has been solved in the versions of the stack that are in the nRF Connect SDK. Since your issue first appeared in v1.6.0, it seems to be an issue with newer versions of the stack.

    Best regards,

    Marte

  • 0 in reply to user92402

    Hi Sergey,

    Our developers were able to reproduce this occasionally on their side. There seem to be multiple issues with respect to the LEAVE command in the newest ZBOSS already. They have reported it as a bug to DSR, and hopefully there will be a fix in a later version of ZBOSS. Thank you for reporting this!

    Best regards,

    Marte

  • 0 in reply to user92402

    Hi Marte,

    Thank you for the update. I'm happy that you managed to preproduce the issue! I hope that DSR will prioritize it as a critical one and fix it ASAP. 

    It was my pleasure to help to improve the solution and I'm looking forward to seeing new SDKs with the issue solved.

    Best regards,

    Sergey

  • 0 in reply to user84718

    Hi Marte, 

    Just a small update. I tested 1.7.1 and it seems like the LEAVE started working for the hub which supports ZigBee 3.0 - QNECT, but I still have the issue described above with LEAVE on my old Samsung Smartthings.

    Best regards,

    Sergey

  • 0 in reply to user84718

    Hi Sergey,

    Thank you for the update!

    I just tested with v1.7.1, and I am still able to reproduce the issue using the same steps as earlier. Our developers have also reproduces the issue in newer versions of the ZBOSS stack, so the underlying issue is still there. I am not sure why you are not seeing this problem with the QNECT hub anymore, but this information might be useful to our developers in researching the bug.

    Unfortunately, I do not have any update on DSR's progress yet.

    Best regards,

    Marte

Reply
  • 0 in reply to user84718

    Hi Sergey,

    Thank you for the update!

    I just tested with v1.7.1, and I am still able to reproduce the issue using the same steps as earlier. Our developers have also reproduces the issue in newer versions of the ZBOSS stack, so the underlying issue is still there. I am not sure why you are not seeing this problem with the QNECT hub anymore, but this information might be useful to our developers in researching the bug.

    Unfortunately, I do not have any update on DSR's progress yet.

    Best regards,

    Marte

Children
Related
Terms of service