FOTA not working on nRF52840 dongle

[jernejn]

I have tried using SMP svr example with MCUboot for FOTA, NRF Connect SDK version 2.9.0. The example is located in zephyr\samples\subsys\mgmt\mcumgr. This example is working perfectly on nRF52840DK, or nRF52DK, but on dongle it's not working, After download, the device doesn't start advertising, and after power off / on, it enters pre-programmed DFU mode.

The only change I have made to the the examples is, I created mcuboot.conf file inside sysbuild folder and added CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000, for partition manager.

I also selected overlay-bt.conf for extra kconfig fragment.

If I compile the same example with Zephyr V3.7.0, it is working. But also with Zephyr, the example breaks when I perform FOTA (on Android with nRF Connect app) and power off / on the device.

Is it even possible to use FOTA on nRF52840 dongle with the pre-programmed DFU bootloader?

[Einar Thorsrud]

Hi,

I do not see a fundamental reason why you should not be able to use the nRF52840 Dongle with MCUboot as well provided that everything is built to start from 0x1000. I see there is an additional zero in the number you have used (0x10000) though. The dongle is not the best development platform though, as it lacks a debugger, so unless you have an external debugger to debug I would suggest testing and debugging on a DK if you have that available.

[jernejn]

Thank you for the answer. The problem is with dongles DFU bootloader. I have the debugger but I cannot debug the bootloader without the sources. When connecting the debugger, the CPU never enters MCUBoot's reset handler. It just loops in the DFU. The problem is somewhere in the DFU application, since the same application works on DK without the DFU bootloader.

How is the bootloader checking if there is an application present on 0x1000 address or not?

As for the extra 0 you mentioned, there is no extra 0. Start offset is 0x1000, MCUBoot partition size is 0x10000 (64 kB).

[Einar Thorsrud]

Hi,

There should not be a need to debug the nRF5 SDK bootloader present on the dongle. While it could have issues, it is well tested and I don't believe it is the issue here. The bootloader will enter DFU mode if there is no valid application or after pin reset. If not, it will jump to address 0x1000.

jernejn said:

As for the extra 0 you mentioned, there is no extra 0. Start offset is 0x1000, MCUBoot partition size is 0x10000 (64 kB).

Ah, yes, you are right. I got a mixup when writing about the offset. The key here is that as long as the offset is 0x1000 (which is handled automatically when building with the dongle board files), building for the dongle is no different from other boards, except that also the end of the flash is not available (used for the nRF5 SDK bootloader).

[jernejn]

Thank you for pointing out that the dongle uses nRF5 SDK's open bootloader. It was a great help in solving the issue.

There are 2 reasons why the example isn't working with the dongle:

1. Partition manager in the nRF Connect SDK v2.9.0 isn't configured properly for the dongle. Since I'm new to the nRF environment, I don't know if this is the problem of the SDK, or should the user always configure the PM? On the picture below you can see that mcuboot_secondary is going beyond 0xE0000, where the nRF5 bootloader is located. Can you also suggest how to properly configure the PM, or is it ok just to disable it?
   
   
   The problem was solved when I used partitions from devicetree, with disabling the PM in sysbuild.conf file (SB_CONFIG_PARTITION_MANAGER=n).
2. The second issue with how to program the app. I tried to program MCUboot and the app with nRF Connect Desktop Programmer. After FOTA update, the device will always enter nRF5 bootloader. I then programmed only MCUboot, entered MCUboot's safe mode and with AuTerm programmed the app. This time, when performing FOTA, everything worked. I suspect the nRF5 bootloader has CRC check, and if the app changes, it doesn't boot the app. So tricking the bootloader that the only app to focus on is MCUboot, did the work.