Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Dual bank update failing until first successful DFU

I'm running a device that implements the NRF52832, and when I follow these steps, the device goes into a state where it is completely unresponsive and must be flashed with from its SWD interface:

  1. Compile a hex file that contains the app, bootloader, softdevice, and settings
  2. Using Segger J-Flash Lite, erase the chip and then program the device with the hex file from step 1
  3. Compile a DFU package that contains just the app
  4. Using the Android Nordic DFU app, begin uploading the DFU package over Bluetooth
  5. Cancel the DFU before it reaches 100%

After this, the device will go into bootloader mode and advertise on BLE for about 30 seconds using the device name set in the bootloader. This seems consistent with the single bank update behavior specified in the SDK documentation (Nordic Semiconductor Infocenter). But why isn't it performing a dual bank update? "NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES" is set to 1. Also, if you don't finish the update in the 30 seconds before the device stops advertising, it will never advertise again. Why is that? The bootloader is supposed to advertise continually until it finds a valid firmware image.

If a DFU is completed successfully and the subsequent DFU is then cancelled before it reaches 100%, then the above will not happen. In that case, it will just load the previous firmware image like it's supposed to. I assume this is because the first DFU properly populates the second bank in memory which allows dual-bank updates to work as intended. Is there a way to populate this bank while compiling the initial hex file?

Also, the SDK version in use is 15.3.0.

Parents
  • Did you ever find a solution to this issue? I have just begun to notice the same thing.

    I am using the iOS nRF Connect application.

    1. I use the nRF Connect desktop programmer application to flash a hex file that contains the softdevice, bootloader, bootloader settings, and initial application hex.
    2. I start the DFU process to upgrade to a later version of the application.
    3. I cancel the update and it bricks the device. No bootloader or application is advertising, and power cycling doesn't bring it back.

    If I allow the first update to succeed, and then start and cancel another update, it will correctly revert to the firmware version as I would expect. 

Reply
  • Did you ever find a solution to this issue? I have just begun to notice the same thing.

    I am using the iOS nRF Connect application.

    1. I use the nRF Connect desktop programmer application to flash a hex file that contains the softdevice, bootloader, bootloader settings, and initial application hex.
    2. I start the DFU process to upgrade to a later version of the application.
    3. I cancel the update and it bricks the device. No bootloader or application is advertising, and power cycling doesn't bring it back.

    If I allow the first update to succeed, and then start and cancel another update, it will correctly revert to the firmware version as I would expect. 

Children
Related