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

[alebldn]

Dear Hung Bui,

Once again, thank you for your kindness and your attention to details. I indeed used the nrf Connect Desktop Programmer application to flash the merged.hex file onto the Dongles.

I'll try the way you just suggested, flashing only mcuboot in order to keep the CRC stable.

About the last consideration, at first I indeed tried to keep the space for the legacy bootloader minimized but quickly realized that it wasn't really an option: even if I put a smaller partition the bootloader would just use the full 0x20000 sized partition anyway.

As of today, I've restored the legacy_bootloader_storage and also renamed it to legacy_bootloader in order to avoid conflicts with the settings_storage partitions used by Zephir's settings subsystem: unless specified explicitly, the configuration would automatically look for a partition including the "settings" name. Furthermore, i decreased the number of static partitions declared in the pm_static file and added the CONFIG_BOARD_HAS_NRF5_BOOTLOADER together with CONFIG_FLASH_LOAD_OFFSET and CONFIG_FLASH_LOAD_SIZE.

Now the example kinda fully works, with the only exception of that reboot into the "Open DFU Bootloader".

I'll try to only program mcuboot right now, I'll get back to you as soon as I'm done with it.

Also: as mentioned in an edit before, the weird thing is that the device reboots correctly the first time, but goes into bootloader mode next reboot. Might this be because the reboot following the DFU over Mesh only reboots the application and not mcuboot itself?

Again, thank you for your help, it really is appreciated.

Have a good afternoon,

Ale

[Hung Bui]

Hi again, 

alebldn said:

Might this be because the reboot following the DFU over Mesh only reboots the application and not mcuboot itself?

It's kind of correct. The device reboot before the image swap happens (hence no CRC issue) the bootloader will jump to the MCUBoot and then MCUBoot swap the image. The next reset after that will run into CRC issue. 

[alebldn]

Dear Hung Bui,

unfortunately I'm coming back with bad news as I wasn't yet able to build the MCUBoot application into the Dongle to make it properly work. I'm not really confident in using this mixed environment as I'm kind of new to developing Nordic applications.

I've been trying to follow the steps in the guide you posted but it resulted in errors when building the very first step. I've been trying to use the vscode extension to build the sample "mcuboot" (compatible with the Dongle) but the result was the same:

CMake Error at /opt/nrfconnect/ncs/v2.5.0/zephyr/cmake/modules/extensions.cmake:2274 (message):
  No such file or directory: TINYCRYPT_DIR:
  '~/Desktop/NordicWorkspaces/ext/tinycrypt/lib'
Call Stack (most recent call first):
  CMakeLists.txt:40 (assert_exists)

(the sample folder's path is "~/Desktop/NordicWorkspaces/nordic_bt_dfu_workspace/zephyr")

I've been trying to move the cloned mcuboot repository around, including inside the zephyr folder but the result was the same.

I've been trying to modify the CMakeLists.txt file to replace the "get_filename_component" (changed in version 3.20 (I'm using version 3.20.5)) in order to match BOOT_DIR and MCUBOOT_DIR with the proper directories so to actually (and successfully) avoid this error, but still resulting in duplicated functions problem when linking the program.

I've also tried using the "with_mcuboot" sample to try and flash in another image and, while i got the whole project working, the mcumgr tool was stuck in the attempt, not being able to flash anything. Programmer app doesn't show anything in the device box so trying to flash images using the "enable MCUBoot" settings checked would not actually work.

Do you have any suggestions? Mind you trying to compile the sample yourself to check whether there actually are errors I'm facing? If so, do you suggest downgrading CMake to version < 3.20?

Thank you very much for your patience,

Ale

[Hung Bui]

Hi Alessandro,

I assume you have managed to build the DFU target mesh application for nRF52840 dongle. Correct ? 
If you have, then you don't need to build the MCUBoot separately. 
What you need to do is to add this file in to a child_image folder in your project to enable MCUBoot's serial recovery mode: 
6574.mcuboot.conf

It should look like this: 

Then you build your application as normal. The reason I suggested this because in the target&distributor, the MCUBoot is already built. You don't need to build MCUBoot separately as in the guide from Zephyr. 

You can find the file zephyr.hex in the build\mcuboot folder:
 

You can use this zephyr.hex in nRF Programmer to upload to the dongle. 

The change in the file I provided above is to allow serial recovery mode. Then you can continue with the instruction in the guide I provided to create the .zip file for the mesh application (build\zephyr\zephyr.hex) then upload it via mcumgr. 

Please be noted that, from what I get from mesh team, the dongle is not supported by the DFU mesh solution. We haven't tested with the dongle. It's expected that you will need to get familiar with the DFU chain and know how to adapt it to the mesh application. 

[Hung Bui]

Hi again, 
I got a tip from our team that if you want to re-flash the dongles you can get one of these cable: https://www.tag-connect.com/product-category/products/cables/10-pin-target

It will allow you to program the dongle on the pogo pins next to the P1 port. You can connect a DK to the dongle and erase nRF5 Bootloader. This way you can use the dongle as you wish. (You will need to define a new board because now the MBR and Legacy bootloader is removed)