mcumgr: The firmware doesn't boot up after upload

[mlac]

Hi there,

I use MCUboot, and seemingly, the firmware update succeeds:

$ p mcumgr --conntype serial --connstring "/dev/ttyACM2,baud=115200" image upload -e zephyr.bin
 413.38 KiB / 413.38 KiB [============================================================================================================================================================================================================================] 100.00% 1.06 KiB/s 6m31s
Done

However, for some reason, the `image list` command yields no results:

$ p mcumgr --conntype serial --connstring "/dev/ttyACM2,baud=115200" image list
Images:
Split status: N/A (0)

Given the lack of image results, I couldn't reproduce the steps of the  Add DFU support to your application guide, which I've tried to follow.

After restarting the device, the firmware doesn't boot up.

CONFIG_BOOTLOADER_MCUBOOT=y is featured in my prj.conf.

child_image/mcuboot.conf contains the following:

CONFIG_PINCTRL=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
CONFIG_LOG=y
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_SERIAL=y
CONFIG_UART_LINE_CTRL=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_PIN_RESET=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_ALWAYS=n
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=3000
CONFIG_BOOT_SERIAL_NO_APPLICATION=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BACKEND_RTT=n

(The CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_ALWAYS=n Kconfig option comes from  MCUboot should only timeout after hardware reset .)

The devicetree flash section:

&flash0 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x0 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0xc000 0x72000>;
        };
        slot1_partition: partition@7e000 {
            label = "image-1";
            reg = <0x7e000 0x72000>;
        };
        scratch_partition: partition@f0000 {
            label = "image-scratch";
            reg = <0xf0000 0xa000>;
        };
        storage_partition: partition@fa000 {
            label = "storage";
            reg = <0xfa000 0x6000>;
        };
    };
};

Thanks in advance for your help!

Laci

[mlac]

In the meantime, I've realized that the size of CONFIG_PM_PARTITION_SIZE_MCUBOOT and boot_partition didn't match and updated the partitions accordingly:

&flash0 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x0 0x10000>;
        };
        slot0_partition: partition@10000 {
            label = "image-0";
            reg = <0x10000 0x72000>;
        };
        slot1_partition: partition@82000 {
            label = "image-1";
            reg = <0x82000 0x72000>;
        };
        scratch_partition: partition@f4000 {
            label = "image-scratch";
            reg = <0xf4000 0x6000>;
        };
        storage_partition: partition@fe000 {
            label = "storage";
            reg = <0xfe000 0x2000>;
        };
    };
};

But sadly, the issue persists.

[Vidar Berg]

Hi Laci,

Please try to use the same static partition file ( warning from partition_manager on NCS 2.5.0 ) for your project(s) to ensure your memory layout is consistent across builds.  

Best regards,

Vidar

[Vidar Berg]

Do you have any UART interfaces accessible on your board that you can use to get debug logs from the bootloader? If not, are you able to debug the bootloader to determine why it is not booting the application?

[mlac]

Yes, I have UART accessible, and I've just enabled the following Kconfig options in MCUboot:

CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_INTERRUPT_DRIVEN=y

I've also added the following devicetree fragment:

/ {
    chosen {
        zephyr,uart-mcumgr = &uart0;
    }
}

But all I see in the console is the following:

*** Booting Zephyr OS build v3.3.99-ncs1-1 ***

[Vidar Berg]

Sorry for not being clearer. I didn't intend to suggest changing the mcumgr interface, you can continue using the USB interface for that. 

Here is an example where I have enabled logging over UART:

7367.hello_world_dfu.zip

[mlac]

I've removed the Kconfig options and devicetree fragment I quoted in my previous post.

Then I added the following MCUboot Kconfig options based on your attached example:

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y
CONFIG_LOG_DEFAULT_LEVEL=0
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
CONFIG_CBPRINTF_NANO=y

Finally, I executed mcumgr:

$ mcumgr --conntype serial --connstring "/dev/ttyACM2,baud=115200" log show
Status: 8
Next index: 0
(no logs retrieved)

What am I missing?

[Vidar Berg]

The logs are printed from your UART interface and are independent of your USB interface used for sending mcumgr commands. You can connect a serial terminal to the UART interface to view the logs.

[mlac]

Got it, thanks! I get the following via UART:

*** Booting Zephyr OS build v3.3.99-ncs1-1 ***
I: Starting bootloader
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
W: Failed reading image headers; Image=0
E: Unable to find bootable image
I: Enter the serial recovery mode

[Vidar Berg]

The problem is that the bootloader is not finding any valid application to boot in the primary slot, but I'm not sure why. Does it work again as soon as you build without the static partition file? In that case, please compare the memory layouts between the 2 builds. 

[mlac]

Just figured it out!

Removing CONFIG_SIGN_IMAGES=n from prj.conf made the application firmware run.

Do you know why it solved the issue? Our firmware doesn't need to be cryptographically signed, which is the reason why I added this line.

[Vidar Berg]

That explains it. You need to enable the CONFIG_SIGN_IMAGES option if you want the build system to automatically sign the application for you. If not, you will have to sign it yourself. MCUBoot will not boot an image that doesn't have the image trailer and header.