2024-08-18 03:59 PM
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:
The layout of slots which does work is as follows:
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
Solved! Go to Solution.
2024-08-20 12:40 PM - edited 2024-08-20 12:46 PM
It turned out that the issue was due to the hardcoded address being used in the code as shown here.
Fixed with use of zephyr code extracting the addresses from dts as shown in below screenshot:
2024-08-20 12:40 PM - edited 2024-08-20 12:46 PM
It turned out that the issue was due to the hardcoded address being used in the code as shown here.
Fixed with use of zephyr code extracting the addresses from dts as shown in below screenshot: