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