Hi Raef,

Thank you for noticing it, it worked!

I had no idea that those flags were overriden from the original bl2/ext/mcuboot/mcuboot_default_config.cmake file.

Apparently that RE_IMAGE_ENCRYPTED option was set automatically after setting

DMCUBOOT_ENC_IMAGES=OFF -DMCUBOOT_ENCRYPT_RSA=OFF.

Also, because these flags were ON, the image required to be written to the secondary slot., but I was not

allowing it to write to it when i assigned "RE_IMAGE_ENCRYPTED= 0X00" which resulted in running an encrypted image,

as the upgrade would basically be none.

Best regards,

João Bento

On Tue, Nov 7, 2023 at 4:14 PM Raef Coles <Raef.Coles@arm.com> wrote:

Hey João

I'm not very familiar with that the RE_IMAGE_ENCRYPTED option does in the STM tooling, but I think if you have disabled encryption there you might also need to disable image encryption in the TF-M build system (which is enabled on the B-U585I-IOT02A by default).

The easiest way to do this is to set `-DMCUBOOT_ENC_IMAGES=OFF -DMCUBOOT_ENCRYPT_RSA=OFF` in the cmake command-line, or to edit platform/ext/target/stm/b_u585i_iot02a/config.cmake and perform a clean build

Hopefully this will help,
Raef

________________________________________
From: João Bento via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 07 November 2023 15:44
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Flashing problems on B-U585I-IOT02A

Hello,

I have recently trying to flash the B-U585I-IOT02A board by running the 3 scripts generated in the build folder, as I usually do with the STM32L552 board. However, I encountered some unexpected errors as I noticed that the secure and non-secure images were being written to external flash address spaces. I quickly noticed that this was happening because the "flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally, the "image_macros_to_preprocess_bl2.c" set the image as encrypted by default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script to write to the secondary slots.
I found it quite strange because tf-m presented an off-the-shelf solution for the other board while for this board it assumes the use of an external flash.
Nevertheless, I tried to work around these limitations by commenting the EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00" similarly to the stm32l552. This led to the images being written to the primary slots defined in the flash layout, however, in runtime I encountered an error that states "Unable to find bootable image".
Therefore, my question is: Do I need to make further adjustments, or is it possible that there's a configuration issue that is not compatible with the board?

Best regards,
João Bento