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!

[coolerkid]

EMPTY_0:

address: 0xdd000

end_address: 0xde000

placement:

after:

- mcuboot_secondary

region: flash_primary

size: 0x1000

app:

address: 0xd200

end_address: 0x75000

region: flash_primary

size: 0x67e00

mcuboot:

address: 0x1000

end_address: 0xd000

placement:

align:

end: 0x1000

before:

- mcuboot_primary

region: flash_primary

size: 0xc000

mcuboot_pad:

address: 0xd000

end_address: 0xd200

placement:

align:

start: 0x1000

before:

- mcuboot_primary_app

region: flash_primary

size: 0x200

mcuboot_primary:

address: 0xd000

end_address: 0x75000

orig_span: &id001

- app

- mcuboot_pad

region: flash_primary

sharers: 0x1

size: 0x68000

span: *id001

mcuboot_primary_app:

address: 0xd200

end_address: 0x75000

orig_span: &id002

- app

region: flash_primary

size: 0x67e00

span: *id002

mcuboot_secondary:

address: 0x75000

end_address: 0xdd000

placement:

after:

- mcuboot_primary

align:

start: 0x1000

region: flash_primary

share_size:

- mcuboot_primary

size: 0x68000

nrf5_bootloader:

address: 0xe0000

end_address: 0x100000

placement:

align:

start: 0x1000

before:

- end

region: flash_primary

size: 0x20000

nrf5_mbr:

address: 0x0

end_address: 0x1000

placement:

after:

- start

region: flash_primary

size: 0x1000

settings_storage:

address: 0xde000

end_address: 0xe0000

placement:

align:

start: 0x1000

before:

- end

region: flash_primary

size: 0x2000

sram_primary:

address: 0x20000000

end_address: 0x20040000

region: sram_primary

size: 0x40000

[Vidar Berg]

Thanks for providing the memory layout. Unfortunately, I don't see anything wrong with it, so still not sure what is causing the nRF5 bootloader to fall back into DFU mode. If you have received the nRF52840 DK you can try to reproduce the same using the Open Bootloader with DFU example (pre-programmed bootloader on dongle is based on the same project)

[coolerkid]

I got the DK and was able to flash it with my firmware, then updated it multiple times over bluetooth and it worked just fine. After restarting it, the app ran just fine and didn't go into DFU. So it does not have the same issue as the dongle. What do I try next? Thanks 

[Vidar Berg]

If you want to reproduce the issue seen with the dongle, you will also need to include the bootloader mentioned in my previous response. The problem you’re encountering with the dongle is that the Open Bootloader enters DFU mode instead of branching to MCUBoot.

[coolerkid]

I compiled and flashed the open bootloader (open_bootloader/pca10056_usb_debug), but now I am unable to put it into DFU to install my firmware. I'm also not getting any logging. I'm kind of lost now what to do next. Thanks 

[Vidar Berg]

DFU will be on this USB port that is connected to the nrf USB: 

Did you connect to this? Also, is the goal to use the nRF52840 Dongle in your final solution? If not, I do not see any advantage of including this bootloader in addition to MCUBoot and would recommend to just use the latter.

[coolerkid]

Ok this is where I'm confused. I thought that when I pushed my app with MCUBOOT enabled, that MCUBOOT became the primary boot loader. After reading your response I believed that you were saying that there was a pre-bootloader on the Nordic Dongle that's different than the one on the DK and I had to load that version on the DK to be able to replicate the issue I'm having with the dongle? 

Yes I'm using that port to flash the device. 

Thanks 

[Vidar Berg]

Yes correct, so the dongle comes pre-programmed with this open_bootloader bootloader which can't be overwritten unless you connect an external debug probe to the dongle. For more details about this, please see the  nRF52840 Dongle Programming Tutorial . 

[coolerkid]

I don't understand what you mean when you say "If not, I do not see any advantage of including this bootloader in addition to MCUBoot and would recommend to just use the latter."

I take this to mean that I should only use MCUBoot and not the default bootloader, but how is that possible if this cannot be overwritten in the dongle?

I've read every article I could find on the bootloader and FOTA but I'm still lost what I need to do next to try and debug the situation I'm facing.

Thanks. 

[Vidar Berg]

coolerkid said:

take this to mean that I should only use MCUBoot and not the default bootloader, but how is that possible if this cannot be overwritten in the dongle?

Correct, but as mentioned in my previous reply you can overwrite it with a debugger. Also this is only relevant if your project uses the nRF52840 Dongle as it is the only device (at least from us) that comes pre-programmed with this bootloader. Loose nRF52840 ICs are shipped empty and require initial programming through the debug interface.

The nRF52840 Dongle is not intended for FW development or for use in a final product and the main if not only reason you might want to have *both* MCUBoot and the Open Bootloader programmed on the dongle is if you need to support Zephyr/NCS DFU, but don't have the option of overwriting the existing bootloader using an external debug probe.