This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE and THREAD DFU

We have a multi protocol project THREAD and BLE. It currently uses the BLE DFU for OTA updates. We would like to add the THREAD DFU so we can use either transport mechanism.

Is it possible to have both in the same project and use the one that initiates the DFU process.

Parents
  • Hello,

    DFU over Thread is only supported in background mode, which means that new FW image(s) are retrieved and stored by the main application. The bootloader is still used to validate and activate the new FW as the final step of the updated process. So I think it should be easy to separate the two DFU transport if one is used in background mode (thread) and the other in bootloader mode. Quickly summarized the update process would then be something like this:

    DFU over BLE

    The DFU controller writes the DFU Start command to the BLE DFU buttonless characteristic making the main application jump to the bootlaoder. The bootloader will then enter DFU mode and start BLE advertising to let the controller re-connect and start the FW transfer.

    Thread

    The main app handles stores the init command and FWimage and when ready it performs a system reset to allow the bootloader to finalize the update.

    If your existing bootloader is based on SDK 15.3.0/nRF5 SDK for Thread and Zigbee v3 or later it should be sufficient to enable the NRF_BL_DFU_ALLOW_UPDATE_FROM_APP config setting in the sdk_config header to support background DFU. SDK documentation for reference: Thread Secure DFU protocol

  • You mention that you need SDK 15.3 to use NRF_BL_DFU_ALLOW_UPDATE_FROM_APP config setting.

    What if the project is based on SDK 14 can this still be done. 

  • I went digging my mistake the project is based on SDK 15.0 will this still work.

  • Background DFU is supported but it doesn't have the same config settings. SDK 15.0.0 was used by the nRF5 SDK for Thread and Zigbee v1.0.0 so you could use the Thread bootloader from this release as a reference. 

    But I would recommend you to consider migrating your code to the latest SDK (currently nRF5 SDK for Thread and Zigbee v4.0.0). Limitation stated in the release notes for the current release:

    OTA DFU: Migration from the nRF5 SDK for Thread and Zigbee version
    earlier than v4.0.0 is not supported for multiprotocol applications.

  • OTA DFU: Migration from the nRF5 SDK for Thread and Zigbee version
    earlier than v4.0.0 is not supported for multiprotocol applications.

    Does this mean that the thousands of devices I have in the field based on Thread SDK 1.0 are can not be updated to SDK 4.0?

  • This limitation applies to background DFU mode where you cannot do major Softdevice upgrades. nRF5 SDK for Thread and Zigbee version 4.0.0 is based on a new major Softdevice release (s140 v6 ->v7) that is larger and would thus overlap with the existing application performing the DFU. But it should be possible to do this update if you do DFU over BLE through the bootloader.

Reply
  • This limitation applies to background DFU mode where you cannot do major Softdevice upgrades. nRF5 SDK for Thread and Zigbee version 4.0.0 is based on a new major Softdevice release (s140 v6 ->v7) that is larger and would thus overlap with the existing application performing the DFU. But it should be possible to do this update if you do DFU over BLE through the bootloader.

Children
No Data
Related