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

[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

[QuentinD]

Thank you for your help ;-) 

To do this, I had to update my SDK (from v2.3.0 to v2.5.0). With this config, I can now see the hash and "to confirm" the hash. Unfortunately, now (with this new SDK), I can no longer write to the secondary (using -n 2): it writes the file to the primary. For this command to work I need to do "CONFIG_SINGLE_APPLICATION_SLOT=n"...

FYI, to successfully activate CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD and BOOT_SERIAL_IMG_GRP_IMAGE_STATE, I had to delete the "depends on !SINGLE_APPLICATION_SLOT" lines from the kconfig.serial_recovery file: I guess this is the only way to do it?

Would it be possible for me to give you my code so you can see what's wrong?