Migrating from nRF SDK 17.0.2 to nRF connect SDK

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Ramachandra Reddy — Mon, 28 Aug 2023 12:25:17 GMT

Please close the ticket or let me know how to close it.

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Ramachandra Reddy — Mon, 28 Aug 2023 12:23:20 GMT

Hi Bui,

Thanks a lot for all the support, the task is completed.

Reagrds,

Ram

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Hung Bui — Thu, 03 Aug 2023 14:45:25 GMT

Hi Ram,

As far as I can see Vidar included the .hex just as a reference (so that you can test). But you should generate the .hex by your own when you compile the application (or the example). Mcuboot hex file will be generated automatically when you generated the application hex.

If you want LDO instead of DCDC you can add your overlay inside \ncs_application\peripheral_lbs_with_dfu\child_image\mcuboot\boards

Same with application, you should put the overlay of your board inside boards folder.

Please be aware that the solution provided by Vidar will replace the nRF5 SDK bootloader. So you will only be able to do DFU via MCUBoot after the DFU update.

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Ramachandra Reddy — Wed, 02 Aug 2023 15:05:55 GMT

Hello Bui,

Yes as you said i have integrated the smp server to upload the image vusing dfu by fallowing the tutorial Add DFU support to your application and it is working fine.

I am able to able the device and able to perform the dfu update using smp server.

The problem is the device which are there in the field has nRF bootloder in it and need to update the NRF connect sdk build.

I have used the below command to manupilate the memory information about soft device and bootloader

cmd: nrfutil pkg generate --bootloader C:/Users/RamachandraReddy/Downloads/dfu_from_nrf5_SDK_to_NCS_demo/ncs_application/peripheral_lbs_with_dfu/build/mcuboot/zephyr/zephyr.hex --bootloader-version 1 --hw-version 52 --sd-req 0xA9,0xCA,0xAE,0xB6 --softdevice ../build/zephyr/app_signed.hex --sd-boot-validation NO_VALIDATION --app-boot-validation NO_VALIDATION --key-file ../secure_dfu_keypair/dcs_private.pem ../output/BLE_FW_OTA_3.0.0_BL.zip

i am able to generate the required DFU file and able to update it.

Here come the actual problem

The bootloder which is used in the above command (highlighted in red) i got from the sample project dfu_from_nrf5_SDK_to_NCS_demo from devzone(link: devzone.nordicsemi.com/.../hang-with-nrf5-sdk-17-1-0-bootloader-and-nrf-connect-sdk-2-1-0-application)

, if i use the same mcuboot hex file then my development baord is working, but looks like the dcdc is not disable in the build because of which my custom board is not coming up,

I tried to copy the entire folder and compile my self and generted the mcuboot hex file. using this the board is not coming up.

I looked into the hex file data, it looks like both the files has lot of difference and doesnt match.

Could you please let me know how i can reprodue the mcuboot file same as one which is there it the sample project.

I am attaching both the sample and mygenerted file for reference.

1. sample file devzone.nordicsemi.com/.../8508.zephyr.hex

2. My file : devzone.nordicsemi.com/.../8508.zephyr.hex

This is very much on priority since all our device need to upgrade to new firmware, Please support it

I am also attaching the sample project which is downloaded for your reference.

code: devzone.nordicsemi.com/.../ncs_5F00_application.rar

I want to know how i can reproduce the same mcuboot hexpath: C:\Users\RamachandraReddy\Downloads\dfu_from_nrf5_SDK_to_NCS_demo\ncs_application\peripheral_lbs_with_dfu\build\mcuboot\zephyr\zephyr.hex) file which is there in the sample project.

which version of sdk is used to generate it.

Regards,

Ram

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Hung Bui — Wed, 02 Aug 2023 07:34:53 GMT

Hi Ram,

Could you please describe how exactly you combined MCUBoot and nRF5 SDK bootloader ? How the DFU process works now ?

Please be aware that MCUboot and application doesn't run at the same time. What you integrated into the application most likely is the SMP server to receive image. The MCUBoot only does booting and image swapping.

I would need to have the full picture of your implementation to tell why you have larger memory footprint.

The simplified memory layout for MCUBoot would look like this:

New image is stored on the MCUBoot Secondary and will be swapped with MCUBoot primary (current app) by MCUBoot when rebooting if it marked for "confirm" or "test".

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Ramachandra Reddy — Wed, 02 Aug 2023 06:57:39 GMT

HI Bui,

Thanks for your reply, I made the changes and it is working fine now.

i have one doubt about the memory usage by bootloader.

Before using mcuboot my application use to occupy only 30% of memory but after including the MCUboot it occupied 75% of memory.

If it take 75% then how where do we get space for slot 1 for swiping the program during DFU.

Could you please share any information about the memory structure before and after adding mcuboot

Regards,

Ram

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Hung Bui — Tue, 01 Aug 2023 14:22:44 GMT

Hi Ram,

My suggestion is to get familiar with the OTA DFU in NCS before you move to the next step is onto how you can have both DFUs support in your application.
Please try follow the guide here: Add DFU support to your application , please test with a normal NCS application.

Also make sure you do a full erase before testing. Do you have 32kHz crystal on your custom board ?

After you have verified that you can run MCUboot on your custom board you will need to decide how you want to have both nRF5 bootloader and the MCUBoot on your board.

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Ramachandra Reddy — Mon, 31 Jul 2023 12:17:51 GMT

Hi Hellesvik,

Thanks for your early response.

Also remember to create a partition for the softdevice that you do not use : How i can create the partition for this

Also i am facing the weird scenario with my custom board.

I have included the bootloader by setting the below flag in prj.cfg file

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# Ensure an MCUboot-compatible binary is generated.

CONFIG_BOOTLOADER_MCUBOOT=y

After build the i can see the below file in the build path got generated which confirms the bootloder is enabled.

I have loding the merged.hex file from nrf connect programmer.

The development board is booting up without any issue and the board is advertising but the custom board is not booting up i am not sure why the issue is, because without enabling the mcuboot (CONFIG_BOOTLOADER_MCUBOOT=y) both development and custom board is working fine, could you please let us know the problem here.

Regards,
Ram

RE: Migrating from nRF SDK 17.0.2 to nRF connect SDK

Sigurd Hellesvik — Thu, 27 Jul 2023 11:06:49 GMT

Hi.

[quote user=""] 1. Is there a way where i can use the old bootloder to upgrade the new connect SDK application code(without MCU Boot)[/quote]

Yes. See One bootloader to rule them all , where I have discussed this with another custtomer

[quote user=""] 2. how can i achieve both old bootloader and MCUboot loader together.[/quote]

Why would you need this?

[quote user=""] 3. How can i remap the nRF connect application to load and run from required memory location while building using VS code.[/quote]

CONFIG_FLASH_LOAD_OFFSET

Also remember to create a partition for the softdevice that you do not use

[quote user=""] 4. How can i view the partition information like below to check the memory details[/quote]

You can either use VS Code Memory Report or "west build -t partition_memory_report"

[quote user=""] 5. What is the best way to do upgrade the NCS firmware using old bootloader.[/quote]

See 1.

Regards,
Sigurd Hellesvik