cancel
Showing results for 
Search instead for 
Did you mean: 

After updating the slot size MCUboot gives error for secondary slot image invalid for FOTA

A Maq
Senior

Hi,

I have following settings:

 

IDE : VS Code (NRF connect plug-in)

 

Programmer : Stm32Cube programmer (West tools used from zephyr sdk to flash and build)

 

Stlink Debugger 

 

OS: Zephyr 

 

MCU: Stm32u5 series (Stm32u575)

 

Imagetool used for the signing of the image that is part of the zephyr sdk.

 

I'm trying to upgrade application firmware using MCUboot ( Zephyr's) bootloader and AWS FOTA .

I can upgrade application firmware however, as soon as I change the size of the image slots the MCUBOOT bootloader on stm32 chips mcuboot does not upgrade the image after the download is complete and complains

E: Image in the secondary slot is not valid!.          (image attached)

Then the mcuboot fallback to the primary slot image after reset.

On reverting back the size of the slots it works again every time.

I have put some debug messages in mcuboot which shows the hash mismatch issue (image attached for code snippet with debug message from MCUboot code)

 

Can anyone please suggest what can be potential solution for MCUBOOT bootloader upgrade over the air on STM32 chip or are there any specific changes required in MCUboot from zephyr to make it work with STM32 so that the change in the slot sizes can be accomplished without any issue as long as it is meeting the logical criteria of being within limit of the 2MB and size of the slot is divisible by 8K(sector size) and both slots primary and secondary  are same size with scratch partition at least a sector size?

 

The layout of slots which does not work is as follows:

boot_partition: partition@0 {
             label = "mcuboot";
             reg = <0x00000000 DT_SIZE_K(48)>;
         };
         slot0_partition: partition@c000 {
             label = "image-0";
             reg = <0x0000c000 DT_SIZE_K(664)>;
         };
         slot1_partition: partition@b2000 {
             label = "image-1";
             reg = <0x000b2000 DT_SIZE_K(664)>;
         };
         scratch_partition: partition@158000 {
             label = "image-scratch";
             reg = <0x00158000 DT_SIZE_K(16)>;
         };

The layout of slots which does work is as follows:

boot_partition: partition@0 {
             label = "mcuboot";
             reg = <0x00000000 DT_SIZE_K(48)>;
         };
         slot0_partition: partition@c000 {
             label = "image-0";
             reg = <0x0000c000 DT_SIZE_K(640)>;
         };
         slot1_partition: partition@ac000 {
             label = "image-1";
             reg = <0x000ac000 DT_SIZE_K(640)>;
         };
         scratch_partition: partition@14c000 {
             label = "image-scratch";
             reg = <0x0014c000 DT_SIZE_K(64)>;
         };

 The STM32 chip we are using Stm32u575 has 2MB flash ( 2 banks 1MB each bank). I could not find in STM32 flash documentation any issue related to banks as now secondary slot image is half in bank one and most part in  bank 2. Please share if any potential issues or known bugs related to hardware of stm32.

Regards

A

1 ACCEPTED SOLUTION

Accepted Solutions
A Maq
Senior

It turned out that the issue was due to the hardcoded address being used in the code as shown here.

AMaq_1-1724183173445.jpeg

 

 

Fixed with use of zephyr code extracting the addresses from dts as shown in below screenshot:

AMaq_0-1724182817676.png

 

View solution in original post

1 REPLY 1
A Maq
Senior

It turned out that the issue was due to the hardcoded address being used in the code as shown here.

AMaq_1-1724183173445.jpeg

 

 

Fixed with use of zephyr code extracting the addresses from dts as shown in below screenshot:

AMaq_0-1724182817676.png