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

[Vidar Berg]

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?

[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.