DFU update from nRF5 SDK to nRF Connect SDK?

RE: DFU update from nRF5 SDK to nRF Connect SDK?

Amanda Hsieh — Thu, 04 Nov 2021 07:59:35 GMT

Hi Sean,

1. I got the INSUFFICIENT RESOURCES error while updating DFU with your procedure. To get rid of the error, I have to modify FLASH (rx) : ORIGIN = 0x78000 to 0x64000. I think it might cause by the bootloader sizes different. The current space for the bootloader is insufficient for the new mcuboot.

2. Yes, you can modify the bootloader address to achieve that. Make sure the bootloader address is the same as the mcuboot address.

-Amanda

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Wed, 03 Nov 2021 14:27:10 GMT

[quote userid="77782" url="~/f/nordic-q-a/79571/dfu-update-from-nrf5-sdk-to-nrf-connect-sdk/337190#337190"]You can use the nRF52832_UART_pm_static.yml under the NCS_blinky folder, but you have to modify the FLASH_START of the nRF5 bootloader to 0x64000 the same as the mcuboot address. Here is my test file. dfu_nRF5_NCS_over_DFU_1102.zip I have added pca10040_s112_ble and pca10040_s112_ble_debug under secure_bootloader with FLASH_START at 0x64000 and updated with NCS_blinky and NCS_peripheral_uart generated by nRF52832_UART_pm_static.yml without issue. [/quote]

Ok thank you, I will test your project tomorrow and let you know. I have two questions:

1. From the .zip you shared a few weeks ago, I checked the file 'pca10040_s132_ble/armgcc/secure_bootloader_gcc_nrf52.ld' and the bootloader address is set to FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000. The pm_static.yml file from the NCS_Blinky project has set the MCUBoot address to 0x64000. However, this configuration works fine when I was testing with the UART DFU method. Do you know why it works and why the BLE DFU is different and requires this change?

2. In my production devices, the bootloader begins at 0x76000 and has a length of 0x8000 (32KB). The MCUBoot bootloader compiles a 'Used size' of just less than 32KB, however, the 'Region size' is 48KB. In the scenario where the MCUBoot bootloader does not fit into this area, is it possible to first update the secure_bootloader to move it slightly and increase its flash allocation so MCUBoot can fit in the next update?

Thanks,

Sean

RE: DFU update from nRF5 SDK to nRF Connect SDK?

Amanda Hsieh — Wed, 03 Nov 2021 08:01:15 GMT

Hi,

[quote user="FARLY7"]Do you know what is causing these differences (version number missing a .0, bootable=false, flags empty, hash unavailable)?[/quote]

I'd recommend asking questions regarding the mcumgr in their slack channel, as described in the repos readme.md:

Our Slack channel: https://mynewt.slack.com/messages/C7Y3K0C2J

We have little to no knowledge about this in tech support.

[quote user="FARLY7"]There was not an equivalent BLE file for the nRF52832, only the nRF52840. Was there a reason for this?[/quote]

If one were to modify MCUBoot’s settings then the size of MCUBoot will change. In case the size of MCUBoot is larger than the allocated partition size, the value of 0x18000 would have to be increased. Similarly, if MCUBoot’s size shrinks due to different build options, then the value of 0x18000 can be reduced.

[quote user="FARLY7"]Would providing a 'BLE version' of the pm_static.yml for the nRF52832 be the solution?[/quote]

You can use the nRF52832_UART_pm_static.yml under the NCS_blinky folder, but you have to modify the FLASH_START of the nRF5 bootloader to 0x64000 the same as the mcuboot address. Here is my test file. devzone.nordicsemi.com/.../dfu_5F00_nRF5_5F00_NCS_5F00_over_5F00_DFU_5F00_1102.zip I have added pca10040_s112_ble and pca10040_s112_ble_debug under secure_bootloader with FLASH_START at 0x64000 and updated with NCS_blinky and NCS_peripheral_uart generated by nRF52832_UART_pm_static.yml without issue.

-Amanda

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Mon, 01 Nov 2021 08:16:40 GMT

Hi Amanda,

Just adding to my reply I sent a few days ago.. as I was successful in updating App + MCUBoot over UART I have now began testing the same process over BLE.

Unfortunately, when I attempt to update over BLE I am getting an INSUFFICIENT RESOURCES error from the device. From reading online this means there is not enough space on the device for the update?

I am using the nRF52832_XXAA (512KB flash)
I tried flashing the smaller (peripheral-only) S112 SoftDevice.
I tried updating with the NCS_Blinky application and not my own, so it is much smaller.
There is a line in the uart_log_recovery.conf file 'CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x18000'. I don't understand why the partition size is set to 98KB when the MCUBoot compiles down to 37KB?
The output from the NCS_blinky build shows the MCUBoot region size as 112KB, could this be reserving unused memory in the update package that is making the image seem larger and unable to fit?

[258/258] Linking C executable zephyr/zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 37476 B 112 KB 32.68%
SRAM: 25952 B 64 KB 39.60%
IDT_LIST: 0 GB 2 KB 0.00%
[147/165] Linking C executable zephyr/zephyr_prebuilt.elf

[154/165] Linking C executable zephyr/zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 16636 B 243200 B 6.84%
SRAM: 5376 B 64 KB 8.20%
IDT_LIST: 0 GB 2 KB 0.00%
[165/165] Generating zephyr/merged.hex

Since the NCS_Blinky + MCUBoot application is pretty small, I don't think it is a resources issue? Could it be something to do with the flash layout defined in the pm_static.yml file? I am using the nRF52832_UART_pm_static.yml file included in your NCS_blinky folder. There was not an equivalent BLE file for the nRF52832, only the nRF52840. Was there a reason for this? Would providing a 'BLE version' of the pm_static.yml for the nRF52832 be the solution?

Thanks again for your help so far.

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Thu, 28 Oct 2021 14:08:51 GMT

Hi Amanda,

Thanks for all this information. I have been working on this for the past 1-2 weeks and I can now successfully replace the nRF5 secure_bootloader with MCUBoot and Zephyr application. I have only tested this over serial so far, I will try and test over BLE soon.

My update process has been:

(Original app and secure_bootloader already exist on the device).
Update secure_bootloader with secure_bootloader_patched by issuing a BL DFU update.
Update the device with my Zephyr app + MCUboot by issuing an SD + BL DFU update.

I have one question/possible issue. After performing a DFU update using secure_bootloader to replace it with Zephyr app + MCUBoot, when I use mcumgr to list the images on the device, I get:

Images:

image=0 slot=0

version: 0.0.0.0

bootable: false

flags:

hash: Unavailable

Split status: N/A (0)

Compared to when I flash an application directly using 'west flash'

Images:

image=0 slot=0

version: 0.0.0

bootable: true

flags: active confirmed

hash: 38771b4b3c567a292ab579e7e0f8709857c241ef4d890bde267637a60cc74279

Split status: N/A (0)

Do you know what is causing these differences (version number missing a .0, bootable=false, flags empty, hash unavailable)?

The application runs fine, even between resets (so is 'booting').
I am using the nRF52832_UART_pm_static.yml file included in the NCS_blinky project you shared.
Updating the app again from the app_update.bin does not change the info, and still works fine.
The app doesn't call any 'image ok' type API after booting to signal that the image is ok to continue running.

Thanks,

Sean

RE: DFU update from nRF5 SDK to nRF Connect SDK?

Amanda Hsieh — Fri, 24 Sep 2021 06:17:25 GMT

Hi Sean,

Sorry for the delay.

You can use partition manager to locate mcuboot. The memory layout could be defined in pm_static.yml as

FOTA from nRF5 SDK to NCSv1.6.1 over uart test

devzone.nordicsemi.com/.../1033.dfu_5F00_nRF5_5F00_NCS_5F00_over_5F00_uart_5F00_0928.zip

Some quick notes about the test:

This test updats MCUboot and the zephyr application image in one go by calling it a Softdevice+bootloader (SoftDevice and bootloader) update. This to be able to overwrite the softdevice with the zephyr app. However, it did require some minor modifications to the existing bootloader to make it accept zephyr application as a Softdevice image.Use dfu_nRF5_NCS\nRF5_SDK_17.0.2_d674dde to build and run the bootloader.
There are several *_pm_static.yml for nRF52832/52840 ble/USB/UART. Rename the "pm_static.yml" to pm_static.yml for your target.
The flash protection mechanism in MCUboot assumes that the mcuboot_primary slot is always placed after the mcuboot partition. It disabled flash protection to get around this limitation.Disabled mcuboot flash protection is as the config under
Modify the OVERLAY_CONFIG path in build_blinky.bat and run the script to build NCS_blinky_over_uart project.
The mcuboot image is zephyr.hex under build\mcuboot\zephyr and you can use app_update.bin to generate the updated package.
After updating withNCS_blinky_over_uart, you can use mcumgr to update via DFU. See this tutorial device-firmware-update-dfu-with-mcuboot-bootloader and this thread. If you update with NCS_peripheral_uart, you can refer to Bluetooth: Peripheral UART to test.

[quote user="FARLY7"]how does the nRF5 bootloader get 'replaced' by MCUboot?[/quote]

It's not updated as an application+bootloader, but rather Softdevice + bootloader. SoftDevice and bootloader

-Amanda

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Wed, 22 Sep 2021 08:22:34 GMT

Hi Amanda,

Do you have any information on how it is possible to replace the nRF5 Bootloader with MCUBoot from NCS?

Please see my other reply on how I have unsuccessfully attempted this already.

Thanks,

Sean

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Tue, 14 Sep 2021 12:09:43 GMT

Hi Amanda,

[quote userid="77782" url="~/f/nordic-q-a/79571/dfu-update-from-nrf5-sdk-to-nrf-connect-sdk/329416#329416"]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. [/quote]

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!

RE: DFU update from nRF5 SDK to nRF Connect SDK?

Amanda Hsieh — Tue, 14 Sep 2021 11:42:59 GMT

Hi Sean,

[quote user="FARLY7"]Do you know if it is possible to have the MCUboot updated to become the 1st stage bootloader?[/quote]

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.

[quote user="FARLY7"]Could I write the MCUboot + Application to offset 0x0 (therefore overwriting the MBR)?[/quote]

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

-Amanda

RE: DFU update from nRF5 SDK to nRF Connect SDK?

FARLY7 — Tue, 14 Sep 2021 08:04:13 GMT

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.

RE: DFU update from nRF5 SDK to nRF Connect SDK?

Amanda Hsieh — Tue, 14 Sep 2021 07:56:39 GMT

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