Update from nRF5 SDK to nRF Connect SDK

[QuentinD]

Hello,

For a month I have been trying to find a solution to update my devices which are at my customers (these devices have a bootloader, softdevice and app coming from the nrf5 SDK) to the mcuboot and app coming from the NCS SDK.

To do this, I relied on this link: https://devzone.nordicsemi.com/f/nordic-q-a/79571/dfu-update-from-nrf5-sdk-to-nrf-connect-sdk

Here are my steps:

1. I modified the secure_bootloader_uart_mbr_pca10056_debug of the nrf5 SDK so that it accepts replacing the sofdevice and the app (nrf5 SDK) with my new app (NCS SDK):
   - comments "return NRF_ERROR_INTERNAL" in the sd_activate() function of the nrf_bootloader_fw_activation.c file
   - comments "result = false;" of the if(SD_MAGIC_NUMBER_GET(sd_start_addr) of the softdevice_info_ok(...) function of the nrf_dfu_validation.c file
2. I created a file containing this bootloader patched with the softdevice and my app (nrf5 SDK):
   nrfutil settings generate --family NRF52840 --application BT840-FW-0.1.0.12.hex --application-version-string "1.0.12" --bootloader-version 3 --bl-settings-version 2 --softdevice BT840- SD-0.7.2.0.hex --key-file priv.pem bootloader_setting.hex
   mergehex --merge bootloader_setting.hex BT840-BL-0.3.hex --output boot_with_settings.hex
   mergehex --merge boot_with_settings.hex BT840-SD-0.7.2.0.hex --output boot_with_settingsAndSofdevice.hex
   mergehex --merge boot_with_settingsAndSofdevice.hex BT840-FW-0.1.0.12.hex --output firmware-BT840-HW3-SD7_2_0-BOOT3-FW1_0_12.hex
3. I uploaded this file to my nrf52840
4. To generate the update packages for the bootloader (MCUboot) and my app from the NCS SDK, I did this:
   nrfutile pkg generate --hw-version 3 --app-boot-validation VALIDATE_GENERATED_CRC --bootloader-version 4 --sd-req 0x0,0xCA,0x0100,0x0101 --bootloader Application/TA_Smart/mcuboot/zephyr/zephyr.hex - -key-file Application/child_image/key/mcuboot_private.pem BT840_update_with_boot.zip
   nrfuutil pkg generate --hw-version 3 --app-boot-validation VALIDATE_GENERATED_CRC --sd-req 0x0,0xCA,0x0100,0x0101 --softdevice Application/TA_Smart/zephyr/app_update.bin --key-file Application/child_image/ key/mcuboot_private.pem BT840_update_with_app.zip
5. I send the DFU update of the softdevice
6. Once it is finished, I send the bootloader DFU update

Here are the logs of these 2 updates:

 Test_update_to_new_sdk.log

Here is the memory map of my devices working with the nrf5 SDK:

mbr: 0x0 -> 0x1000
softdevice: 0x1000 -> 0x27000
app: 0x27000 -> 0xD0000 --------> the application uses BLE and Thread
storage: 0xD0000 -> 0xD1000
unused page: 0xD1000 + 0xE0000
ot_flash_data: 0xE0000 -> 0xE4000
bootloader: 0xE4000 -> 0xF0000
unused_page2: 0xF0000 -> 0xFE000
mbr_params_page: 0xFE000 -> 0xFF000
bootloader_settings_page: 0xFF000 -> 0x100000

Here is the content of my pm_static.yml from my project using the NCS SDK: 

mbr:
  address: 0x0
  region: flash_primary
  size: 0x1000
app:
  address: 0x1200
  region: flash_primary
  size: 0xD0E00
mcuboot:
  address: 0xE4000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1A000
mcuboot_pad:
  address: 0x1000
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x1000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0xD1000
  span: *id001
mcuboot_primary_app:
  address: 0x1200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xD0E00
  span: *id002
mcuboot_secondary:
  address: 0xD2000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x10000
settings_storage:
  address: 0xE2000
  placement:
    before:
    - mcuboot
  region: flash_primary
  size: 0x2000
mbr_params_page:
  address: 0xFE000
  region: flash_primary
  size: 0x1000
bootloader_settings_page:
  address: 0xFF000
  region: flash_primary
  size: 0x1000  
sram_primary:
  address: 0x20000000
  region: sram_primary
  size: 0x40000

Additional information:

• After updating the softdevice (step 5), my file was written between address 0x1000 and address 0xC11DF (thus overwriting the old softdevice and app). On the other hand, in the logs, I see "<debug> nrf_dfu_validation: Hash verification. start address: 0x27000, size: 0x9A1D4": is it normal that it says "0x27000" and not "0x1000"?
• If after this update, I send the bootloader (step 6), it also writes the file at address 0x1000 and not at address 0xE4000: do you know why?
• If I update the bootloader before the softdevice, I see in the logs that it starts writing from address 0x99000 (in the logs and physically): why is it at this address?
• It's obvious but of course, my project using the NCS SDK works when I use it with the immutable bootloader + MCUboot + app

Once I updated my device to MCUboot and the app from the NCS SDK, I no longer see anything in the RTT logs and I can't see which instruction the nrf52840 is stuck on.
Do you have any idea where the problem could be coming from?

Thank you

[QuentinD]

Hi,

Putting "CONFIG_FPROTECT=n" was enough: now if I flash the files directly, it works! THANKS !

On the other hand, when I send the file by DFU and then I read the flash again, I notice that it does not write the end of the file. It does erase the block in the flash but it does not write the data. During my last test, it correctly wrote the data up to address 0x7E81b in flash but after that it no longer wrote anything (it should go up to address 0x9CED3) but nevertheless in the bootloader logs all the writes are "success": do you have any idea what could be causing this problem?

Can you look at my bootloader log from my previous post to see if you see a problem?

[Vidar Berg]

Hi,

I'm glad to hear that it resolved the issue with MCUBoot not booting.

QuentinD said:

On the other hand, when I send the file by DFU and then I read the flash again, I notice that it does not write the end of the file. It does erase the block in the flash but it does not write the data. During my last test, it correctly wrote the data up to address 0x7E81b in flash but after that it no longer wrote anything (it should go up to address 0x9CED3) but nevertheless in the bootloader logs all the writes are "success": do you have any idea what could be causing this problem?

The merged Zephyr app + bootloader binary is first loaded to 0x27000. After this, the bootloader is supposed to activate the images by copying them to their respective slots. However, the activation step is skipped because the bootloader does not see the Zephyr app as a valid Softdevice:

00> <error> app: Source address does not contain a valid SoftDevice.

[QuentinD]

Yes you are right: the bootloader tries to read the softdevice ID at address 0x27000+0x2004 while the softdevice ID is at address 0x1000+0x2004.

If I read the flash during the update, I see that the bootloader writes my file starting at address 0x27000 in flash.
On the other hand, when it passes into the "sd_activate()" function, the bootloader has already copied the data from address 0x27000 to address 0x1000: this is why it does not read the correct value .

In the logs, we see this line:
00> <info> nrf_dfu_validation: SoftDevice update is a major version update. Current: 7. New: 10.
So we see that the Softdevice ID is recognized in the update file.

Is it normal that my file is at address 0x1000 instead of address 0x27000 when it comes to the "sd_activate()" function?

[QuentinD]

From the logs it looks like there is a reboot during the "Writing settings..."

[QuentinD]

The problem I had was due to the restart of the nrf52840 (restarted by the other microcontroller) while copying the file.

Now everything works: thank you!