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

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

[Hieu]

Hi Yang Hu,

I still wonder why you have to use a custom implementation like that. Does our current setup with MCUboot and SMP Server on BLE Application not satisfying to you for certain reason? Is there perhaps some confidential feature involved?

What we are attempting to do is very much recreating what our development teams have designed, implemented, and tested. It is not very recommendable without a strong reason.

Hieu

[yang.hu]

Hi Hieu,

In my opinion, our purpose is the same, whether it's a SMP Server or Custom Server.

We want receive some date via BLE, it doesn't matter if it's OTA or sensor date.

I have something like sensor data to communicate with others device,  i has one BLE Server already. So i don't think i need the extra service(SMP Server)  to get OTA data.

I am using many nRF5x mcu, some of them have little RAM and flash, adding extra service cost too many resources.

Yang Hu

[Hieu]

Hi Yang Hu,

I see. Yours is a legit concern, and it would be great if you achieve the necessary resource saving with your custom setup.

I discussed with a few other engineers here today and we found out that there might be a problem with MCUboot that is causing the problem you are seeing.

We are involving our bootloader specialists to discuss this issue. I will update here as soon as there is any significant progress; or I will come back with a quick status update on Thu Jan 19 if things were slow. 

My apology for not being able to confirm this earlier and costed us so much time.

Hieu