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.

[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?

[Andrei H.]

Hi Vidar,

 In the end the nrf5sdk secure bootloader and fw app works only if I disable BLE (including jump from app to bootloader and the other way around).

 The issue is now related to BLE. I get something like:

ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:301
MPSL ASSERT: 112, 1577

[00:00:04.102,203] <err> os: ***** HARD FAULT *****
[00:00:04.102,233] <err> os: Fault escalation (see below)
[00:00:04.102,233] <err> os: ARCH_EXCEPT with reason 4

[00:00:04.102,264] <err> os: r0/a1: 0x00000004 r1/a2: 0x0000012d r2/a3: 0x0000000e
[00:00:04.102,264] <err> os: r3/a4: 0x00000004 r12/ip: 0x00000010 r14/lr: 0x00038a8f
[00:00:04.102,294] <err> os: xpsr: 0x21000018
[00:00:04.102,294] <err> os: s[ 0]: 0x20016f60 s[ 1]: 0x00018c3d s[ 2]: 0x00000070 s[ 3]: 0x00323131
[00:00:04.102,325] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x2000622b s[ 6]: 0x20006250 s[ 7]: 0x000183e9
[00:00:04.102,355] <err> os: s[ 8]: 0x20016120 s[ 9]: 0x20016160 s[10]: 0x20016140 s[11]: 0x00048419
[00:00:04.102,355] <err> os: s[12]: 0x20016f80 s[13]: 0xffffffed s[14]: 0x00000000 s[15]: 0x00000000
[00:00:04.102,386] <err> os: fpscr: 0x00000000
[00:00:04.102,386] <err> os: Faulting instruction address (r15/pc): 0x00043f1a
[00:00:04.102,416] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:04.102,447] <err> os: Fault during interrupt handling

[00:00:04.102,478] <err> os: Current thread: 0x20008678 (BT CTLR ECDH)
[00:00:05.077,697] <err> os: Halting system

Best regards

[Vidar Berg]

Hi,

Thank you for sharing the log. It shows that an assert was raised inside the precompiled MPSL library. To allow me look up which assert it is, could you please let me know the exact nRF connect SDK version you are using?

[Andrei H.]

Hi Vidar,

 I'm using NCS v2.9.3. I've found that the issue is similar if not the same as this one:
* RE: Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application 

 Including these KConfig fields makes everything work normally.

 Thanks for the help.

Best regards.

[Vidar Berg]

Hi,

I was not able to find any assert that matches this number. I have to double check with the team if I am looking in the right place. But just to confirm, if you remove these configs again, you get the same assert again: 

ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:301
MPSL ASSERT: 112, 1577 ? Does your board have the optional 32 KHz crystal mounted?

[Vidar Berg]

Are you sure you are NCS v2.9.3? The team confirmed that I was looking in the right place, which means that we don't have any assert that matches this number in this SDK version.