Device goes into DFU after adding FOTA over Bluetooth

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Tue, 21 Oct 2025 07:57:24 GMT

Thanks for the clarification. Perhaps it would be better to work with dongles from those companies then as they may ship with a different bootloader. The nRF52840 dongle is for example not FCC certified and may not be resold in markets requiring this.

[quote user="coolerkid"]So how can we debug this issue if it's working on the DK with the open bootloader[/quote]

Did your program the open bootloader + MBR and where you able to upload your application through the nRF USB?

[quote user="coolerkid"]Can these dongles for sure support FOTA over BT?[/quote]

Yes.

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Tue, 21 Oct 2025 01:46:03 GMT

Our intent is to use a dongle from one of the companies where we can white label them for resale, instead of building our own because it has everything we need already. I'm not sure if we will be having the manufacture flash these for us with our firmware or if we're going to do it ourselves, but if we do we'll only be able to flash it over USB so we likely wont have the option to write over the bootloader.

So how can we debug this issue if it's working on the DK with the open bootloader, but not on the actual dongles we are trying to use? Can these dongles for sure support FOTA over BT?

Thanks

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Wed, 15 Oct 2025 19:13:50 GMT

[quote user="coolerkid"] 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?[/quote]

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.

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Wed, 15 Oct 2025 14:29:17 GMT

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.

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Wed, 15 Oct 2025 06:11:14 GMT

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 .

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Wed, 15 Oct 2025 02:48:58 GMT

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

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Tue, 14 Oct 2025 06:21:00 GMT

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.

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Mon, 13 Oct 2025 17:32:38 GMT

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

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Tue, 07 Oct 2025 06:10:12 GMT

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.

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Tue, 07 Oct 2025 03:23:43 GMT

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

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Mon, 06 Oct 2025 12:22:05 GMT

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)

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Fri, 03 Oct 2025 13:46:06 GMT

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

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Fri, 03 Oct 2025 07:22:52 GMT

Good. It's much easier to debug when you have the on-board debugger.

The problem is not with this reserved partition, but there could be problems with the other parititions. Could you please post the partitions.yaml file from your build folder here?

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Thu, 02 Oct 2025 18:01:54 GMT

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

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Thu, 02 Oct 2025 07:37:59 GMT

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.

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Thu, 02 Oct 2025 01:23:15 GMT

Any idea what could be wrong? Thanks

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Tue, 30 Sep 2025 15:02:01 GMT

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

Thanks

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Tue, 30 Sep 2025 14:54:06 GMT

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

[quote user="coolerkid"]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.[/quote]

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

RE: Device goes into DFU after adding FOTA over Bluetooth

coolerkid — Tue, 30 Sep 2025 14:31:32 GMT

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!

RE: Device goes into DFU after adding FOTA over Bluetooth

Vidar Berg — Tue, 30 Sep 2025 12:51:18 GMT

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