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]

Happy to help :) Been a learning process for me as well as serial recovery + NSIB is not the most common setup

QuentinD said:

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"...

My thoughts here are that in v2.3.0 there might've been a bug or a warning in your build that allowed you to both use CONFIG_SINGLE_APPLICATION_SLOT=y and to define a 64k Mcuboot secondary application slot in your pm static AND that you were allowed to use -n 2.

When reflecting over this now it seems strange to me that we were allowed to configure both a secondary application partition and use CONFIG_SINGLE_APPLICATION_SLOT=y. If you still have the v2.3.0 revision that had the previous issue we investigated, could you check to see if there were a warning when building your previous app in v2.3.0 which had CONFIG_SINGLE_APPLICATION_SLOT=y and the 64k secondary partition? If not I'll add it to the to do list to look into, so no worries.

QuentinD said:

For this command to work I need to do "CONFIG_SINGLE_APPLICATION_SLOT=n"...

I would imagine that you don't need to have CONFIG_SINGLE_APPLICATION_SLOT enabled if you have serial recovery as the application should go straight into mcuboot_primary_application slot and this should allow you to use -n 2 to upload the new MCUboot image fo mcuboot_secondary_application slot before transporting it to the s0/s1 slot. But I guess that causes issues for you in v2.5.0 since you need to remove the dependency you mention?

Kind regards,
Andreas

[QuentinD]

Sorry, I have already deleted v2.3.0 from my disk and am making code adaptations for the new SDK.

If I set "CONFIG_SINGLE_APPLICATION_SLOT=n" (with a primary and a secondary of a different size), I have this issue:

*** Booting nRF Connect SDK v2.5.0 ***
[00:00:00.000,213] <inf> mcuboot: Starting bootloader
[00:00:00.000,488] <wrn> mcuboot: Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?
[00:00:00.000,793] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.000,854] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.000,885] <inf> mcuboot: Boot source: none
[00:00:00.000,976] <inf> mcuboot: Image index: 1, Swap type: none
[00:00:00.001,037] <err> mcuboot: Image in the primary slot is not valid!
[00:00:11.416,015] <err> mcuboot: Unable to find bootable image

And here are the image lists before and after an update:

C:\DocTA\Soft\TA-Smart-BT840P>mcumgr -c my_config image list
Images:
 image=0 slot=0
    version: 2.0.1
    bootable: true
    flags: active confirmed
    hash: 6f52cf5c50e6989c3c8779b66d1087432384f96033d28455281f51cbeb61cd94
 image=1 slot=0
    version: 2.0.1
    bootable: true
    flags: active confirmed
    hash: 34552d5c69164df57ff025d9a79a695d3784ae72b1b730b5175a3a9b188e3755
Split status: N/A (0)

C:\DocTA\Soft\TA-Smart-BT840P>mcumgr -c my_config image upload Application\TA_Smart\zephyr\signed_by_mcuboot_and_b0_s1_image_update.bin -n 2
 59.00 KiB / 59.00 KiB [=======================================================================] 100.00% 2.19 KiB/s 26s
Done

C:\DocTA\Soft\TA-Smart-BT840P>mcumgr -c my_config image list
Images:
 image=0 slot=0
    version: 2.0.1
    bootable: true
    flags: active confirmed
    hash: 6f52cf5c50e6989c3c8779b66d1087432384f96033d28455281f51cbeb61cd94
 image=0 slot=1
    version: 2.0.1
    bootable: true
    flags:
    hash: 9782abe03da3012f15f3d0d5f7ddc6c66216471a90344591f7f7456785492cb4
 image=1 slot=0
    version: 2.0.1
    bootable: true
    flags: active confirmed
    hash: 34552d5c69164df57ff025d9a79a695d3784ae72b1b730b5175a3a9b188e3755
 image=1 slot=1
    version: 2.0.1
    bootable: true
    flags:
    hash: 9782abe03da3012f15f3d0d5f7ddc6c66216471a90344591f7f7456785492cb4
Split status: N/A (0)

Basically, I activated CONFIG_SINGLE_APPLICATION_SLOT because I have a constraint in terms of memory space and therefore I do not want to have to duplicate the space used by my application.

[QuentinD]

Hello,

Were you able to investigate this problem ?

[QuentinD]

Hello,

I remind you thant we have been stuck on this problem for 3 months and we still have not had a solution ! If you don't know how to solve the problem, can you ask to the developer team ?

Thank you

[AHaug]

Hi,

Apologies for the long wait. It has been a period with unusual long period with unexpected amount of sickleave and extra load due to that.

I spent yesterday afternoon creating a sample for you that showcases serial recovery + nsib in the same app. I hope the detailed steps and provided sample (at the bottom/attachments) is enough to get you to your goal

Requirements:

• nRF Connect SDK v2.5.0
• nRF52840DK

The application features

• Serial recovery over UART
• NSIB & updatable bootloader
• A static_pm.yml where mcuboot primary and secondary has been defined with different non-equal sizes. The sizes has been chosen arbitrarily w.r.t ratios, and is only meant as a sample to showcase that this works with different sized partitions. You can customize them as you see fit given that you do it according to the static partitioning documentation.

What you can do with this app

• Enter serial recovery mode to directly upload the new application firmware to mcuboot primary application slot and overwrite the existing firmware. 
  • This means that you can modify the pm_static.yml to create an primary application slot that uses almost all of the available internal flash as long as there still is a secondary mcuboot partition that can fit the new Mcuboot update image for s0/s1
• Update the bootloader by uploading the new firmware image to the smaller mcuboot secondary partition, confirm and reset

You can update the bootloader, the application or both in any order you need as long as the pm_static.yml has not been changed in between the revisions you're going to update.

If you wish to make modifications instead of using the prebuilt firmware in build_v1 and build_v2 do the following:

1. Build and flash the project
2. Increment the firmware version in child_image/mcuboot.conf
3. Make changes to the application if your new firmware needs application changes
4. And/or make change to $NRF_CONNECT_SDK/bootloader/mcuboot/boot/zephyr/main.c, for instance add a log
5. Build, do not flash
6. Follow the steps below to perform the updates

Below I will give you the steps to recreate this using the prebuilt firmware.

Updating the application:

I've predefined my conn as acm0 following the steps in docs.zephyrproject.org/.../mcumgr.html

1. Erase everything using
   1. nrfjprog -e
2. Flash the firmware through cmd from the project folder
   1. west flash -d build_v1 --skip-rebuild --recover
3. Connect to a serial terminal and observe that you boot from slot 0 and that the print output is what you've added to your application
4. Disconnect from the serial terminal
5. Hold DK BTN 1 and press the reset button to enter serial recovery mode
6. Observe that LED1 is lighting
7. In cmd list your images so you see what's present before the upload
   1. mcumgr -c acm0 image list
8. Upload the new firmware
   1. mcumgr -c acm0 image upload build_v2/zephyr/app_update.bin -e -n0
9.  List once more and observe that the new image is in image=0 slot =0 with flags "active confirmed", i.e it has overwritten the previous firmware which in my case ends with ...a55722 and instead uses _v2 which ends with ...a6238  
   1. mcumgr -c acm0 image list
10. Connect to a serial terminal
11. Reset the board
    1. nrfjprog --reset
12. Observe that the DK boots with the "updated version" print

Output after updating the application

*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.

Attempting to boot from address 0x9200.

Verifying signature against key 0.

Hash: 0x8f...3b

Firmware signature verified.

Firmware version 1

Booting (0x9200).
*** Booting nRF Connect SDK v2.5.0 ***
APP This is the first version with serial recovery & different mcuboot partitions app print
*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.

Attempting to boot from address 0x9200.

Verifying signature against key 0.

Hash: 0x8f...3b

Firmware signature verified.

Firmware version 1

Booting (0x9200).

*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.

Attempting to boot from address 0x9200.

Verifying signature against key 0.

Hash: 0x8f...3b

Firmware signature verified.

Firmware version 1

Booting (0x9200).

*** Booting nRF Connect SDK v2.5.0 ***
APP This is the updated version with serial recovery & different mcuboot partitions app print

MCUmgr input

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.2.34
    bootable: true
    flags: active confirmed
    hash: d36b9f8cbe980ff4deb866f705c7739b4c18ce3de1d32f02aef6660522a55722
 image=1 slot=0
    version: 1.2.34
    bootable: true
    flags: active confirmed
    hash: d8148464f8c8a4c9951abd6fe518f5dffb26dc685c1e88c5d342352fe1b9dc8f
Split status: N/A (0)

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image upload build_v2/zephyr/app_update.bin -e -n0
 43.06 KiB / 43.06 KiB [=================================================================================================================================================================] 100.00% 2.43 KiB/s 17s
Done

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.2.34
    bootable: true
    flags: active confirmed
    hash: bc74e3d37c4889deb9370cf471102fb374fd89b9b014a722692ab1773fea6238
 image=1 slot=0
    version: 1.2.34
    bootable: true
    flags: active confirmed
    hash: d8148464f8c8a4c9951abd6fe518f5dffb26dc685c1e88c5d342352fe1b9dc8f
Split status: N/A (0)

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>nrfjprog --reset
Applying system reset.
Run.

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>

Updating the bootloader

If you're starting here, then you need to do the first step of adding the conn to acm0. The output here are after I've updated the application in the previous steps

1. Disconnect from the serial output
2. Check the images
   1. mcumgr -c acm0 image list
3. Upload the new bootloader image from build_v2. Since we're in _v1 are using s0 for our bootloader, we need to upload the s1-image.
   1. mcumgr -c acm0 image upload build_v2/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin -e -n2
4. List the images. Observe that the new bootloader image is in the slot corresponding to mcuboot_secondary application
   1. mcumgr -c acm0 image list
5. Confirm the new bootloader and observe that the bin in image 0 slot 1 is now flagged "pending permanent" and is ready for update
   1. mcumgr -c acm0 image confirm 
6. Connect to a serial terminal
7. Restart the device and wait a while until the update has gone through
   1. nrfjprog --reset
8. Reset the device once more and observe that it now boots from s1 

Output after updating the bootloader:

*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.

Attempting to boot from address 0x9200.

Verifying signature against key 0.

Hash: 0x8f...3b

Firmware signature verified.

Firmware version 1

Booting (0x9200).

*** Booting nRF Connect SDK v2.5.0 ***
APP This is the updated version with serial recovery & different mcuboot partitions app print
*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 1.

Attempting to boot from address 0x16200.

Verifying signature against key 0.

Hash: 0x8f...3b

Firmware signature verified.

Firmware version 2

Setting monotonic counter (version: 2, slot: 1)

Booting (0x16200).

*** Booting nRF Connect SDK v2.5.0 ***
APP This is the updated version with serial recovery & different mcuboot partitions app print

Input in cmd:

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.2.3.4
    bootable: true
    flags: active confirmed
    hash: bc74e3d37c4889deb9370cf471102fb374fd89b9b014a722692ab1773fea6238
Split status: N/A (0)

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image upload build_v2/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin -e -n2
 41.44 KiB / 41.44 KiB [================================================================================================================================================================] 100.00% 2.56 KiB/s 16s
Done

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image list
Images:
 image=0 slot=0
    version: 1.2.3.4
    bootable: true
    flags: active confirmed
    hash: bc74e3d37c4889deb9370cf471102fb374fd89b9b014a722692ab1773fea6238
 image=0 slot=1
    version: 1.2.3.4
    bootable: true
    flags:
    hash: 6f79a50c6399a65cca5d86b6eb1b5009340bbd252b6f770b449ef63b22e3a241
Split status: N/A (0)

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>mcumgr -c acm0 image confirm 6f79a50c6399a65cca5d86b6eb1b5009340bbd252b6f770b449ef63b22e3a241
Images:
 image=0 slot=0
    version: 1.2.3.4
    bootable: true
    flags: active confirmed
    hash: bc74e3d37c4889deb9370cf471102fb374fd89b9b014a722692ab1773fea6238
 image=0 slot=1
    version: 1.2.3.4
    bootable: true
    flags: pending permanent
    hash: 6f79a50c6399a65cca5d86b6eb1b5009340bbd252b6f770b449ef63b22e3a241
Split status: N/A (0)

C:\Nordic\SDKs\ncs\my_projects\samples_for_NCS\DFU\serial_recover_nsib>nrfjprog --reset
Applying system reset.
Run.

0652.serial_recover_uart_nsib.zip

Kind regards, 
Andreas