• State Verified Answer
  • Replies 2 replies
  • Subscribers 86 subscribers
  • Views 581 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 351373
Options

DFU behavior during dual-bank update and power loss scenarios on nRF52840 (nRF5SDK v17.1.0)

koteraMfg.

Hello,

I am using nRF52840 with nRF5SDK v17.1.0, and I have several questions regarding DFU.
Reference page: https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/index.html

① In the case of dual-bank update, my understanding is that the new firmware is written to Bank1, while the existing application remains in Bank0.

  • Does the bootloader simply switch the application start bank after a successful update?

  • Or does it copy the application from Bank1 to Bank0 as part of the DFU process?

② If the power is lost during the firmware transfer to Bank1, the CRC check will fail at the next boot, and the bootloader will run the application from Bank0 (existing app).

  • But what happens if the power is lost after Bank1 has been fully written but while the bootloader is updating its settings (e.g., switching the active bank or copying)?

  • What would be the behavior at the next boot in this case?

③ We are planning to perform DFU from a smartphone application using the following libraries:

  • Android-DFU-Library

  • iOS-DFU-Library
    Will these libraries continue to be supported in the future (e.g., updates for new OS versions)?

④ For production devices, what is the common practice for DFU configuration?

  • Is dual-bank update generally recommended, or single-bank update?

  • Should multiple methods of triggering the bootloader’s DFU start be implemented?

  • Are there any other best practices or important considerations when using DFU in a product?

Any advice would be greatly appreciated.

Thank you!

Parents
  • +1

    Hi,

    Or does it copy the application from Bank1 to Bank0 as part of the DFU process?

    Yes. After the new image is transfered to slot 1, the bootloader activates it by copying it down to slot 0. (In order to run the image from slot 1, the image would have to be built for slot 1, or would have to be buit as position independent and that is not suported in the SDK).

    ② If the power is lost during the firmware transfer to Bank1, the CRC check will fail at the next boot, and the bootloader will run the application from Bank0 (existing app).

    If there is a reset during transfer the image is not marked as completed, and ther has never been an attempt to activate it, so th ebootloder will not even check the CRC of it during boot as it is not in slot 0 (it will however remain in slot 1 so that donwload can continue in a subsequent DFU session without having to transfer the whole image again).

    But what happens if the power is lost after Bank1 has been fully written but while the bootloader is updating its settings (e.g., switching the active bank or copying)?

    The bootlodaer keeps a backup of the DFU settings pag which is restored if the settings page is invalid. If all fails, and there is no bootable application, the bootloader enters DFU mode to facilitate recovery

    Will these libraries continue to be supported in the future (e.g., updates for new OS versions)?

    There is no current plan to deprecate support for these and it is unlikely tha twill change in the near future, but I cannot give any promises for how long it will be supported. Please contact your Nordic sales representative if you need more input on this.

    Is dual-bank update generally recommended, or single-bank update?

    In most practical cases dual bank DFU is prefered if possible. This way, a valid application can always be booted after a failed DFU attempt. At the same time, dual banknig is not always possible if the appliacation size incrases, so single bank updates is also an option. In this case, a failed update makes de application unbootable, but the device enters DFU mode in this case, and can be recovered by a subsequent successfull DFU operation.

    Should multiple methods of triggering the bootloader’s DFU start be implemented?

    This is entierly application dependent. Most modern application need "buttonless DFU" where the device enters DFU via Bluetooth as demonstrated by the Buttonless DFU Template Application. It could also make sense to enter DFU based on a pin/button or pin reset for some products.

    Are there any other best practices or important considerations when using DFU in a product?

    The most important is that application simages should be signed, which is the case with the secure bootloader in he nRF5 SDK. You need to keep the private key secure, and not loose it. If it is lost, you will not be able to ship new DFU images. Other than that, most choises will be application dependent.

    PS: If you are starting development now I would strongly advice considering the nRF Connect SDK instead of the nRF5 SDK.

Reply
  • +1

    Hi,

    Or does it copy the application from Bank1 to Bank0 as part of the DFU process?

    Yes. After the new image is transfered to slot 1, the bootloader activates it by copying it down to slot 0. (In order to run the image from slot 1, the image would have to be built for slot 1, or would have to be buit as position independent and that is not suported in the SDK).

    ② If the power is lost during the firmware transfer to Bank1, the CRC check will fail at the next boot, and the bootloader will run the application from Bank0 (existing app).

    If there is a reset during transfer the image is not marked as completed, and ther has never been an attempt to activate it, so th ebootloder will not even check the CRC of it during boot as it is not in slot 0 (it will however remain in slot 1 so that donwload can continue in a subsequent DFU session without having to transfer the whole image again).

    But what happens if the power is lost after Bank1 has been fully written but while the bootloader is updating its settings (e.g., switching the active bank or copying)?

    The bootlodaer keeps a backup of the DFU settings pag which is restored if the settings page is invalid. If all fails, and there is no bootable application, the bootloader enters DFU mode to facilitate recovery

    Will these libraries continue to be supported in the future (e.g., updates for new OS versions)?

    There is no current plan to deprecate support for these and it is unlikely tha twill change in the near future, but I cannot give any promises for how long it will be supported. Please contact your Nordic sales representative if you need more input on this.

    Is dual-bank update generally recommended, or single-bank update?

    In most practical cases dual bank DFU is prefered if possible. This way, a valid application can always be booted after a failed DFU attempt. At the same time, dual banknig is not always possible if the appliacation size incrases, so single bank updates is also an option. In this case, a failed update makes de application unbootable, but the device enters DFU mode in this case, and can be recovered by a subsequent successfull DFU operation.

    Should multiple methods of triggering the bootloader’s DFU start be implemented?

    This is entierly application dependent. Most modern application need "buttonless DFU" where the device enters DFU via Bluetooth as demonstrated by the Buttonless DFU Template Application. It could also make sense to enter DFU based on a pin/button or pin reset for some products.

    Are there any other best practices or important considerations when using DFU in a product?

    The most important is that application simages should be signed, which is the case with the secure bootloader in he nRF5 SDK. You need to keep the private key secure, and not loose it. If it is lost, you will not be able to ship new DFU images. Other than that, most choises will be application dependent.

    PS: If you are starting development now I would strongly advice considering the nRF Connect SDK instead of the nRF5 SDK.

Children
Related
Terms of service