ImageState( slot=0, version='1.0.0', hash=HashBytes('00ECFDFD...'), bootable=True, pending=False, confirmed=True, active=True, permanent=False )
ImageState( slot=1, version='1.0.0', hash=HashBytes('2FD1F2FC...'), bootable=True, pending=True, confirmed=False, active=False, permanent=True )
Upon running the remote reset command, the board successfully triggers a system reboot, but MCUboot does not execute any sector shuffling or delays. It boots instantly straight back into the exact same HashBytes 00ECFDFD... in Slot 0.
Flash Layout Configurations (.overlay)
&flexspi {
status = "okay";
reg = <0x402a8000 0x4000>, <0x60000000 DT_SIZE_M(8)>;
is25wp064: is25wp064@0 {
compatible = "nxp,imx-flexspi-nor";
size = <67108864>;
reg = <0>;
spi-max-frequency = <133000000>;
status = "okay";
jedec-id = [9d 70 17];
erase-block-size = <4096>;
write-block-size = <1>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
/* STEP 1: Delete all conflicting stock partitions from the base board dts */
/delete-node/ partition@0;
/delete-node/ partition@10000;
/delete-node/ partition@310000;
/delete-node/ partition@610000;
/delete-node/ partition@630000;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 DT_SIZE_K(64)>;
};
/* Reduced slot0 to 3.4MB (0x366000) instead of 3.5MB */
slot0_partition: partition@10000 {
label = "image-0";
reg = <0x00010000 0x366000>; /* 3.5MB */
};
slot1_partition: partition@390000 {
label = "image-1";
reg = <0x00376000 0x366000>; /* 3.5MB */
};
scratch_partition: partition@710000 {
label = "image-scratch";
reg = <0x00710000 DT_SIZE_K(128)>;
};
storage_partition: partition@730000 {
label = "storage";
reg = <0x00730000 DT_SIZE_K(832)>;
};
};
};
};
app/prj.conf
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_XIP=y
CONFIG_MCUBOOT_BOOTLOADER_MODE_SWAP_WITHOUT_SCRATCH=y
CONFIG_USE_DT_CODE_PARTITION=y
app/sysbuild/mcuboot.conf
CONFIG_XIP=y
CONFIG_BOOT_SWAP_USING_MOVE=y
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="bootloader/mcuboot/root-rsa-2048.pem"
CONFIG_BOOT_VALIDATE_SLOT0=y
# Attempted RAM function isolation flags for Zephyr 3.5.0
CONFIG_FLEXSPI_CONFIG_IN_RAM=y
Hi @Deepa-khatri2588 ,
Thanks for your interest in NXP MIMXRT series!
I’ve reviewed your KConfig and DTS files, and it appears there are some issues. For example, `CONFIG_FLEXSPI_CONFIG_IN_RAM` and `CONFIG_CODE_FLEXSPI_RAMFUNC` do not exist in Zephyr 3.5.0.
Please check your KConfig settings in this official documentation:
https://docs.zephyrproject.org/3.5.0/kconfig.html
I recommend paying attention to the following KConfig settings:
CONFIG_CODE_FLEXSPI=y
CONFIG_XIP=y
CONFIG_FLASH_MCUX_FLEXSPI_XIP=y
CONFIG_FLASH_MCUX_FLEXSPI_XIP_MEM_ITCM=y
CONFIG_FLASH_MCUX_FLEXSPI_NOR_WRITE_BUFFER=y
CONFIG_FLASH_LOG_LEVEL_OFF=y
CONFIG_MEMC_LOG_LEVEL_OFF=y
CONFIG_MEMC=y
In DTS, there is an issue where node IDs and offset addresses do not match, which may also need to be verified:
slot1_partition: partition@390000 {
label = "image-1";
reg = <0x00376000 0x366000>;
};
Best regards,
Gavin
Thanks for your reply
I corrected the node address/offset label mismatch in my mimxrt1020_evk.overlay to ensure perfect structural alignment across the 3.4MB partitions:
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 DT_SIZE_K(64)>;
};
/* Reduced slot0 to 3.4MB (0x366000) instead of 3.4MB */
slot0_partition: partition@10000 {
label = "image-0";
reg = <0x00010000 0x366000>; /* 3.5MB */
};
slot1_partition: partition@376000 {
label = "image-1";
reg = <0x00376000 0x366000>; /* 3.5MB */
};
scratch_partition: partition@6dc000 {
label = "image-scratch";
reg = <0x006DC000 DT_SIZE_K(128)>;
};
storage_partition: partition@6fc000 {
label = "storage";
reg = <0x006FC000 DT_SIZE_K(1040)>;
};i added the macros you recommended as well
I push the signed binary over UDP using an SMP manager tool. After upload, I explicitly execute an image state write command. I am confirming that both the pending and permanent flags are successfully changing to True in Slot 1. A snapshot read of the flash states immediately before sending the reset command proves the metadata is armed:
ImageState(
slot=0, version='1.0.0',
hash=HashBytes('6835E08D...'),
bootable=True, pending=False, confirmed=True, active=True, permanent=False
)
ImageState(
slot=1, version='1.0.0',
hash=HashBytes('139D3CC6...'),
bootable=True, pending=True, confirmed=True, active=False, permanent=True
)Even though Slot 1 is perfectly armed for a permanent upgrade (pending=True, permanent=True), when I execute an os reset the board is still loaded with the old code
I attempted to enable serial logging for the MCUboot child image context, routing it to our debug interface UART channel (lpuart1 / UART7). However, when the hardware resets, I see absolutely zero console text or error traces from MCUboot. The very first logs to appear on the terminal are the initialization strings originating from the Slot 0 application.
What is the recommended method to capture early serial console logs from MCUboot on the RT1020 EVK before it hands execution control over to the application image
Any advice on why this swap routine is silently failing would be highly appreciated.
Hi @Deepa-khatri2588 ,
Regarding the LOG level settings, I think you should check this file: https://github.com/zephyrproject-rtos/zephyr/blob/94f5b2c2e828ed51a8e20c55d3f172dbf4a2dea8/tests/boo...
Also, I noticed that your slot sectors may be too large. Please check these two KConfig settings:
CONFIG_BOOT_MAX_IMG_SECTORS_AUTO
CONFIG_BOOT_MAX_IMG_SECTORS
Best regards,
Gavin