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.