Implement bootloader in NCS SDK

[QuentinD]

Hello,

Until now I was working on an application based on the nRF5 SDK: it is this application that is used by my customers.
Now I would like to use the NCS SDK to continue to have the latest features and bug fixes.

Here I almost finished redeveloping my new application (based on NCS SDK) to work like my old one (based on nRF5 SDK) but I have a problem with the bootloader...

My board (contains an nrf 52840) has no buttons and no external memory (so I will have to overwrite existing code when I do an update) but does have a UART.
I need to be able to update the application but also the bootloader.

Here are my questions:

• I think I have to go into recovery mode to be able to update in this situation? But how can I do it if I don't have a button?
• The update files will be sent by another microcontroller on the board via the uart: can you tell me more about what I need so that the other microcontroller can communicate with the nrf 52840 to send the files to the bootloader? (files ? protocol ?)
• Is it possible to update a device that would work with the nRF5 SDK (secure_bootloader_uart_mbr_pca10056) to keep the old bootloader but updating the softdevice+app with the new application (NCS SDK)?

THANKS

[AHaug]

Hi,

I think I have to go into recovery mode to be able to update in this situation? But how can I do it if I don't have a button?

One option is to use "serial recovery with wait", 

A colleague of mine has written this repository with samples, where you the serial recovery samples containing samples for serial recovery using both the waiting and mcumgr method and regular UART serial recovery. I suggest you have a look at these samples to see if they fit your project or if you're able to tailor them to your project

The update files will be sent by another microcontroller on the board via the uart: can you tell me more about what I need so that the other microcontroller can communicate with the nrf 52840 to send the files to the bootloader? (files ? protocol ?)

I recommend you to have a look at devzone.nordicsemi.com/.../doing-an-fota-via-ble-using-a-nordic-development-kit

Is it possible to update a device that would work with the nRF5 SDK (secure_bootloader_uart_mbr_pca10056) to keep the old bootloader but updating the softdevice+app with the new application (NCS SDK)?

Yes, but there are things you will have to take in mind. I recommend you to have a look at  One bootloader to rule them all which refers to a sample created by a colleague of mine showing how to port a nRF5 app to become a NCS app  Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application . This case, https://devzone.nordicsemi.com/f/nordic-q-a/100639/nrf5340-multi-image-dfu-update-over-ble-remote-error-in-value-3 does also to some extent explain some of the procedure

Let me know if this is enough to get you started! 

Kind regards,
Andreas

[QuentinD]

Hello,

Thank you very much for your answer.

I've been working on this for 2 weeks but unfortunately I still have problems...

Here at the moment, I'm trying to find a way to update the devices that are with my customers (with the nRF5 SDK) so that it's not too complicated for us and for them to manage the updates of old devices and new ones (with NCS SDK). I think the simplest solution would be to manage to only update the app of the devices that are with my customers (therefore keeping the old bootloader and the softdevice present in the devices).

To do this, I tried to do like Vidar Berg with his project 2273.peripheral_lbs.zip (devzone.nordicsemi.com/.../hang-with-nrf5-sdk-17- 1-0-bootloader-and-nrf-connect-sdk-2-1-0-application) but unfortunately there must be things I forgot because it doesn't work.

When I compile my project and flash it, it works on my device. On the other hand, if I send the update to a device working with the nRF5 SDK, it accepts the update but afterwards it is blocked.

Here are the problems I'm seeing that I don't know how to fix:

- In the prj.conf file of my project, I put "CONFIG_FLASH_LOAD_OFFSET=0x27000" but it is the value 0xC000 which is put (I have a warning for that in the logs).

- In my mcuboot.cong file in the child_image folder, I added "CONFIG_SINGLE_APPLICATION_SLOT=y". Despite this, I have to provide memory in my pm_static.yml file for mcuboot_secondary otherwise I get a compilation error: do you know why?

Here are my DFU logs:

3312.test.log

Here is my \Application\boards\pm_static_nrf52840dk_nrf52840.yml:

app:
  address: 0x10200
  region: flash_primary
  size: 0xdfe00
mcuboot:
  address: 0x0
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x1200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xD0000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xcfe00
  span: *id002
mcuboot_secondary:
  address: 0xE0000
  end_address: 0xF0000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x10000
settings_storage:
  address: 0xf0000
  end_address: 0x100000
  region: flash_primary
  size: 0x10000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Here is my \Application\child_image\mcuboot.conf:

CONFIG_UART_CONSOLE=n
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y

CONFIG_FPROTECT=n #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.

#CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x18000
CONFIG_PARTITION_MANAGER_ENABLED=y

# The build won't fit on the partition allocated for it without size
# optimizations.
CONFIG_SIZE_OPTIMIZATIONS=y

# Serial
CONFIG_SERIAL=y
CONFIG_UART_CONSOLE=n
CONFIG_UART_LINE_CTRL=y

# MCUBoot serial
#CONFIG_MCUBOOT_SERIAL=y
#CONFIG_BOOT_SERIAL_UART=y

# Config logger
CONFIG_LOG=y
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_BACKEND_RTT=y

#-------------------------------------------------------------

# Declare for single slot and partition size for MCUBoot
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
CONFIG_SINGLE_APPLICATION_SLOT=y

CONFIG_BOOT_SIGNATURE_KEY_FILE="mcuboot/key/mcuboot_private.pem"  # add a signature key file to this bootloader. This option only accepts the private key of an ECDSA key pair, as build system scripts automatically extract the public key at build time. The file path is relatively to the application directory.
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

Here is my \Application\boards\nrf25840dk_nrf52840.overlay:

/* Copyright (c) 2020 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

/ {
	/*
	* In some default configurations within the nRF Connect SDK,
	* e.g. on nRF52840, the chosen zephyr,entropy node is &cryptocell.
	* This devicetree overlay ensures that default is overridden wherever it
	* is set, as this application uses the RNG node for entropy exclusively.
	*/
	chosen {
		zephyr,entropy = &rng;
	};
};
&adc {
	status = "disabled";
};
&uart1 {
	status = "disabled";
};
&pwm0 {
	status = "disabled";
};
&i2c0 {
	status = "disabled";
};
&spi0 {
	status = "disabled";
};
&spi1 {
	status = "disabled";
};
&spi2 {
	status = "disabled";
};
&spi3 {
	status = "disabled";
};
&qspi {
	status = "disabled";
};
&usbd {
	status = "disabled";
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};
};

&uart0_default {
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 2)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};
};

&uart0_default {
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 2)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 2)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};
};

&uart0_default {
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 1)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_default {
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 2)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 2)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};
};

&uart0_default {
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 1)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&arduino_adc {
    io-channel-map = <0 &adc 1>, <1 &adc 2>, <2 &adc 4>, <3 &adc 5>, <4 &adc 6>, <5 &adc 7>;
};



/delete-node/ &scratch_partition;
/delete-node/ &storage_partition;


// Place storage partition below nRF5 Bootloader. The bootloader starts at 0xf8000 in this case.
&flash0 {
    partitions {
        storage_partition: partition@f5000 {
            label = "storage";
            reg = < 0xf5000 0x3000 >;
        };
    };
};

Here is my prj.conf of my Application:

#
# Copyright (c) 2020 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# nRF board library
CONFIG_DK_LIBRARY=y

CONFIG_MBEDTLS_SHA1_C=n
CONFIG_FPU=y # Allow to process float (double) numbers
CONFIG_ASSERT=y

# Enable the UART driver
CONFIG_UART_INTERRUPT_DRIVEN=y #UART in interrupt mode
CONFIG_SERIAL=y

# Enable ring buffer
CONFIG_RING_BUFFER=y

# Add Bootlaoder to the application
# CONFIG_SECURE_BOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y # add MCUboot as upgradable bootloader 

CONFIG_IMG_MANAGER=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_FLASH_LOAD_OFFSET=0x27000

# After you upload a new image and reset the development kit, MCUboot attempts to boot the secondary image. If this image has, in order of precedence, a major, minor, or revision value that is lower than the primary application image, it is considered invalid and the existing primary application boots instead.
# The optional label or build number specified after the + character is ignored when evaluating the version. An existing application image with version 0.1.2+3 can be overwritten by an uploaded image with 0.1.2+2, but not by one with 0.1.1+2.
CONFIG_MCUBOOT_IMAGE_VERSION="0.1.0+0"

And finaly, here are my partitions:

app:
  address: 0x10200
  region: flash_primary
  size: 0xdfe00
mcuboot:
  address: 0x0
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x1200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xD0000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xcfe00
  span: *id002
mcuboot_secondary:
  address: 0xE0000
  end_address: 0xF0000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x10000
settings_storage:
  address: 0xf0000
  end_address: 0x100000
  region: flash_primary
  size: 0x10000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Here I only put the MCUboot to simplify but then I would like to add the CONFIG_SECURE_BOOT.

Thanks for your help !

[QuentinD]

Hi,

Thank you for your follow-up.

Haven't received a response yet?

[AHaug]

Hi,

Apologies for the delayed response time

QuentinD said:

If I do the upload command without the "-n 2", it overwrites my application (mcuboot_primary). So that's why I put "-n 2" so that the application is not deleted and that it puts the bootloader file in the only partition that I have access to (mcuboot_secondary).

I believe that something might be wrong with your partitioning which causes the update image for the bootloader to be uploaded in the primary application slot if you don't use -n 2. This is what your partitioning should look like if you have a firmware with an updatable application and updatable bootloader in NCS (sample found here). Here you can see that the there is a s0 and s1 partition which is intended for the updatable bootloader. 

QuentinD said:

My partitions:

I see that you state that you have them here in this reply, but could you also navigate to the build folder and enter ninja partition_manager report? It should look something similar to this.

  flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
+---0x0: b0_container (0x9000 - 36kB)--------------+
| 0x0: b0 (0x8000 - 32kB)                          |
| 0x8000: provision (0x1000 - 4kB)                 |
+---0x9000: s0 (0xc200 - 48kB)---------------------+
| 0x9000: s0_pad (0x200 - 512B)                    |
+---0x9200: s0_image (0xc000 - 48kB)---------------+
| 0x9200: mcuboot (0xc000 - 48kB)                  |
+--------------------------------------------------+
| 0x15200: EMPTY_0 (0xe00 - 3kB)                   |
+---0x16000: s1 (0xc200 - 48kB)--------------------+
| 0x16000: s1_pad (0x200 - 512B)                   |
| 0x16200: s1_image (0xc000 - 48kB)                |
+--------------------------------------------------+
| 0x22200: EMPTY_1 (0xe00 - 3kB)                   |
+---0x23000: mcuboot_primary (0x6e000 - 440kB)-----+
| 0x23000: mcuboot_pad (0x200 - 512B)              |
+---0x23200: app_image (0x6de00 - 439kB)-----------+
+---0x23200: mcuboot_primary_app (0x6de00 - 439kB)-+
| 0x23200: app (0x6de00 - 439kB)                   |
+--------------------------------------------------+
| 0x91000: mcuboot_secondary (0x6e000 - 440kB)     |
| 0xff000: EMPTY_2 (0x1000 - 4kB)                  |
+--------------------------------------------------+

  sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

When uploading the new image without n -2 you can see that the new image is not added to the primary application slot, i.e slot 0. It is located in a secondary slot before you confirm and reset. We would expect something similar on your end

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>nrfjprog --com
1050255060    COM6    VCOM0
1050255060    COM7    VCOM1

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr conn add acm0 type="serial" connstring="dev=COM6,baud=115200,mtu=512"
Connection profile acm0 successfully added

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.1.1
    bootable: true
    flags: active confirmed
    hash: 05dc5159151571bafa5e11309367b9ac9ede8d6dec708fafab01a2cd4b6fe90f
Split status: N/A (0)

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr -c acm0 image upload build_1/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin
 35.73 KiB / 35.73 KiB [============================================================================================================================================================================================] 100.00% 2.33 KiB/s 15s
Done

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.1.1
    bootable: true
    flags: active confirmed
    hash: 05dc5159151571bafa5e11309367b9ac9ede8d6dec708fafab01a2cd4b6fe90f
 image=0 slot=1
    version: 1.1.1
    bootable: true
    flags:
    hash: 3f99475cc81181793e4dbc2f8ba97669270978c8bb318741aa755c118baf9ff7
Split status: N/A (0)

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr -c acm0 image confirm 3f99475cc81181793e4dbc2f8ba97669270978c8bb318741aa755c118baf9ff7
Images:
 image=0 slot=0
    version: 1.1.1
    bootable: true
    flags: active confirmed
    hash: 05dc5159151571bafa5e11309367b9ac9ede8d6dec708fafab01a2cd4b6fe90f
 image=0 slot=1
    version: 1.1.1
    bootable: true
    flags: pending permanent
    hash: 3f99475cc81181793e4dbc2f8ba97669270978c8bb318741aa755c118baf9ff7
Split status: N/A (0)

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>nrfjprog --reset
Applying system reset.
Run.

C:\Nordic\samples_for_nrf_connect_sdk\bootloader_samples\updatable_bootloader\nsib_mcuboot_smp>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.1.1
    bootable: true
    flags: active confirmed
    hash: 05dc5159151571bafa5e11309367b9ac9ede8d6dec708fafab01a2cd4b6fe90f
 image=0 slot=1
    version: 1.1.1
    bootable: true
    flags:
    hash: fe6a5916233647d89cda6d245e41b3b4cb30399cf12fb46a2f073786bff6be05
Split status: N/A (0)

Kind regards,
Andreas

[QuentinD]

Hi,

The main difference I see is for "mcuboot_secondary". I see you haven't configured "CONFIG_SINGLE_APPLICATION_SLOT=y". I had to provide 0x10000 bytes for mcuboot_secondary in order not to have compilation errors but I would like not to have mcuboot_secondary if possible (or as small as possible).

Could you try by enabling "CONFIG_SINGLE_APPLICATION_SLOT=y"? (I think my problem comes from this option)

Here are my partitions:

[QuentinD]

Hello,

Were you able to test with the "CONFIG_SINGLE_APPLICATION_SLOT=y" option?

[AHaug]

Hi,

QuentinD said:

Were you able to test with the "CONFIG_SINGLE_APPLICATION_SLOT=y" option?

I was just about to write you a reply when I saw this one came in! First of I'm sorry it took a week to get back to you (yet again)

QuentinD said:

I see you haven't configured "CONFIG_SINGLE_APPLICATION_SLOT=y"

Secondly, yes I did and I see that I had misunderstood that aspect of your project

So as I had explained this earlier

AHaug said:

 Regarding MCUboot images. Correct me if I am wrong, but I suspect that you may believe that MCUboot updates work the same as "regular" application updates. It's not quite the same, as the new MCUboot image is uploaded to mcuboot_secondary before it is swapped to s1. Then NSIB reads a flag stating which slot it should run MCUBOOT from, i.e s0 or s1 depending on which is the latest update, and then MCUboot starts the application.

Which is still valid and this is the reason for why you need to have a secondary MCUboot application slot. The new MCUboot image has to be temporarily stored in MCuboot secondary before it is placed in s0 or s1 depending on the file you've uploaded. The implementation is made in such a way that that MCUboot only knows about its own slots, and since we're following the protocol we're sending things by default to MCUboot i.e the secondary slot.

MCUboot also assumes that the primary and secondary slot is equally large, with the exception of single bank serial recovery DFU. In this case, and with the addition that you have an uppdatable bootloader, MCUboot only expects the secondary slot to be atleast as large as s0 and s1 such that you can upload the new Mcuboot/bootloader image. In your case your s0 s1 is ~64kB, meaning you should be able to set the secondary to the same size (which you've shown in the partition in your previous reply)

AHaug said:

If I do the upload command without the "-n 2", it overwrites my application (mcuboot_primary). So that's why I put "-n 2" so that the application is not deleted and that it puts the bootloader file in the only partition that I have access to (mcuboot_secondary).

This also makes perfect sense, and I see I've mislead you somewhat in my prior reply. As I had only tested with dual bank, the flags were not an issue and I could upload the new bootloader image without using flags since the partitioning followed the default scheme. When uploading without the -n flag, mcumgr upload image defaults to -n 1. In your case, you will have to use a 

github.com/.../Kconfig.serial_recovery

Do also note the tips in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/mcumgr.html#image-management regarding -n and -e

Let me know if that clarifies things for you 

Kind regards,
Andreas

[QuentinD]

Hi,

Thanks again for your explanation but I already know all that.

The problem I have is that I have to load the update file in the secondary but then I don't know how to make it load in s0 or s1? (as you said, I set the secondary large enough to hold the new MCUboot)
So I can load the new MCUboot in the secondary but how do I update the bootloader? (I don't see the hash of the MCUboot I uploaded with the image list command)

[QuentinD]

Hello,

Do you have some news ? We are on this problem for 2 months and I still haven't solved my problem: it's becoming urgent!

[AHaug]

Hi,

QuentinD said:

Do you have some news ? We are on this problem for 2 months and I still haven't solved my problem: it's becoming urgent!

Unfortunately I have no more news, but rather a need to realign the case between us and you. 

We've gone through your case from start to end just now and this is currently my understanding of your project. Please correct and add your own thoughts

1. What are your goals for the project?
   1. You have ported your application from nRF5 to NCS. 
   2. You want to add single bank serial recovery DFU support to your new NCS application
   3. You want to add NSIB to have an updatable bootloader (MCUBoot) together with the new NCS application
   4. You wanted to update a device having nRF5 firmware and the old bootloader to the new NCS firmware. If so, then what is your motivation?
      
      
2. What have you achieved?
   1. You've ported your application from nRF5 to NCS
   2. You've added serial DFU support for your NCS application and performed updates
   3. You've added NSIB can only upload the new MCUboot images (_s0 / _s1) to MCUboot secondary application, but you've not been able to write them to s0/s1 from there
3. Any other items that you would like to mention? Components? Goals for your project?

The case has been going slow from our end due to the amount of moving parts and somewhat due to some misunderstandings in between us and you. At the start of october I asked you to create a new case for the questions regarding adding NSIB to the project as that is a different topic than adding DFU support for your application to get better case/topic separation, so I think that the misunderstanding occurred around here when you wanted to add NSIB to what we believed was a project where you performed DFU from nRF5 to NCS and added NSIB

So lets clarify any misunderstandings and pick up the speed from here

Kind regards,
Andreas

[QuentinD]

Hi,

You understood my problem very well: everything you said is correct.

The devices that are with my customers were developed with the NRF5 SDK. As I want to be able to benefit from the new features, I was forced to redevelop my application using the NCS SDK.
All the old features now work with this new SDK and so I would now like to get the bootloader working to continue to be able to update the devices that are in the field when I have a new release.
So I created this ticket to find out how to implement the bootloader in the NCS SDK to be able to update my old devices that work with the old SDK and also how to update new devices that would work with the new SDK.

Now I know how to update the application of my devices which are at my customers (based on the nRF5 SDK) to an application based on the NCS SDK -> therefore an update which uses the bootloader of the nRF5 SDK
Now I would like new devices we produce to use the Zephyr bootloader (NCS SDK). The problem I have is that I can't update it: once I write the file to MCUboot secondary, I can't get it to write this file to s0/s1.

To summarize, now I can update the applications of the devices that are with my customers (using the nRF5 SDK) so I can continue to send them my new updates. But I would like also to use the Zephyr bootloader for the new devices we produce so the bootloader update must work (update a device working with the NCS SDK to a new version coming from the NCS SDK).

Thank you

[AHaug]

Great, thank you. That makes us up to speed with what you're attempting to achieve

I've spent the day digging around in the serial recovery configurations together with my colleague and we found a discovery that could be a potential solution w.r.t creating an app that uses serial recovery + NSIB in NCS.

When using serial recovery, pretty much every other configuration have been disabled to keep things as small as possible. That does also include https://github.com/nrfconnect/sdk-mcuboot/blob/adab597a0eb0eb9c030a7b797748a49ca89988c2/boot/zephyr/Kconfig.serial_recovery#L202, which is required for MCUboot to do it's magic (i.e perform the update when restarting the device). MCUboot will not move the image from mcuboot secondary to its respective image slot unless the new image is confirmed for upgrade. 

So since this configuration is disabled by default in serial recovery, you can't set the image to confirmed. Enabling the config should fix that.

After you've added this configuration and tagged the new update image with 'confirm', MCUboot should transfer it from mcuboot_secondary to s0/s1 by following the steps in https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/updatable_bootloader/nsib_mcuboot_smp. Remember to use the flag -n 2 to ensure that the new image gets uploaded to mcuboot_secondary and not to mcuboot_primary.

Let me know if this gets us any closer to achieving your goals

Kind regards,
Andreas