nRF Dongle 52840 DFU over Mesh

[alebldn]

Dear fellow Developers,

I'm finishing a project where I have to implement the DFU over Mesh protocol in a series of firmware running on a nRF 52840 Dongle. While I was able to solve most of the problems so far, there's still a major one that is bugging me:

I managed to complete the whole procedure of Device Firmware Update over Mesh, where a Distributor was able to distribute the Firmware to several targets, successfully the vast majority of times. The device remains provisioned, the services offered show the correct update (so to verify, together with the version number that the service is indeed updated), and I'm able to use them seamlessly.

Problem is, whenever the update is completed, if I detach the nRF 52840 Dongle from its USB port (hence turning it off) it always reboots in "Open DFU Bootloader" mode. Unplugging and re-plugging the device doesn't produce any effect.

I also tried the following directive so to apply the firmware at a later stage, but this was unsuccessful. 

mesh models dfd start 0 0 0 0

mesh models dfd apply

I feel like there are major incompatibilities between the Dongle Bootloader and MCUBoot and I was wondering if any of you have any idea on how to overcome these.

Thank you in advance,

Ale

[Hung Bui]

Hi Ale, 
The problem with the dongle is that by default it has the original bootloader from nRF5 SDK, in addition to the MCUBoot bootloader that you have flashed (I assume). 

The nRF5 bootloader on each booting up will check and verify if the firmware (MCUBoot + your application) remain the same by using hash check. 
In your case the distributor receive the image and maybe update the firmware when you do mesh DFU update. The NRF5 bootloader doesn't recognize this change and will switch to bootloader mode because it detects a hash check fail. 

My suggestion is either to use a nRF52 DK as the hardware backend (there isn't a nRF5 bootloader on it) or solder a header on the  P1 port on the dongle to erase the bootloader and use it as a DK. You may then need to create a new board and re-configure the memory of the dongle similar to what on the DK. 

[alebldn]

Dear Hung Bui,

Thank you very much for your kind answer. We will work towards your solutions: either having a DK as Distributor or by removing the Dongle Bootloader.

Just for curiosity: do you know whether there is a way to update the hash in software so to have the Dongle properly load?
This is just out of curiosity as I'm pretty sure the SOC won't have the DFU Bootloader therefore we won't have that kind of problems in production.

If you don't know, don't worry: I'll try to do some research myself anyway in the meantime (and, if I find any solution, I'll post it here :) )

Thank you again and kind regards,

Ale

EDIT: I still haven't researched the topic yet but I thought a little bit about it: the weird thing is that in order for the Firmware to be updated, the Dongle does indeed reboot successfully. So, there's an inconsistent situation in which the first reboot successfully passes the hash check, but all the subsequent ones fail.

[Hung Bui]

Hi Ale, 

It can be difficult to update the hash as I am not certain on if  it's the image that the distributor receiving causing the issue or it's the firmware of the distributor being updated causing the issue. 

It would be quite simple to disable CRC/hash check in the bootloader code, but you would need to be able to reflash the bootloader. 

[alebldn]

Dear Hung Bui,

a quick update: re-trying the protocol with a DK as distributor and Dongles as targets produces the very same result. To be honest I feel like I misunderstood you: did you mean to use DKs as Targets? Unfortunately we can't as of today: we have ordered a couple hundred Dongles to perform a test and we're looking for solutions involving those devices.

I also gave a couple tries changing the metadata stored in the distributor in the preparation phase but, once again, to no success at all.

As a last resort we'll delete completely the nrf5 DFU Bootloader but it would be nice to find a patch to this.

I'll keep working on it.

Have a good evening,

Ale

[Hung Bui]

Hi Ale, 

Sorry that I missed the part that you use the dongle on all of your devices. I thought that you only use the dongle on the distributor but not on the target. 

The dongle is not a development platform so we don't suggest to use it in the initial phase of development. I agree that it's a good device on mass testing but the correct behavior should be verified before you start mass testing. 

Soldering hundreds of header on the dongle can be an issue.
My assumption is that when you flash the dongle with your application, you were using the merged.hex file that contains both the MCUBoot and the mesh application, is it correct ? Did you flash it via the nrf Connect Desktop Programmer application ? 

If it's the case, it explain why the Legacy Bootloader complained about CRC. 

What you need to do is instead of flashing the MCUBoot and application merged, you instead only flash the MCUBoot and then after that use MCUBoot recovery mode to receive the Mesh application. This way the Legacy Bootloader only check the MCUBoot, not the application when booting up. 
Please take a look at the documentation here: https://docs.zephyrproject.org/latest/boards/arm/nrf52840dongle_nrf52840/doc/index.html#option-2-using-mcuboot-in-serial-recovery-mode

You can use dfu_application.zip to flash the application with mcumgr

Maybe not related but I looked at this ticket from you: Error when building BT mesh DFU OTA Target on Dongle 52840 (struct.error: ushort format requires 0

I saw that you have modified legacy_bootloader_storage from 0xe0000 to 0xe8000. 
Do you have an explanation for that ? 
The legacy bootloader starts at 0xe0000 not 0xe8000, by configure that you are risking overwriting the legacy bootloader.