mcumgr firmware update over BLE: Error: 6 on image confirm

[eshaulx]

Hi, I am running Zephyr 2.1.99-ncs1 on an NRF52840 target with MCUbootloader. I have 2 applications smp_svr1 & smp_svr2 the former is loaded to slot 0 and slot 1 is free. I am trying to update the board with the smp_svr2 to slot 1 over BLE using mcumgr CLI as follows:

Step 1: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' image list Response 1: Images: image=0 slot=0 version: 0.0.1 bootable: true flags: active confirmed hash: 77f2bde082227506df7fc92519485963992dcb81b44400c9c144b22ffa9e44fc Split status: N/A (0)

Step 2: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' image upload ~/workspace/canary/Canary_Application/smp_svr_2/build/zephyr/app_update.bin Response 2: 119.82 KiB / 119.82 KiB [===============================================================================================================] 100.00% 2.67 KiB/s 44s Done

Step 3: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' image list Response 3: Images: image=0 slot=0 version: 0.0.1 bootable: true flags: active confirmed hash: 77f2bde082227506df7fc92519485963992dcb81b44400c9c144b22ffa9e44fc image=0 slot=1 version: 0.0.2 bootable: true flags: hash: cab9aed73169e23ed588673a10a9f4fec47b09cf384da1c4177fa8ed0b7490bf Split status: N/A (0)

Step 4: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' image test cab9aed73169e23ed588673a10a9f4fec47b09cf384da1c4177fa8ed0b7490bf Response 4: Images: image=0 slot=0 version: 0.0.1 bootable: true flags: active confirmed hash: 77f2bde082227506df7fc92519485963992dcb81b44400c9c144b22ffa9e44fc image=0 slot=1 version: 0.0.2 bootable: true flags: pending hash: cab9aed73169e23ed588673a10a9f4fec47b09cf384da1c4177fa8ed0b7490bf Split status: N/A (0)

Step 5: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' reset Response 5: Done

Step 6: mcumgr> sudo ./mcumgr --conntype ble --connstring 'peer_name=Zephyr' image confirm Response 6: Error: 6

The problem is that when pointing slot 1 hash and reseting, the application seems to be loaded from slot 0 (I have changed the printouts between both of the application) In addition, the command to confirm the image fails with Error: 6 I appriciate any of your thoughts as to what is done wrongly.

Both applications are using the configuration: CONFIG_BOOTLOADER_MCUBOOT=y CONFIG_MCUBOOT_IMG_MANAGER=y

Thanks in advanced, Erez.

[sjanc]

The thing is that you reset after but before you confirm image. This results in image being reverted to original version which doesn't require confirm anymore. So after test if things works, you confirm image and you are all set. You don't need to reset manually.

Also note that mcuboot is always executing code from slot0 while mcumgr always upload image to slot 1 and images are swapped if needed.

[eshaulx]

Dear sjanc, I was following the flow: Image list -> Image upload -> Image test -> reset (to test) -> confirm When the reset was done, I expected that the 2nd application (on slot 1 will run) This is the test... Unless I am getting the whole flow wrong... If it's not the flow, how should I test the uploaded application? 10x Erez

[utzig]

Also call another image list after your reset so we know what happened before doing a image confirm

[eshaulx]

I tired that and got the same reply as in step 4 (before): Images: image=0 slot=0 version: 0.0.1 bootable: true flags: active confirmed hash: 77f2bde082227506df7fc92519485963992dcb81b44400c9c144b22ffa9e44fc image=0 slot=1 version: 0.0.2 bootable: true flags: pending hash: cab9aed73169e23ed588673a10a9f4fec47b09cf384da1c4177fa8ed0b7490bf Split status: N/A (0)

[utzig]

Since slot 1 is in pending state you will get Error: 6. Have you tried to reset by pressing a button instead of using the reset command?

[utzig]

It might also be interesting to enable the debug console and copy the messages the bootloader outputs here.

[sjanc]

hmm this indeed looks like device was not reset before confirm... please test manual reset

[eshaulx]

I haven't tried to perform manual reset (only by command of the mcumgr) But it seems that the application was restarted upon the reset (see below log) Do you recommend trying with the actual hard reset? please see below the debug console during the spoken scenario: *** Booting Zephyr OS build v2.1.99-ncs1 *** Bluetooth initialized Advertising successfully started Connected Disconnected (reason 0x13) Advertising successfully started Connected Disconnected (reason 0x13) Advertising successfully started Connected Disconnected (reason 0x13) Advertising successfully started Connected Disconnected (reason 0x13) Advertising successfully started Connected Disconnected (reason 0x13) Advertising successfully started *** Booting Zephyr OS build v2.1.99-ncs1 *** - reset proove Bluetooth initialized - here i expected to see the printouts of the 2nd app Advertising successfully started - here i expected to see the printouts of the 2nd app Connected Disconnected (reason 0x13) Advertising successfully started

[utzig]

There are no messages from the bootloader, did you build it yourself?

[utzig]

There are no messages from the bootloader, did you build it yourself?

To be clear, this does not seem to be a mcumgr bug, it could be a mcuboot bug, but it looks more like you might have a mismatch of partitions between the bootloader and the images, so the bootloader never detects that you want to upgrade, while from the image perpective everything is correct, so that's why I asked if you built the bootloader, but also you could have changed the partitions with an overlay or something like that. Having the debug console enabled on the bootloader would be a good way to know what's happening.

[eshaulx]

I have built the bootloader by myself with my board dts. I also increase the level of the debug logging to 4 ### Ensure Zephyr logging changes don't use more resources CONFIG_LOG_DEFAULT_LEVEL=4 I can see the bootloader printouts when I have only bootloader flashed to the board (I could also see them before increasing the debug level):

but still could not see any bootloader printouts during the process of the mcumgr.

[utzig]

I can see the bootloader printouts when I have only bootloader flashed to the board

When you have the images flashed you don't see these bootloader messages?

[eshaulx]

This is what I see after flashing the 1st application appending to the bootloader: The application is running from the bootloader

[utzig]

So far it looks OK.

[eshaulx]

As I said, during the mcumgr communication process there are still no bootloader printouts. I am trying to figure out if mcuboot compilation is wrong or missing something.

[utzig]

As I said, during the mcumgr communication process there are still no bootloader printouts. I am trying to figure out if mcuboot compilation is wrong or missing something.

The bootloader always prints, could you be overwriting it with the image? How do you flash the bootloader and the image in slot0?

[utzig]

As I said, during the mcumgr communication process there are still no bootloader printouts. I am trying to figure out if mcuboot compilation is wrong or missing something.

The bootloader always prints, could you be overwriting it with the image? How do you flash the bootloader and the image in slot0?

On second thought, it looks OK since it booted the first image. (this platform is not the greatest for real-time communication!)

[utzig]

Are you using the standard DTS provided by Zephyr or did you customize or add overlays?

[eshaulx]

I am flashing the bootloader using west flash (this also perform a chip erase) then when it's only bootloader I am flashing the application using: west flash --hex-file ./build/zephyr/app_signed.hex Which start to flash from 0xC000

Yes I agree, can you suggest a better platform?

[eshaulx]

I have my own customize dts for my board with this partitions:

[utzig]

Yes I agree, can you suggest a better platform?

http://mcuboot.slack.com/ or one of #mcuboot / #mcumgr channels on Zephyr's slack.

[utzig]

Ah, that DTS does not look OK, the correct would be:

        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x000036000>;
        };
        slot1_partition: partition@42000 {
            label = "image-1";
            reg = <0x00042000 0x000036000>;
        };
        scratch_partition: partition@78000 {
            label = "image-scratch";
            reg = <0x00078000 0x00008000>;
        };

[utzig]

You have to use the sizes not the ending addresses, also the @offset has to match, it should work with the one I copied above.

[eshaulx]

Thanks for your quick catch - it's indeed wrong, I have updated my dts:

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0x0000C000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x000036000>;
        };
        slot1_partition: partition@42000 {
            label = "image-1";
            reg = <0x00042000 0x000036000>;
        };
        scratch_partition: partition@78000 {
            label = "image-scratch";
            reg = <0x00078000 0x00008000>;
        };

        /*
         * The flash starting at 0x00080000 and ending at
         * 0x000fffff is reserved for use by the application.
         */

        /* Storage partition will be used by FCB/NFFS/NVS if enabled. */
        storage_partition: partition@80000 {
            label = "storage";
            reg = <0x00080000 0x0007FFFF>;
        };

Unfortunately, I still get the same results Please note that I am compiling the mcuboot and application 1,2 with the same dts Can you confirm it's best practice?

[utzig]

Btw, not necessarily related but you also need to fix the size in the storage_partition:

        storage_partition: partition@80000 {
            label = "storage";
            reg = <0x00080000 0x00080000>;
        };

[utzig]

Can you confirm it's best practice?

Yes, mcuboot also requires an overlay that makes the boot_partition the code-partition although that should happen "automatically".

[L1amaGod]

I occured the completely same problem. And my dts is like below. Could you please help me?