DFU update from nRF5 SDK to nRF Connect SDK?

[FARLY7]

Hi there,

We currently have ~500 nRF52832 devices running nRF5 SDK (bootloader, S132, application). These devices are updated using the nRF5 SDK Secure Bootloader UART DFU.

I have rewritten the application firmware using NCS (nRF Connect SDK) and I would like to update these devices to NCS using the nRF5 SDK Secure Bootloader UART DFU. 

I followed some instructions included in a similar question, however I have had issues:

------------------------------------------------------------------

I am testing with Nordic example projects as much as possible to help customer support replicate any issues.

I am flashing the PCA10040 (nRF52 DK) with the 'examples/dfu/secure_bootloader/pca10040_uart_debug' application included in the latest nRF_SDK_17.0.2. This application allows me to enter UART DFU bootloader. I can test writing the included test application 'examples/dfu/secure_dfu_test_images/uart/nrf52832/blinky_mbr.zip'. This process works fine as expected (nRF5 SDK -> nRF5 SDK).

To begin testing from nRF5 SDK -> NCS:

1. I again flash the same secure_bootloader DFU example application to enter DFU mode.

2. I then follow the instructions linked here to flash the Zephyr blinky.zip application (I also add the --key-file parameter to sign it).

west build -b nrf52dk_nrf52832 zephyr/samples/basic/blinky
nrfutil pkg generate --hw-version 52 --sd-req=0x00 --application build/zephyr/zephyr.hex --application-version 1 blinky.zip --key-file private.key
nrfutil dfu serial -pkg blinky.zip -p /dev/ttyACM0

However, after the DFU seems to complete, the application does not boot (LEDs are not blinking). You can find the device DFU logs here.

I can step through the nRF5 bootloader and see that a hardfault is triggered when the bootloader eventually attempts to jump to the new application.

These are the local variable values in nrf_bootloader_app_start_final.c: jump_to_addr()

Name	Value	Location
current_isr_num	0000 0000	2000 FF84
new_msp	1136 1B36	2000 FF80
reset_handler	DB00 42B5	2000 FF7C
vector_table_address	0000 1000	2000 FF64

I suspect it is caused by the reset_handler value? This does not seem to be a valid address.

Some questions/points:

1. Flashing the Zephyr blinky example directly works fine as you would expect.
2. I also added the small change to the nRF5 bootloader that checks the SD magic number, as suggested by mtsunstrum.
3. As there is no private.key provided with the secure_bootloader DFU example applications I use my own dfu_public_key.c and private.key files to sign the bootloader and NCS Blinky application.
4. The instructions in the link provided are only included in the nRF52840 Dongle board page, they are not included in the nRF52 DK board page. Are these instructions not compatible with nRF52 DK? I see the nRF52840 comes with the open bootloader installed, when I am using secure bootloader?

[Amanda Hsieh]

Hi Sean, 

As the log (<debug> app: Running nrf_bootloader_app_start with address: 0x00001000) indicated, the app start address is 0x1000. Adding CONFIG_FLASH_LOAD_OFFSET=0x1000 to prj.conf should fix the issue. 

Regards,
Amanda 

[FARLY7]

Thanks for your reply Amanda Hsieh you beat me too it. I was in the middle of posting:

----------------------------------

I have made some progress on this..

I was able to update and run the Zephyr blinky application (no MCUboot) using the instructions above, however I needed to change the Zephyr application FLASH_LOAD_OFFSET Kconfig option from 0x0 to 0x1000. From what I've understood so far, this is to place the application after the MBR region in flash (which resides at 0x0).

I have also tested that I can re-enter the bootloader from the new application by setting the GREGRET register and then resetting the device. This allows me to continue triggering new DFU updates from the new Zephyr based application.

I am currently attempting to get the MCUboot + Application updated and running.

• Do you know if it is possible to have the MCUboot updated to become the 1st stage bootloader? Or can it only become the 2nd stage bootloader (nRF5 SDK Bootloader -> MCUboot -> Application). Could I write the MCUboot + Application to offset 0x0 (therefore overwriting the MBR)? I understand this process would prevent from recovering from a failed update.

[Amanda Hsieh]

Hi Sean, 

FARLY7 said:

Do you know if it is possible to have the MCUboot updated to become the 1st stage bootloader?

After updating with MCUboot + Application, the nRF5 bootloader will be replaced with mcuboot and you will have the MBR as the first entry point. MCUboot can be used as a 1st stage bootloader and usually is if you use the 52 series. 

 

FARLY7 said:

Could I write the MCUboot + Application to offset 0x0 (therefore overwriting the MBR)?

No,  it won't be possible. The mbr protects itself with BPROT/ACL and any unexpected resets will obviously brick the device

 

-Amanda 

[FARLY7]

Hi Amanda,

Amanda Hsieh said:

After updating with MCUboot + Application, the nRF5 bootloader will be replaced with mcuboot and you will have the MBR as the first entry point. MCUboot can be used as a 1st stage bootloader and usually is if you use the 52 series. 

I cannot get an MCUboot + Application to boot successfully. Do you have a list of steps to get this working and any additional KConfig options required?

1. I enable the CONFIG_BOOTLOADER_MCUBOOT option, and the linker options are shown as:

FLASH_LOAD_OFFSET	0xC000 (Unconfigurable, set from the .dts it seems)
FLASH_LOAD_SIZE	0x32000 (Unconfigurable, set from the .dts it seems)
ROM_START_OFFSET	0x1000

2. I then create a DFU package from the zephyr/merged.hex file and proceed as before, passing the merged.hex as an --application parameter.

3. When I perform the DFU update, I have the same error as in the original post, where the reset_vector address is all wrong and the device hardfaults.

Do I need to pass the MCUboot hex as a separate --bootloader parameter? nrfutil does not allow the combination of App + BL, these must be separate packages. I am unsure which .hex file is MCUboot, and in what order to delivery the updates.

Also, how does the nRF5 bootloader get 'replaced' by MCUboot? I don't understand this. If the Application+MCUboot is being flashed as an Application in nRF5 bootloader terms, then the bootloader is untouched. The device still boots up, checks the MBR, and then the nRF5 bootloader points it to the start of the 'Application' which is the MCUboot? Is my understanding wrong? 

Thanks a lot for your help so far!