Device with s120 softdevice version gets stuck in the bootloader waiting for DFU.

Hi all,

In our project we are using two device running on NRF chipset. One has the s140 softdevice version (NRF52833) and the other has s112 version (NRF52810). We are facing the issue only on the device with s112 softdevie version. More details for the problem:

  1. The issue is observed when doing DFU from the NRF connect app and the app is killed in between the DFU process.
  2. For the device with softdevice version s140, it starts to advertise after 2 mins of time. Probably it has to do with the NRF_BL_DFU_INACTIVITY_TIMEOUT_MS value which is set to 2 mins. At this timeout the bootloader is reset.
  3. However, for the other device which is running on s112 softdevice, it stays in the bootloader waiting for the DFU file forever. The NRF_BL_DFU_INACTIVITY_TIMEOUT_MS value is same as the other device which is 2 mins and after this timeout the bootloader is supposed to reset as per the code.
  4. Once we do DFU with boottag for the same device from NRF connect app, then the device starts the advertise again and device comes out of the bootloader. However, from our custom application this is not an option. We need the device to come out of bootloader even after failed DFU process.
  5. Perhaps the bootloader does resets after the inactivity timeout but it again stucks in DFU mode.
  6. Since enabling the bootloader logs is causing memory segment overlap issue so we are unable to get the bootloader logs to post it here.

So what can be the underlying issue for this? Is it due to some flag that the device starts waiting for DFU? Or the bootloader does not reset in the first place after failed DFU event?

Any help is very much appreciated. Thanks.

Parents
  • Hi,

    Is it so that you abort the DFU procedure while a DFU operation updating the application is ongiong? If so, a potential explanation could be that on the nRF52833 variant, there is enough available flash to perform the application DFU in a dual banking manner. This will not be possible on the nRF52810 due to less flash memory, and the application update is in a single bank manner (see nRF5 SDK v17.1.0: Dual-bank and single-bank updates).

    After a failed dual bank update, the old application is stil present and can be boooted after the timeout specified with NRF_BL_DFU_INACTIVITY_TIMEOUT_MS has occored. After a single bank update however, there is no valid application that can be booted. In this case, the only way to recover is to perform a successfull update.

Reply
  • Hi,

    Is it so that you abort the DFU procedure while a DFU operation updating the application is ongiong? If so, a potential explanation could be that on the nRF52833 variant, there is enough available flash to perform the application DFU in a dual banking manner. This will not be possible on the nRF52810 due to less flash memory, and the application update is in a single bank manner (see nRF5 SDK v17.1.0: Dual-bank and single-bank updates).

    After a failed dual bank update, the old application is stil present and can be boooted after the timeout specified with NRF_BL_DFU_INACTIVITY_TIMEOUT_MS has occored. After a single bank update however, there is no valid application that can be booted. In this case, the only way to recover is to perform a successfull update.

Children
No Data
Related