Mcuboot stuck when updating image using flash_img_buffered_write() in zephyr

[emslGit]

Hello mcuboot community,

I am new to mcuboot and for the past week i have been trying to update the image by writing the contents of a zephyr.signed.bin file from an SD card and storing it to slot1 with flash_img_buffered_write() and boot_request_upgrade().

I have checked that the SD related functions work fine (and we have been using SD for a while), so buf should contain the exact contents as the built image 1.0.1. Below is the script that I use to create both images (i change the version 1.0.0 => 1.0.1 for the upgrade image). The upgrade image 1.0.1 is pretty much identical to image 1.0.0, only changing some print statements.

west build -d build -b main_node_dev
west sign -t imgtool -d build --bin --no-hex -- --key $ZEPHYR_BASE/../bootloader/mcuboot/root-rsa-2048.pem --version 1.0.0 --pad

When running imgtool.py verify both images turn out OK, (although the tool informs me that they both are configured for offset 0x10000 which would be slot0 in my case). Mcuboot and image 1.0.0 chain load fine and I get no non-zero return values (res below). Swap type at the bottom indicates 2 (test), however after sys_reboot(), the boot loader simply freezes at this stage and does not load the secondary image 1.0.1 at all. Upon hard reset, it sometimes reverts to image 1.0.0 and it sometimes crashes with MPU-fault, forcing me to reflash the image and/or boot loader.

Below is the screen/putty output where it gets stuck after the sys_reboot() call when trying to upgrade from 1.0.0 to 1.0.1. I notice that it shows Primary image and Scratch, but no entry for secondary image. Ideas what could be wrong?:

I: Starting bootloader
I: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
I: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Swap type: test

It stays like that forever, basically.

Here is the relevant code for main.c (the rest of the code concerns only the SD card). Also, assume that the buf variable is the same content and size as zephyr.signed.bin:

#include <zephyr.h>
#include <dfu/mcuboot.h>
#include <dfu/flash_img.h>
#include <storage/flash_map.h>
#include <sys/reboot.h>

#define IMG_SIZE 1984 * 1024

uint8_t *buf;

void main(void)
{
    struct flash_img_context img_1;
    int id_1 = FLASH_AREA_ID(image_1);
    int type = 0;
    int res = 0;

    /* Write contents of buffer to slot 1 */
    if (res == 0) {
        res |= flash_img_init_id(&img_1, id_1);
        res |= flash_img_buffered_write(&img_1, buf, IMG_SIZE, false);
        res |= flash_img_buffered_write(&img_1, buf, 0, true);
    }

    /* Request upgrade */
    if (res == 0) {
        k_msleep(100);

        res |= boot_request_upgrade(BOOT_UPGRADE_TEST);
        type = mcuboot_swap_type();
    }

    /* Reboot for upgrade to take effect */
    if (res == 0) {
        k_msleep(5000);
        sys_reboot(SYS_REBOOT_COLD);
    }
} /* main */

For reference, main node dev is in reality a mimxrt1024_evk with some overlays and changes to .dts and pinmux. Flashing mcuboot with board set as mimxrt1024_evk and then flashing the actual image with board set as main_node_dev seems to work fine though. Maybe this could be a problem? (I don't think it is the case, though)

Here are some configs I am using that might be relevant, although I have looked up most of them I am not sure about all of them. I am using more configs but they don't seem very relevant.

CONFIG_IMG_BLOCK_BUF_SIZE=512
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_MCUBOOT_BOOTUTIL_LIB=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

CONFIG_REBOOT=y

CONFIG_DISK_ACCESS=y
CONFIG_FAT_FILESYSTEM_ELM=y
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_SETTINGS=y

Additional info:

• Zephyr version: 2.7.99, build: v2.7.99-3156-g32c492cc0ce7
• Mcuboot: 1.8.0
• Board: mimxrt1024_evk

Here is also the flash map for mimxrt1024_evk. Most sections in the .dts look identical to our "rogue" version main_node_dev, specifically the flash map: https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/mimxrt1024_evk/mimxrt1024_evk.dts#L56-L83

Please let me know if there is more info I can provide or something else I can try. Any help will be muchly appreciated!

[d3zd3z]

Are you able to attach a debugger. It would be helpful to try and trace the codeflow once it prints the "Swap type: test" message in loader.c. I would think it should be starting a swap at this point.

[emslGit]

Sorry for the late reply. I tracked the codeflow from loader.c with printk, since our debugger is broken. Interestingly as i dug deeper, the more infrequent it got stuck. I tracked the "stuckness" into boot_swap_sectors() in swap_scratch.c but by that time I could rarely reproduce the error, and now it works almost every time. I guess I will mark this as solved for future reference, and return if it stops working.