Device goes into DFU after adding FOTA over Bluetooth

[coolerkid]

I added FOTA over Bluetooth to my NRF52840 application. Everything works, I can update the application over bluetooth and it runs properly, but after updating if I unplug the dongle and plug it back in the device starts up in DFU mode instead of just starting up my application normally. Any idea why this would occur? Thanks 

[Vidar Berg]

Hello, 

Is this DFU mode (called serial recovery mode in MCUboot) in the nRF5 SDK bootloader that comes pre-programmed on the nRF52840 dongle, or in MCUboot? The only times the pre-programmed bootloader should enter DFU mode are if no valid application is present, or if the PINRESET bit is set in the POWER->RESETREAS register. And are you seeing this on more than one board?

Driving any of these pins low on the nrf52840 dongle will cause the bootloader to enter dfu mode (indicated by red LED) :

Ref. https://docs.nordicsemi.com/bundle/ug_nrf52840_dongle/page/UG/nrf52840_Dongle/hw_button_led.html

Best regards,

Vidar

[coolerkid]

After I flash it over Bluetooth my application works fine the first time, and I can confirm it's running the updated application, but once I unplug and plug it back in LED2 is flashing. If I open Programmer I see the device show up as Open DFU Bootloader and the contents of the device shows the application still there. Usually I have to press the reset button to get into this mode, but after flashing over Bluetooth it remains in this mode.

Could there be a condition where the application were able to run a first time but then when disconnecting it and reconnecting it the application isn't considered valid? I have tried calling boot_write_img_confirmed() on startup, but that did not fix it.

Thanks!

[Vidar Berg]

What if you plug it in a second time? Also, is the app using any of the pins mentioned in the linked user guide?

coolerkid said:

Could there be a condition where the application were able to run a first time but then when disconnecting it and reconnecting it the application isn't considered valid? I have tried calling boot_write_img_confirmed() on startup, but that did not fix it.

boot_write_img_confirmed() is only relevant to mcuboot. The preprogrammed bootloader is responsible for validating the mcuboot and not the zephyr app.

[coolerkid]

Every time I plug it in it's the same issue. The app isn't using any of those pins. 

Thanks 

[coolerkid]

Any idea what could be wrong? Thanks 

[Vidar Berg]

The only explanation I can think of is that the app/MCUBoot image is being altered at runtime and causing the boot validation to fail on subsequent reboots (see Boot validation modes). If the next image in the boot chain cannot be validated, the bootloader will fall back to DFU mode. If you are actively developing any FW, I recommend using a development kit (nRF52840 DK). The dongle is not designed for this.

[coolerkid]

Ok, I just ordered a nRF52840 DK. Could this have anything to do with my static partition? Do I need to make any changes from the one you had given me before? Thanks!

nrf5_bootloader:

address: 0xE0000 # Start address in flash

end_address: 0x100000 # End address in flash (1 MB boundary)

placement:

align:

start: 0x1000 # Alignment requirement (4 KB boundary)

before:

- end # Ensure it gets placed before the flash "end"

region: flash_primary

size: 0x20000 # 128 KB reserved for bootloader