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

DFU recover from 'DfuTarg" bootloader to application

I run into this situation on Android nRF Connect [latest version], where the device can lose a connection when attempting a DFU. In this situation, the advertising name is DfuTarg and the user has no idea the name  and even the bluetooth address changes. If disconnected in this stage(in the simplest case, say I disconnect before DFU begins), the bootloader does not jump back to the application. I can obviously connect to the device calling itself DfuTarg, but that cannot be expected from a user. The Android app also opens up a new tab with the DfuTarg device, which leads to further confusion. How do you advise to recover from/handle this situation?

Parents
  • Hi,

    How do you advise to recover from/handle this situation?

    The bootloader has an inactivity timeout that will reset if the device after a specified number of inactive miliseconds, configured by setting NRF_BL_DFU_INACTIVITY_TIMEOUT_MS in the bootloaders sdk_config.h. If the application is still present (either because the timeout happened early, or because dual bank DFU is used), the application will be started in this case. If not, the device will enter DFU mode again.

    You could also set the advertising name of the bootloader to be something that reflects your product ("Productname_DFU" or similar) so that it would make more sense to the user if this happens.

Reply
  • Hi,

    How do you advise to recover from/handle this situation?

    The bootloader has an inactivity timeout that will reset if the device after a specified number of inactive miliseconds, configured by setting NRF_BL_DFU_INACTIVITY_TIMEOUT_MS in the bootloaders sdk_config.h. If the application is still present (either because the timeout happened early, or because dual bank DFU is used), the application will be started in this case. If not, the device will enter DFU mode again.

    You could also set the advertising name of the bootloader to be something that reflects your product ("Productname_DFU" or similar) so that it would make more sense to the user if this happens.

Children
No Data
Related