Switching Zigbee device role with OTA update?

If a manufacturer ships a large number of nRF52840 based devices that are configured as Zigbee end devices, and then later decides to switch them to Zigbee routers through an OTA firmware update, will that work?

Or is there data stored in the ZBOSS NVRAM that could potentially confuse the stack after such a change?

Obviously, the effects of the OTA update would need to be transparent to end users -- i.e. they shouldn't be forced to manually re-pair or factory-reset all of the devices that got the update.

Parents
  • Hi,

    Yes, information about the device role is stored in ZBOSS NVRAM. The update from an End Device to a Router without factory reset is not possible.
    What are you trying to achieve with this approach?
    Best regards,
    Jørgen
  • We want the product to be a ZR, but a while back we switched the builds to ED mode because that helped work around some of the stability issues we were seeing in ZR mode.  The hope is that we can switch back to ZR mode through an OTA update at some point in the future, after the stability issues have all been addressed.

    We continue to see the Nordic devices rebooting/asserting randomly, and it is more disruptive to the customer's network if it's a ZR rather than an ED doing this.  The most reproducible example of this is  (Missing Ticket) where a simple match_desc response causes the Nordic device to hang.  We have seen other instances where a flurry of network activity causes a Nordic device configured as a ZR to hang/reset, but there was no instrumentation connected at the time and there isn't currently a repro case.

    I can upload the NVRAM from the most recent failure, if that helps...

Reply
  • We want the product to be a ZR, but a while back we switched the builds to ED mode because that helped work around some of the stability issues we were seeing in ZR mode.  The hope is that we can switch back to ZR mode through an OTA update at some point in the future, after the stability issues have all been addressed.

    We continue to see the Nordic devices rebooting/asserting randomly, and it is more disruptive to the customer's network if it's a ZR rather than an ED doing this.  The most reproducible example of this is  (Missing Ticket) where a simple match_desc response causes the Nordic device to hang.  We have seen other instances where a flurry of network activity causes a Nordic device configured as a ZR to hang/reset, but there was no instrumentation connected at the time and there isn't currently a repro case.

    I can upload the NVRAM from the most recent failure, if that helps...

Children
No Data
Related