How to update the MCUboot in nRF Connect on nRF52840DK

[RAS_ID]

Hi,

I press Button 1 and Reset to put the nRF52840 DK in to DFU mode that is programmed with a immutable bootloader (B0), mcuboot, and application. This works well to update the application (app_update.bin) using mcumgr over USB. However, during the mcuboot update (signed_by_mcuboot_and_b0_s1_image_update.bin), the application area is over-written and the application enters in a infinite loop after reset. I verified the over-write by reading the flash memory using the nRF programmer. 

Since mcumgr doesn't accept an address or slot parameter, I think the DFU mode is initialized with the application address. 

Are there different ways to enter the DFU mode to update the application and to update the mcuboot?

Thanks,

Ram

[Sigurd]

Hi,

I find it strange that the mcuboot update affected the application area in that way.

What command did you use with mcumgr, and how does your prj.conf file look like ?

Did you try with signed_by_mcuboot_and_b0_s0_image_update.bin as well?

What does the mcumgr image list command return?

[RAS_ID]

Hi,

Thanks for your reply!

I use the following command to program the flash.

$ mcumgr --conntype serial --connstring="COM14" image upload build/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin     -mcumgr command used to program the flash.

63.82 KiB / 63.82 KiB 100.00% 2.92 KiB/s 21s01s                           -the numbers changes during programming
Done                                                                                                    -once programming is done.

and, application prj.conf is given below with default prj.conf for the mcuboot

CONFIG_GPIO=y
CONFIG_SECURE_BOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_BUILD_S1_VARIANT=y

Memory partition looks like as given below

immutable bootloader starts at 0

S0 starts at 8000

S1 starts at 19000

App starts at 2A000

When I compare the files read after programming, I see the following

After programming with app_update.bin, no difference except at the end of the file.

After programming with signed_by_mcuboot_and_b0_s1_image_update.bin, the differences start at 2A000. I also  recorded that the read file size is 100KB larger than the original file.

Please let me know if I could provide any other details.

Thanks

Ram

[RAS_ID]

Hi,

Any update on the mcuboot update and method of entering the DFU mode for it is well appreciated.

Thanks,

Ram

[Sigurd]

Hi,

Unfortunately, DFU of the MCUBoot is currently not supported by mcumgr. You are correct, it doesn't accept an address or slot parameter, and is initialized with the application address. There are some related activity ongoing around this (- mcumgr/SMP support for recognizing which image need to be upload (to be defined)) in this PR: github.com/.../27673

RAS_ID said:

Are there different ways to enter the DFU mode to update the application and to update the mcuboot?

Unfortunately, I don't think there are other options/tools available. Sorry for the inconvenience.

[RAS_ID]

Thank you very much!

I hope there will be solution soon.

One more question. If I program signed_by_mcuboot_and_b0_s0_image_signed.hex (or _b0_s1_) using the nRF programmer, it should work because the hex file has the address. But, it is not working.

I have noted that the signed_by_mcuboot_and_b0_s0_image_signed.hex (or _b0_s0_) is loaded at 0x8000 (0x19000), not at 0x8200 (0x19200) as expected. The pp_signed.hex is loaded at 0x2A200.        

Is the address a reason for the mcuboot update not working with the programmer? Overall image size has not changed (verified by reading the image in the programmer)

Thanks,

Ram