Update from nRF5 SDK to nRF Connect SDK

RE: Update from nRF5 SDK to nRF Connect SDK

Bruno Randolf — Fri, 21 Mar 2025 16:42:41 GMT

I am using the method mentioned in that post to wipe out the flash completely and flash the new firmware based on NCS. Works like a charm!

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Thu, 25 Jan 2024 15:18:00 GMT

Thank you very much !

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Thu, 25 Jan 2024 13:23:16 GMT

I don't think you will have enough flash memory to add an immutable bootloader and use MCUBoot as a second-stage bootloader. Since MCUBoot does not include its own BLE DFU transport, there normally should not be a reason to update.

That said, it might be possible to make a mechanism to update the bootloader from the app since you have the MBR with the bootloader copy function present on the device (unless MCUBoot overlaps with the MBR params page).

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Thu, 25 Jan 2024 13:14:40 GMT

Yes exactly.

Yes I know that the MCUboot is not upgradeable: what I would like to know is in these conditions (update a device whitch is from nrf5 sdk), would it be possible to add the "immutable bootlaoder" (s0) in addition to the MCUboot in the update file to allow updating the bootloader later?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Thu, 25 Jan 2024 13:07:26 GMT

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/466003"]Yes, it was by rereading the flash that I realized what I said above.
I just had to extend the timeout of my other microcontroller (the timeout triggers the reset pin of the nrf52840) for the copy to be done without problem.[/quote]

Thank you for confirming. This means there is a critical window in the copy routine where a sudden reset could cause the SD activation to fail. The fix would likely be to remove the check. The Softdevice was already validated in the postvalidation step.

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/466003"]I'm sorry but it seems you don't understand my question.
Now I can do like you in your project (I can only have these 3 element on my device: MBR+app+MCUboot). It works and I can use MCUboot to update
with my future applications.
But if one day I want to be able to update the MCUboot to a new version, what should I do now to be able to update the MCUboot in my device?[/quote]

I understand your question now, but MCUBoot is not upgradeable.

[quote userid="4240" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465842"]The original bootloader will be replaced by the MCUBoot bootloader if the update was completed, and this bootloader is not upgradable.[/quote]

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Thu, 25 Jan 2024 13:01:58 GMT

Yes, it was by rereading the flash that I realized what I said above.
I just had to extend the timeout of my other microcontroller (the timeout triggers the reset pin of the nrf52840) for the copy to be done without problem.

I'm sorry but it seems you don't understand my question.
Now I can do like you in your project (I can only have these 3 element on my device: MBR+app+MCUboot). It works and I can use MCUboot to update
with my future applications.
But if one day I want to be able to update the MCUboot to a new version, what should I do now to be able to update the MCUboot in my device?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Thu, 25 Jan 2024 12:50:38 GMT

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465987"]We do not see it in the logs because the last logs before the restart were not indicated in the log file (it did not display logs during the copy phase). If you look at the log file, you will see that the last log before the reboot was truncated.[/quote]

It takes quite a while for the destination address to reach the SD info struct in the copy routine, so it is odd that the info structure would have been erased when there are no logs indicating that the copy routine even started. Have you done anything to confirm that this is indeed the case? E.g., by reading the flash content at 0x29004 with nrfjprog.

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465987"]I think you misunderstood my question. Now that I have successfully replaced the softdevice+app+bootloader with the app+MCUboot, what should I put in place to successfully update the bootloader later? (update MCUboot)[/quote]

As illustrated by the picture I refered to earlier, the Softdevice (zephyr app in this case) and bootloader (mcuboot) are updated after the copy routine is finished.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Thu, 25 Jan 2024 12:24:00 GMT

We do not see it in the logs because the last logs before the restart were not indicated in the log file (it did not display logs during the copy phase). If you look at the log file, you will see that the last log before the reboot was truncated.

I think you misunderstood my question. Now that I have successfully replaced the softdevice+app+bootloader with the app+MCUboot, what should I put in place to successfully update the bootloader later? (update MCUboot)

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Thu, 25 Jan 2024 12:13:15 GMT

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465978"]The problem was that since my update file had a size of 0xA9D70 bytes, the copy process overwrote the value of the magic number which was at address 0x29004 since the reboot happened more or less when he had written to the address 0x7E81b.[/quote]

The log shows that the copy routine did not start, so I don't see how the SD info struct could have been overwritten.

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465978"]You didn't answer me: to continue to be able to update the bootlaoder, what more should I do?[/quote]

The bootloader and SoftDevice should be activated simultaneously, but the activation is aborted due to the issue discussed above.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Thu, 25 Jan 2024 12:06:21 GMT

As I remember it, this is how it worked:
1. The update file was written to address 0x27000
2. The first part of the update file was copied to address 0x1000. During the copy, the nrf52840 was restarted.
The problem was that since my update file had a size of 0xA9D70 bytes, the copy process overwrote the value of the magic number which was at address 0x29004 since the reboot happened more or less when he had written to the address 0x7E81b.
So, on reboot, there was no longer a magic number at address 0x29004 since it had been overwritten.

You didn't answer me: to continue to be able to update the bootlaoder, what more should I do?

Thank you

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Thu, 25 Jan 2024 11:23:07 GMT

It appears that the problem arises in the nrf_bootloader_fw_activate() function, where SD_MAGIC_NUMBER_GET() is checked:

00> <debug> app: Enter nrf_bootloader_fw_activate
00> <debug> app: Valid SD + BL
00> <debug> app: Enter nrf_dfu_sd_bl_continue
00> <debug> app: Enter nrf_bootloader_dfu_sd_continue
00> <error> app: Source address does not contain a valid SoftDevice.
00> <error> app: SD+BL: SD copy failed

This is after the sd+bl image has been postvalidated. What doesn't make sense is why the bootloader fails to read the magic number in nrf_bootloader_dfu_sd_continue(). To debug this further, it would help if you could print the 'src_addr' before the SD_MAGIC_NUMBER_GET() check.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Wed, 24 Jan 2024 15:00:16 GMT

After the file was written to nrf52840 at address 0x27000, I had a reboot during the phase of copying the fisrt part of the file to the app partition (0x1000).
In fact, if there was a restart during the copy, afther the restart it goes into the postvalidate_sd_bl() function and since softdevice_info_ok(...) returns false (SD_MAGIC_NUMBER_GET(sd_start_addr) != SD_MAGIC_NUMBER) because the address does not is no longer the right one.

To continue to be able to update the bootlaoder, what more should I do?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Wed, 24 Jan 2024 14:43:53 GMT

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465841"]Apparently, if the reboot is done during the copy phase, it no longer continues the update.[/quote]

What phase is this, is it after the zephyr app + mcuboot bootloader has been uploaded and when the images are being copied from bank 0 to their destinations?

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/465841"]With this solution, is it still possible to update the bootloader once the memory has been overwritten by the MCUboot+app?[/quote]

The original bootloader will be replaced by the MCUBoot bootloader if the update was completed, and this bootloader is not upgradable.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Wed, 24 Jan 2024 14:39:22 GMT

Apparently, if the reboot is done during the copy phase, it no longer continues the update.

With this solution, is it still possible to update the bootloader once the memory has been overwritten by the MCUboot+app?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Tue, 23 Jan 2024 10:52:10 GMT

I'm glad to hear you were able to identify the problem. Thank you for the update. However, if the target was unexpectedly reset, I would still have expected the activation process to continue on the next reboot assuming the DFU process was completed.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Tue, 23 Jan 2024 10:47:50 GMT

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!

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Mon, 22 Jan 2024 16:09:11 GMT

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

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Mon, 22 Jan 2024 14:36:12 GMT

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?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Mon, 22 Jan 2024 10:38:28 GMT

Hi,

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

[quote user="QuentinD"]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?[/quote]

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.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Mon, 22 Jan 2024 09:25:17 GMT

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?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Fri, 19 Jan 2024 15:25:49 GMT

Hi,

For this error:

[quote user="QuentinD"]00> [00:00:10.572,052] <err> mcuboot: Protect mcuboot flash failed, cancel startup.[/quote]

Try to build mcuboot with CONFIG_FPROTECT=n. I recall there were some issues with the flash protection mechanism after relocating the bootloader to the end of flash (in nRF Connect SDK the bootloader starts at the beginning of flash).

[quote user="QuentinD"]00> [00:00:00.000,701] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors[/quote]

This suggests that the MCUBoot secondary slot is not allocated in flash. Please run the "memory report" action in VS code and post the flash partition layout here.

Best regards,

Vidar

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Fri, 19 Jan 2024 14:59:48 GMT

If I flash the app_signed.hex and zephyr.hex file to my nrf52840, I have these logs:

00> *** Booting nRF Connect SDK v2.5.0 ***
00> [00:00:00.000,213] <inf> mcuboot: Starting bootloader
00> [00:00:00.000,701] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors
00> [00:00:10.572,021] <inf> mcuboot: Bootloader chainload address offset: 0x1000
00> [00:00:10.572,021] <inf> mcuboot: Jumping to the first image slot
00> [00:00:10.572,052] <err> mcuboot: Protect mcuboot flash failed, cancel startup.

Do you know what can cause this kind of problem?

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Fri, 19 Jan 2024 10:20:55 GMT

Hi Vidar,

Thank you very much for your help: I have made a lot of progress :)

But here I still have a problem: the file that I am trying to write is not completely written in memory (the end of the file is missing) although according to the logs everything was written correctly.
Just to check that there is no problem in the bootloader code for writing large files, I tested what it would do if I had only updated the application by filling almost all the "app" partition. For this, I wrote from address 0x27000 to address 0xC2C3B (size=0x9BC3B) and everything was written correctly.

If I now send my file containing the NCS App + MCUboot to overwrite the softdevice (file of 0xA9E80 bytes), it writes in flash from the address 0x1000 to an address around the address 0x7EB00 (I say "around" since if I change the delay between sending 2 frames to the bootloader, the last written address changes (but not much)) whereas it should go up to address 0xAAE80.

Here is the memory map of my nrf52840 before the update:

mbr: 0x0 -> 0x1000
softdevice: 0x1000 -> 0x26000
app: 0x27000 -> 0xD0000 (0xA9000) -> in reality my app goes from 0x27000 to 0x98CEB
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 are the bootloader logs during the update:
devzone.nordicsemi.com/.../Test_5F00_BT840_5F00_V0.1.0.12.log

I'm trying to send these files:

devzone.nordicsemi.com/.../sd_5F00_bl.bin

devzone.nordicsemi.com/.../sd_5F00_bl.dat

This file was built from these 2 files:
devzone.nordicsemi.com/.../app_5F00_signed.hex devzone.nordicsemi.com/.../1411.zephyr.hex

Remarks:

We see that physically, the update overwrites in flash the softdevice and part of the NRF5 application with part of the NCS SDK application. On the other hand, we see this in the logs:
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x00027000, src=0x200046A0, len=64 bytes), queue usage: 1
...
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000D0E40, src=0x2000461C, len=64 bytes), queue usage: 1
Why is it indicated "0x27000" as the starting address and not 0x1000 because physically that is where it is written? Isn't the problem I'm having related to this?
I can write the entire "app" partition if I don't start writing by starting at the address of the softdevice so we already know that there is no problem writing in flash for large files and no problem writing to addresses where I have a problem.
In the logs, all the writes are marked as "success" but in reality, rereading the flash, I see that the end is not saved, do you have any idea?

RE: Update from nRF5 SDK to nRF Connect SDK

Vidar Berg — Wed, 17 Jan 2024 10:07:35 GMT

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/464549"]Ah I thought when I saw the image that we had to send an update of the app with a file which contains the NCS App and MCUboot. So you should instead do a combined update of the softdevice+bootloader (in which the softdevice update file will contain the NCS app and the bootloader update file will contain the MCUboot)?[/quote]

Correct.

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/464549"]Can we send the softdevice and after the next reboot to send the bootloader or must both be written at the same time?[/quote]

They must be written at the same time.

[quote userid="89270" url="~/f/nordic-q-a/107266/update-from-nrf5-sdk-to-nrf-connect-sdk/464549"]Does this solution require you to first go through a patched bootlaoder?[/quote]

You can include the Softdevice info structure in the zephyr app to trick the bootloader into thinking it is a valid Softdevice. See the example attached to my other devzone post for how you can include this structure.

RE: Update from nRF5 SDK to nRF Connect SDK

QuentinD — Wed, 17 Jan 2024 09:38:36 GMT

Thank you for your explanation.

Ah I thought when I saw the image that we had to send an update of the app with a file which contains the NCS App and MCUboot. So you should instead do a combined update of the softdevice+bootloader (in which the softdevice update file will contain the NCS app and the bootloader update file will contain the MCUboot)?

Can we send the softdevice and after the next reboot to send the bootloader or must both be written at the same time?

Does this solution require you to first go through a patched bootlaoder?