nRF5 SDK 17.1.0 Secure DFU Bootloader and MCUboot as second stage bootloader

[Andrei H.]

Hi,

 Can MCUboot be used as a second stage bootloader (an application from the Secure DFU Bootloader over Serial Link standpoint) to be DFU'ed to existing devices which now are updateable w/ BL + SD + APP ?

Regards.

[Vidar Berg]

Hi,

Yes, it is possible provided you have enough flash to spare. I have seen examples of this with the nrF5280 Dongle which comes pre-programmed with he nRF5 SDK Open bootloader to enable to use MCUBoot without needing to re-program the dongle with an external debug probe. Could you say a bit more about what you are trying to achieve / what the end goal with this is so I can check if there is an existing sample for this. Also, are you developing you new code using the nRF connect SDK?

Best regards,

Vidar

[Andrei H.]

Hi Vidar,

 Of course I can detail. The plan was to update devices (custom PCB based on nrf52840) which are running production fw (nRF5 SDK based apps) to be able to run zephyr based app instead, which cannot be flashed (in normal conditions). They need to be DFU'ed via nrfutil dfu usb-serial. Bootloader has prod keys so that needs to be considered, but it shoudnt be a problem. I suspect DFU in-place swaping the bootloader with MCUboot is not an option so then second best thing is having MCUboot as second bootloader. There is maybe also external flash memory compatible with the one from PCA10056 if more flash memory is really needed.

 I would like to ask for an practical example about achieving this if possible.

 

Vidar Berg said:

are you developing you new code using the nRF connect SDK?

A: yes

Kind regards.

[Vidar Berg]

Hi,

It should be technically possible to swap the original bootloader with mcuboot if your current bootloader region is big enough to fit MCUBoot configured with serial recovery enabled (it may have a bigger footprint). But I wonder if it might be better to just continue using the nRF5 SDK bootloader since you already have a working solution and then just build the Zephyr Application to start on top of the MBR at 0x1000.

Kind regards,

Vidar

I posted a proof of concept demo for updating from the nrF5 SDK to NCS here Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application but again I think the best option might be to continue with the existing bootloader in your case.

[Andrei H.]

Hi Vidar,

 This seems to work indeed.

 I've one more question, how can I trigger to stay in bootloader mode with NCS app? In order to change the FW with another one, using the nrf5_sdk bootloader mechanism w/ nrfutil ?

I've tried to add overlay:

/ {
	aliases {
		gpregret = &gpregret1;
	};
};

config:

CONFIG_REBOOT=y
CONFIG_RETAINED_MEM=y

code itself:

rc = retained_mem_clear(reg);
rc = retained_mem_read(reg, 0, buffer, sizeof(buffer));
LOG_HEXDUMP_INF(buffer, sizeof buffer, "GPREGRET:");

data[0] = 0xB1;
rc = retained_mem_write(reg, 0, data, sizeof(data));
rc = retained_mem_read(reg, 0, buffer, sizeof(buffer));
LOG_HEXDUMP_INF(buffer, sizeof buffer, "GPREGRET:");
k_sleep(K_SECONDS(3));

sys_reboot(SYS_REBOOT_WARM);
CODE_UNREACHABLE;

log

[00:00:10.067,199] <inf> btn: GPREGRET:
                              00                                               |.                
[00:00:10.067,260] <inf> btn: GPREGRET:
                              b1                                               |.                

After which the device does not stay in bootloader (it starts the app again, not as expected).

Kind regards.

[Vidar Berg]

Hi,

Please read back the value of the GPREGRET register @ 4000051c to confirm it is correctly set to 0xb1. You may also want to check if the retained_mem_* calls are returning without errors.

#include <soc.h>

...

   LOG_INFO("NRF_POWER->GPREGRET: 0x%x", NRF_POWER->GPREGRET)

Kind regards,

Vidar

[Andrei H.]

Hi Vidar,

 I've made the changes this is the output:|

[00:00:07.315,429] <inf> btn: NRF_POWER->GPREGRET: 0xb1

Also, after device has been restarted I've run the nrfutil command:

nrfutil device read --address 0x4000051C --direct

with output:

0x4000051C: 000000B1                              |....|

So this makes me thing the register was set correctly, but there is no effect from it?

Kind regards.

[Vidar Berg]

Hi,

Thanks for confirming. Not sure why the bootloader is not entering DFU mode on startup then. Do you see if the nRF5 SDK bootloader is being entered on startup?