How to erase flash area s0 and s1 when using NSIB?

[yang.hu]

Hi, 

I am using nrf5340, NCS v2.1.2.

My software arch is s0 + MCUboot + application, and i want to add an upgradable bootloader named MCUboot, of course an upgradable application(appcore + netcore).

I know the mcumgr can do this, but i want application to get the new upgradable packet by BLE or other wireless communications mode, then put them to their upgradable flash area.

After this, the b0 will boot new MCUboot or the MCUboot will boot new application.

--- 

I read some doc about this more than once at nordic NCS doc.

Now i can upgrade the appcore and netcore by MCUboot, and adding an upgradable MCUboot i only need to do.

I try to add B0 in my project, and flash all of them in my nrf5340dk. I see all of them in my board by nrf connect for desktop.

I modify CONFIG_FW_INFO_FIRMWARE_VERSION in mcuboot.conf, and build again. Then i flash 'signed_by_mcuboot_and_b0_s1_image_test_update.hex' using nrfjprog tools.

In my debug tool, i see B0 boot the new MCUboot, and the new MCUboot boot applicaton.

---

At this point, i think i only need to write new MCUboot upgradable packet to flash area s0 or s1 in my application. After reset board, the new MCUboot will booting.

But i can not erase flash area s1 by flash_area_erase() and img_mgmt_impl_erase_slot().

Using flash_area_erase() i got bus falut and img_mgmt_impl_erase_slot() is not erase flash area s1 actually.

[16:39:21.121]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0x46...0c

[16:39:21.221]收←◆Firmware signature verified.
Firmware version 3
Setting monotonic counter (version: 3, slot: 0)
Booting (0x8200).
[16:39:21.681]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***

[16:39:26.743]收←◆I: Starting bootloader
W: flash_area: 12, flash_map_entries:17
W: flash_area: 16, flash_map_entries:17
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
W: flash_area: 7, flash_map_entries:17
W: flash_area: 16, flash_map_entries:17
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none

[16:39:26.969]收←◆I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot

[16:39:32.033]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
[00:00:00.000,701] <inf> main: Hello World! nrf5340dk_nrf5340_cpuapp.

[16:39:37.035]收←◆[00:00:05.012,023] <wrn> main: align: 0x4
[00:00:05.012,084] <inf> main: read:
                               3d b8 f3 96 00 00 00 00  00 02 00 00 30 a4 00 00 |=....... ....0...
                               00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |........ ........
[00:00:05.012,084] <wrn> main: len: 0xd000.
[00:00:05.012,115] <wrn> main: fa_size: 0xd000.
[00:00:05.012,145] <err> os: ***** BUS FAULT *****
[00:00:05.012,176] <err> os:   Precise data bus error
[00:00:05.012,207] <err> os:   BFAR Address: 0x18000
[00:00:05.012,237] <err> os: r0/a1:  0x00000001  r1/a2:  0x0000d000  r2/a3:  0x00000002
[00:00:05.012,268] <err> os: r3/a4:  0xffffffff r12/ip:  0x0000d000 r14/lr:  0x00033037
[00:00:05.012,298] <err> os:  xpsr:  0x01000000
[00:00:05.012,298] <err> os: Faulting instruction address (r15/pc): 0x0003303a
[00:00:05.012,390] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:05.012,451] <err> os: Current thread: 0x20000260 (ota_mod_thread)
[00:00:05.112,121] <err> fatal_error: Resetting system

[16:46:15.623]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0x46...0c

[16:46:15.722]收←◆Firmware signature verified.
Firmware version 3
Setting monotonic counter (version: 3, slot: 0)
Booting (0x8200).
[16:46:16.197]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***

[16:46:21.251]收←◆I: Starting bootloader
W: flash_area: 12, flash_map_entries:17
W: flash_area: 16, flash_map_entries:17
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
W: flash_area: 7, flash_map_entries:17
W: flash_area: 16, flash_map_entries:17
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none

[16:46:21.484]收←◆I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot

[16:46:26.595]收←◆*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
[00:00:00.000,701] <inf> mcuboot_util: Swap type: none
[00:00:00.000,762] <inf> mcuboot_util: Swap type: none
[00:00:00.053,466] <inf> main: img_mgmt_impl_erase_slot: 0.
[00:00:00.053,558] <inf> mcuboot_util: Swap type: none
[00:00:00.053,558] <inf> main: 0img_mgmt_slot_in_use: 1.
[00:00:00.053,619] <inf> mcuboot_util: Swap type: none
[00:00:00.053,649] <inf> main: 1img_mgmt_slot_in_use: 0.
[00:00:00.053,680] <inf> mcuboot_util: Swap type: none
[00:00:00.053,771] <inf> mcuboot_util: Swap type: none
[00:00:00.053,802] <inf> main: img_mgmt_state_confirm: 0.
[00:00:00.053,802] <inf> main: Hello World! nrf5340dk_nrf5340_cpuapp.

bus falut:

r14/r15: nrf_nvmc.h:line:306:*(volatile uint32_t *)page_addr = 0xFFFFFFFF;

I hope i can describe the problem clearly.

Thanks for any suggestion.

Regards,

Yang Hu

[Hieu]

Hi Yang Hu,

I understand that you are trying to add two-stage bootloader to your application, is that correct?

If so, adding an upgradeable bootloader should not require you to modify MCUboot in anyway. I tried this myself just last week.

If your application has been configured to support mcumgr, simply use mcumgr to flash one of the following two images:

signed_by_mcuboot_and_b0_s0_image_test_update.bin
signed_by_mcuboot_and_b0_s1_image_test_update.bin

Choosing it depends on what the "current" MCUboot is on your device. The "current" MCUboot is the one that is valid and has a higher version number among the two in s0 and s1 slots.

If the current MCUboot is in S0, use mcumgr to flash the **_s1_image_test_update.bin.
If the current MCUboot is in S1, use mcumgr to flash the **_s0_image_test_update.bin.

A guide to perform MCUboot upgrade with mcumgr is available in the README of this sample created by our colleague Sigurd. 
For your case, it would be something like this:

mcumgr conn add conn_name type="serial" connstring="dev=com6,baud=115200,mtu=512"

# Since you already used nrfjprog to write a new MCUboot into S1, making S1 the current slot, the next image would be S0
mcumgr -c conn_name image upload build/zephyr/signed_by_mcuboot_and_b0_s0_image_update.bin

Hieu

[yang.hu]

Hi Hieu,

Thanks for your reply.

> I understand that you are trying to add two-stage bootloader to your application, is that correct?

Yes.

The mcumgr is a good way to upgrade firmware, but it looks using wired upgrade, i want to download the upgradeable firmware by BLE not UART.

I know the Bo using 'Ping-pong mode' to boot and/or upgrade MCUboot. Writing new MCUboot to  s0 or s1 slot, the B0 will boot it on the next reboot.

My problem is i can not erase the s0 or s1 slot by using flash_area_erase() and img_mgmt_impl_erase_slot().

New MCUboot cannot written without erasing.

Regards,

Yang Hu

[Hieu]

Hi Yang Hu,

If you are using the nRF Connect SDK, you do not need to worry about writing the new image to S0 or S1. The active MCUboot itself will take care of this.

I will describe the flow is below, using the image from the NSIB documentation:

1. "The MCUboot image for the inactive slot" is downloaded into the shared "buffer" area, MCUboot Secondary
2. At the next reboot, the active MCUboot detects the new image availability, and copy it over to the then-still-inactive slot
3. From the next reboot (one more reboot after step 2), B0 detects the two MCUboot images, and will choose the one with higher monotonic counter version as the active one.

There are two resources you can refer to for adding DFU over BLE:
- Zephyr SMP Server sample, where you can enable BLE support.
- Our colleague Simon's guide, with instructions to add DFU to a BLE application.

Best regards,

Hieu

[yang.hu]

Hi, 

At the step 2, MCUboot print the new image is always invalid. 

I try to write nRF5340 appcore application to MCUboot_Secondary, MCUboot also print new image is invalid. Before i add NSIB to my project, appcore application is valid.

This is my b0.conf:

CONFIG_NCS_MCUBOOT_IN_BUILD=y
CONFIG_SECURE_BOOT_DEBUG_RTT=y

And prj.conf:

CONFIG_SECURE_BOOT=y
CONFIG_SB_SIGNING_KEY_FILE="D://ncs//priv.pem"
CONFIG_BUILD_S1_VARIANT=y
CONFIG_FW_INFO=y
CONFIG_FW_INFO_FIRMWARE_VERSION=1

The log is in loader.c, line:790.

Best regards,

Yang Hu

[yang.hu]

> At the step 2, MCUboot print the new image is always invalid. 

I find the reason of this, i do not write the full image to mcuboot secondry.

I write signed_by_mcuboot_and_b0_s1_image_update.bin to mcuboot secondry, and reset my board.

But old MCUboot print ‘Reset address of image in secondary slot is not in the primary slot’.

this is log:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Swap type: perm
W: rr size:c10c
E: Reset address of image in secondary slot is not in the primary slot
E: Erasing image from secondary slot
I: Swap type: none
W: rr size:48100
I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot

[Hieu]

Hi, how are you writing the bin file to MCUboot secondary? Did you write directly using some flash tool, or did you write by talking to the application via SMP Protocol?

If you want to emulate the process by writing directly (from PC) to flash, you need to use the "***_moved_test_update.hex" variant of the file. That hex files contain some necessary metadata to trigger DFU.

[yang.hu]

In my project, i am using ext flash. First, i switch .bin to .c, then i using flash_write api to write to MCUboot_secondary.

[Hieu]

Are you using a custom implementation to write to your ext flash MCUboot_secondary or the solution provided in NCS?

By the way, I am out of office for the rest of the week. I hope this is not urgent. If it is urgent, please let me know and I will see if I can arrange some alternatives.

[yang.hu]

Hi, i am using a custom implementation.

In fact, i have two applications, one is test application that only write new image to MCUboot secondary, the other is my true application. And the true application include NSIB+MCUboot+application.

Firstly, i using the test application write new image to MCUboot secondary, then i flash my true application again.

After this, MCUboot secondary has the new image when my true application is running. 

The true application will call 'boot_request_upgrade_multi(0, BOOT_UPGRADE_PERMANENT);', and i will reset my board later.

> I hope this is not urgent. If it is urgent, please let me know and I will see if I can arrange some alternatives.

I hope you can give me some others suggest, and i can try in the rest of the week. 

Best regards,

Yang Hu

[yang.hu]

As far as i can see, mcungr using 'stream_flash_buffered_write()' to write new image to slot.

[Hieu]

Hi Yang Hu,

yang.hu said:

Firstly, i using the test application write new image to MCUboot secondary, then i flash my true application again.

After this, MCUboot secondary has the new image when my true application is running. 

Is the purpose of the "test application" just to write the new image to MCUboot Secondary, and only for development testing purpose?

If so, you could instead just directly flash the signed_by_mcuboot_and_b0_s0_image_moved_test_update.hex or signed_by_mcuboot_and_b0_s1_image_moved_test_update.hex files instead, as I previously recommended.

The reason you have issues is most likely because the MCUboot "metadata" for the image was not written correctly. Such data is already included in the hex files above.

If you wish to pursue this test application for a particular reason, you could refer to the SMP Server sample for how to write the new image to MCUboot Secondary. The flow of that application should include both downloading the image and setting the necessary "metadata" flags.

On that note, that sample might serve well as your test application. You will need to tweak it so that the flash partition is exactly the same as your real application though.

Having said all of that, my recommendation is still writing the hex file directly. If you have a special purpose that requires the "test application" approach, please share.

Let me know if you need anything else. Once again, I will be out of office for the rest of the week, so if you need an urgent response, please note so.

[yang.hu]

Hi,

> Once again, I will be out of office for the rest of the week, so if you need an urgent response, please note so.

I am not need an urgent response, and i will wait for you.

In summary, I would like to have a single firmware which can supports,

• Updating of network core (Using net_core_app_update.bin) 
• Updating application core (Using app_update.bin)
• Updating 2nd stage MCUboot bootloader (Using signed_by_mcuboot_and_b0_s1_image_update.bin)

And all of these .bin files are received via BLE or others wireless way. 

I am not using any solution provided in NCS, it is a custom implementation.

The custom implementation is:

1. I switch this .bin file to .c, and add some custom header to it, then i send it to my device via BLE.

2. My device receives this data and uses the header infomation to identify which target the data is being upgraded to.

3. After this, my device will write this data to its suitable solt, such as MCUboot secondary solt.

4. My device will using '

boot_request_upgrade_multi(0, BOOT_UPGRADE_PERMANENT);' to tell bootloader it time to swap new image.

5. After reset, the bootloader will boot the new image.

Currently It is  possible to do the following while nRF Secure Immutable Bootloader (NSIB) is disabled:

1. Updating of network core (Using net_core_app_update.bin) 

2. Updating application core (Using app_update.bin)

when i add NSIB to my project, all of this is not updating.

I add some log to MCUboot, and here is updating application core log:

I: Swap type: perm
E: area_id: 4.
E: reset_value: 0x3cdf1.
E: min_addr: 0x1008800.
E: reset_value: 0x3cdf1.
E: max_addr: 0x1040000.
E: Reset address of image in secondary slot is not in the primary slot
E: Erasing image from secondary slot
I: swap_type: 1
I: Image upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Copying the secondary slot to the primary slot: 0x1 bytes
E: Unable to find bootable image

We can see MCUboot erase the secondary solt firstly, and then copy the secondary slot to the primary solt.

Finally, the MCUboot bootloader is also not upgradable.