• State Verified Answer
  • Locked Locked
  • Replies 27 replies
  • Subscribers 25 subscribers
  • Views 1975 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 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

  • +1 in reply to user92402

    Hi Sergey,

    This will be fixed in nRF Connect SDK v1.9.0.

    Best regards,

    Marte

  • 0 in reply to user92402

    Hi Marte,

    When will be the estimated release for this version/fix?

    Best regards,

    Alex

  • 0 in reply to user94117

    Hi Alex,

    If you want information about roadmap and releases, please contact our regional sales manager in your area.

    Best regards,

    Marte

  • 0 in reply to user92402

    Hi Marte,

    I checked SDK 1.9.0 and, indeed, it's working as expected!

    Thank you for the update and sorry for my delayed reply.

    Best regards,

    Sergey

Reply Children
No Data
Related
Terms of service