How to use Secure Manager with External Flash profile

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

1. What is the External Flash profile?

The External Flash profile enables Secure Manager to use external flash memory.

This external flash memory stores the download slots for the following:

Nonsecure application
Secure Manager
ITS provisioning (if applicable)
Module (if applicable)

The Secure Manager uses external flash memory for the PSA firmware update service. Free space in external flash memory can be used by the nonsecure application for internal purposes. The memory mapping of external flash memory can be customized.

Information

The SMuRoT download slot is located in the user flash memory.

'Figure 1: External flash memory default configuration

The use of external flash memory expands the capacity for larger nonsecure applications, as detailed in the table below:


Flash memory configuration	Nonsecure application size
SMAK_0 Large profile	600 Kbytes
SMAK_0 External Flash profile	1 408 Kbytes
SMAK_1 Large profile	472 Kbytes
SMAK_1 External Flash profile	1 280 Kbytes

1.1. Components

The external flash memory is used to store the download slots for images, which are installed by the SMuRoT.

Different components require access to external flash memory to perform read, write, or erase operations:

The STM32CubeProgrammer software tool during provisioning or for a download

The SMuRoT during the boot, to install the image(s) present

The nonsecure application via PSA firmware update service to update an image: Secure Manager, nonsecure application, or module

The following components can be updated or replaced to support another external flash memory:

The External Loader

The External Flash Driver

The External Flash API

Figure 2: Components requiring access to external flash memory

The table below provides definitions specific to the terms used in this article:


Term	Definition
External Loader	An External Loader is a piece of software designed to access external flash memory. STM32CubeProgrammer provides an External Loader for the default external flash memory on the STM32H573I-DK Discovery kit. This tool runs on a computer.
External Flash Driver	The External Flash Driver is a nonsecure image authenticated by the SMuRoT in the user flash memory. It implements functions to initialize, read, write, and erase external flash memory. The SMuRoT invokes these functions during the installation process.
External Flash API	External Flash APIs are Secure Manager functions implemented in the nonsecure application to read, write, and erase external flash memory.

1.2. Use cases

The sections below show the scenarios in which external flash memory is used.

1.2.1. Provisioning

During provisioning, STM32CubeProgrammer uses an External Loader to write images to external flash memory (download slots). This External Loader is specific to provisioning. See the External Loader subchapter for more details.

Figure 3: External flash memory during provisioning

1.2.2. Download

The download of an image during runtime is possible only in the product state TZ-Closed and is reserved for the nonsecure application or modules. For a download, STM32CubeProgrammer uses an External Loader to write the image to the external flash memory. This External Loader is specific to the download. See the External Loader subchapter for more details. After the download, STM32CubeProgrammer resets the board. During boot, the SMuRoT installs the image using an External Flash Driver.

Figure 4: External flash memory during a download

1.2.3. PSA firmware update service

At runtime, the nonsecure application can use the PSA firmware update service to update or retrieve information from firmware or abort an image, such as the Secure Manager, a nonsecure application, or a module. The nonsecure application calls the PSA API, and the Secure Manager calls the External Flash API functions to read, write, or erase in external flash memory. After the "request install" operation, the system reboots and the SMuRoT installs the image by using an External Flash Driver.

Note: The update of SMuRoT uses only the user flash memory.

Figure 5: External flash memory during PSA firmware update service

2. External Flash profile configuration

The first step in this process is to indicate to the provisioning.py script that the External Flash profile must be used. Edit the [binary].profile section in the Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\sm.ini file as shown below:

[binary]
# (large | external_flash)
profile = external_flash
profile_ini = {"large"           : "Profile_Large/large.ini",
               "external_flash"  : "Profile_External_Flash/ext_flash.ini"}

Refer to the following subchapters to configure the External Flash profile. Some parts refer to the Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini configuration file. For more details about this file, see this other configuration profile file wiki.

2.1. External Flash Driver

The external flash memory stores the encrypted firmware before its installation in the user flash memory. To install firmware (decryption, authentication, and deployment), the updatable root of trust (SMuRoT) must access the external flash memory through an External Flash Driver (Figure 6 and 7).

Figure 6: Software architecture

Figure 7: External Flash Driver

An example is available under Projects\STM32H573I-DK\Applications\ROT\External_Flash_Driver. It is tailored for the default external flash memory of the STM32H573I-DK, MX25LM51245G (Macronix, serial NOR, SFDP, 512 Mbits).

The following sections explain the External Flash Driver in detail.

2.1.1. Specifications

The External Flash Driver must comply with constraints regarding SRAM usage, memory, and APIs, as it interacts with SMuRoT. The purpose of the following sections is to elaborate on these constraints.

2.1.1.1. Product state

The External Flash Driver runs in the nonsecure area, as shown in Figure 6. It can be updated via ST-LINK with bootloader in the product state TZ-Closed, but it cannot be updated in the product state Closed.

2.1.1.2. RAM usage

SMuRoT shares data with the External Flash Driver in nonsecure SRAM1. The remaining SRAM1 can be used internally by the External Flash Driver, such as for logs. The External Flash Driver cannot access SRAM2 or SRAM3.

2.1.1.3. Flash memory mapping

To be used by the SMuRoT, the External Flash Driver must comply with these memory constraints:

Figure 8: External Flash Driver memory mapping

2.1.1.4. Descriptor

The descriptor area is designed to provide constant memory access to API functions through pointers. These API functions must respect the placement shown in the code snippet below:

ROOT const EXT_FLASH_Descriptor_t descriptor =
{
  .Init             = EXT_FLASH_Init,
  .Read             = EXT_FLASH_Read,
  .Write            = EXT_FLASH_Write,
  .EraseSector      = EXT_FLASH_EraseSector,
  .DeInit           = EXT_FLASH_DeInit,
  .GetInfo          = EXT_FLASH_GetInfo,
  .SetVtor          = EXT_FLASH_SetVtor
};

2.1.1.5. APIs

The External Flash Driver project does not include a main() function. Instead, it provides a list of APIs, as shown in the table below.

These APIs must be updated according to the external flash memory used, while keeping the same parameters.


Name	Parameters	Comments
EXT_FLASH_Init()	None	Initialize the External Flash Driver Initialize global data
EXT_FLASH_DeInit()	None	Deinitialize the External Flash Driver
EXT_FLASH_Read()	Address (in, 32 bits): memory offset to read Size (in, 32 bits): length to read pData (out, pointer): pointer to store the read content	Read in the external flash memory
EXT_FLASH_Write()	Offset (in, 32 bits): memory offset to write Size (in, 32 bits): length to write pData (in, pointer): data to write	Write in the external flash memory
EXT_FLASH_EraseSector()	Offset (in, 32 bits): offset to erase	Erase a sector (4K) in the external flash memory
EXT_FLASH_GetInfo()	pInfo (out, pointer): store the memory information	Get the external flash memory parameters
EXT_FLASH_SetVtor()	/	Set the VTOR for the External Flash Driver

Each API shall return a status as defined in External_Flash_Driver\Inc\ext_flash_driver_descriptor.h below:

#define EXT_FLASH_ERROR   (0x0029e226U)
#define EXT_FLASH_OK      (0xfffc909cU)

2.1.2. Log

To assist in the development of the External Flash Driver, logs can be activated by adding the preprocessor directive EXT_FLASH_LOG_ENABLED to the project. The default configuration matches the SMAK_Appli and is available in External_Flash_Driver\Src\com.c. This configuration can be customized.

Rebuild the project and refer to the next section to update the External Flash Driver and view the trace in the terminal emulator.

2.1.3. Example

An example of an External Flash Driver is available under Projects\STM32H573I-DK\Applications\ROT\External_Flash_Driver.

Figure 9: The External Flash Driver project

You can build the project External_Flash_Driver. Depending on the IDE used, the output is located in:

If you use IAR Systems^® EWARM, Projects\STM32H573I-DK\Applications\ROT\External_Flash_Driver\EWARM\STM32H573-DK_Ext_Flash_Driver\Exe\Ext_Flash_Driver.bin

If you use STMicroelectronics STM32CubeIDE, Projects\STM32H573I-DK\Applications\ROT\External_Flash_Driver\External_Flash_Driver\STM32CubeIDE\Output\Ext_Flash_Driver.bin

Figure 10: Outputs of the External Flash Driver project

Then, copy the output file from the External_Flash_Driver project to Projects\STM32H573I-DK\ROT_Provisioning\SM\Binary\Profile_External_Flash\Ext_Flash_Driver.bin and run the Projects\STM32H573I-DK\ROT_Provisioning\SM\provisioning.py script with your configuration.

2.1.3.1. Adding External Flash Driver to SFI

Once the External Flash Driver is generated, it must be added to the SFI so that the Secure Manager can use it. For this purpose, a JSON file and a configuration file (INI) must be updated.

Each image's information is described in a JSON file. These JSON files are referenced in the images dictionary within the Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini file. Each path is relative from the ext_flash.ini file and can be customized.

To add the External Flash Driver binary to the SFI, use the JSON template located atProjects\STM32H573I-DK\ROT_Provisioning\SM\Binary\JSON\Templates\Profile_External_Flash\external_flash_driver_raw_template.json. Copy the template under a new name, for example, Projects\STM32H573I-DK\ROT_Provisioning\SM\Binary\JSON\my_external_flash_driver.json.

Below are the contents of the JSON template. Update the following information:

binary must be a relative path from the JSON file to the binary External Flash Driver mentioned in the Example.

Note: The name of the binary can be customized if the path is updated accordingly.

xml must be a relative path from the JSON file to the Projects\STM32H573I-DK\ROT_Provisioning\SM\Images\SM_External_Flash_Driver_Image.xml file.

auto_update must be left to true so that the xml file is automatically updated.
```
{
   "binary":"../../../../Binary/Profile_External_Flash/Ext_Flash_Driver.bin",
   "xml":"../../../../Images/SM_External_Flash_Driver_Image.xml",
   "auto_update":true
}
```
Then, you can update the path to this JSON file in Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini as shown below:

[sfi_generation]
images = {"ns_app"   : "../../Binary/JSON/ns_app_default.json",
          "module_0" : "../../Binary/JSON/module_default.json",
          "FITS"     : "../../Binary/JSON/fits_default.json",
          "external_flash_driver" : "../../Binary/JSON/my_external_flash_driver.json"}

2.2. External Loader

To write images from the SFI into the external flash memory, STM32CubeProgrammer requires an External Loader (see Figure 2). Depending on the use case, STM32CubeProgrammer must identify which External Loader to use and its path. The variables path_el and path_el_sfix in Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini file below are used for this purpose and can be customized:

path_el: relative path to STM32CubeProgrammer for the download use case, see Download subchapter

path_el_sfix: relative path to STM32CubeProgrammer for the provisioning use case, see Provisioning subchapter

[external_loader]
# Relative path from STM32CubeProgrammer path defined in tools.ini
path_el = ./ExternalLoader/MX25LM51245G_STM32H573I-DK.stldr
path_el_sfix = ./ExternalLoader/MX25LM51245G_STM32H573I-DK-RevB-SFIx.stldr

If you use a different External Loader, you must update these paths accordingly.

The External Loader cannot use the following pins as they are secured during the jump into the bootloader:


Peripheral	Pins
GPIO A	13 and 14
GPIO B	11
GPIO C	15
GPIO D	2
GPIO E	1
GPIO F	6
GPIO G	15
GPIO H	15
GPIO I	11

2.3. External flash info

At this stage, all components for the External Flash profile are ready. The provisioning.py script now requires additional information.

The characteristics of the external flash memory must be provided to the provisioning.py script through ext_flash.ini. Using this information, the script verifies the alignment and checks whether the image complies with the external flash memory limits.

For example, with the default external flash memory of the STM32H573I-DK, MX25LM51245G (Macronix, serial NOR, SFDP, 512 Mbits), the size is 65536 KB and 64 KB for each block.

[external_flash_info]
# Flash size in KB
size = 65536
# Block size in KB
block_size = 64

2.4. Download addresses

Before the provisioning command, the memory mapping of the external flash memory can be customized. The download address of each image, indicated in the ext_flash.ini file below can be changed:

secure_manager_core: Secure Manager

module_0: module (if applicable)

FITS: ITS provisioning (if applicable)

ns_app: nonsecure application
```
[download_address]
# Must be in 0x90000000 address space, aligned with external flash block size, fitting in flash size
secure_manager_core = 0x90000000
module_0 = 0x90050000
FITS = 0x90090000
ns_app = 0x900A0000
```
As the comment indicates, each address must meet the following criteria:
- Be within the 0x90000000 address space
- Be aligned with the external flash memory block size
- Fit within the external flash memory size

To help you comply with these constraints, the size of each image is provided in the table below:


Flash memory configuration	Secure Manager Core size	Module size	FITS size	Nonsecure application size
SMAK_0 External Flash profile	248 Kbytes	N/A	16 Kbytes	1 408 Kbytes
SMAK_1 External Flash profile	248 Kbytes	128 Kbytes	16 Kbytes	1 280 Kbytes

Using the information provided in the External flash info subchapter, the script provisioning.py can verify the alignment and check whether the image complies with the external flash memory limits. In case of error, see the External flash layout subchapter.

Note: If you want to reserve a part of the external flash memory for your nonsecure application, this part will not be available as a download slot. Therefore, it must not be included in the memory mapping calculation.

At this step, all the layers and customizations required to provision the Secure Manager are now in place. Proceed with provisioning.

3. Nonsecure application

After provisioning, perform the following steps to add a nonsecure application for the External Flash profile:

Initialization of the external flash memory
If you use the PSA firmware update service:
- Implement the External Flash API defined in the Secure Manager middleware

Figure 11: Nonsecure application interactions with external flash memory

The following subchapters describe all these steps in detail.

3.1. Initialization of the external flash memory

To use the external flash memory, the nonsecure application must initialize it (Figure 11).

An example of the initialization function FW_APP_EXT_FLASH_Init() is available in Projects\STM32H573I-DK\Applications\ROT\SMAK_Appli\Src\external_flash_api.c. This function is used in the main() of SMAK_Appli.

3.2. PSA firmware update service

To use the firmware update service in the External Flash profile, the user must implement the External Flash API to read, write, and erase images in external flash memory.

These APIs, are defined in the middleware at Middlewares\ST\secure_manager_api\interface\inc\extflash\extflash_interface.h and must be implemented in the nonsecure application project.

3.2.1. Generated header file

The aforementioned functions must be included in the nonsecure application project. A header file generated in Projects\STM32H573I-DK\Applications\ROT\SMAK_Appli\Inc\sm_config.h is used for this purpose. Some details about the Python^® environment in the nonsecure application can be found in another wiki: Python^® environment in the nonsecure application.

/* This a generated file of the current configuration, do not edit.*/
#ifndef SM_CONFIG_H
#define SM_CONFIG_H

#define FLASH_LAYOUT_CONFIG 0
#define MODULE_COUNT 0
#define NS_RESERVED_AREA_SIZE 0x0
#define NS_RESERVED_OFFSET 0x81c6000
#define SM_PROFILE_EXTERNAL_FLASH

#endif /* SM_CONFIG_H */

The path of this generated header can be customized by editing [sm].sm_config_header_path in Projects\STM32H573I-DK\Applications\ROT\SMAK_Appli\project.ini file:

[sm]
path=./../../../ROT_Provisioning/SM/
sm_config_header_path = ./Inc/sm_config.h

Warning

The name must not be modified, as it is used in various places in the project, particularly in the middleware.

3.2.2. Implementation of the External Flash API

As seen in Figure 11, the user must implement the External Flash API for the PSA firmware update service purpose.

Three high-level functions are used by the PSA firmware update service (Secure Manager) to access the external flash memory:

sm_extflash_read()

sm_extflash_write()

sm_extflash_erase()

These functions must be implemented in the nonsecure application project.

An example of the implementation of these APIs is available in Projects\STM32H573I-DK\Applications\ROT\SMAK_Appli\Src\sm_external_flash.c.

The definitions of the External Flash API are available in Middlewares\ST\secure_manager_api\interface\inc\extflash\extflash_interface.h and are included in the SMAK_Appli project with the#define SM_PROFILE_EXTERNAL_FLASH from the generated header file. This define is mandatory to include the definitions of the External Flash API in the middleware.

To include the files above only for the External Flash profile, the#define SM_PROFILE_EXTERNAL_FLASH from the generated header file is used in the SMAK_Appli project. This define is used in different places in the project to include files related to the External Flash profile or to use specific functions for the external flash memory.

Note: As a user of the External Flash profile, you do not need to keep this #define to support all cases in your nonsecure application project.

4. Use another external flash memory

At this stage, you have reviewed all required components and environment changes. You are now ready to use a customized External Flash profile.

Figure 12: Items to customize for an external flash memory different from the default

All these items have been covered in the previous chapters:

External Flash Driver

External Flash API

5. Troubleshooting

5.1. General

For general troubleshooting, refer to the dedicated chapter in the following wiki: Security:How to start with Secure Manager customized config on STM32H5: Troubleshooting

5.2. External Flash profile


Error	Possible root cause	Remedy
External Loader
During the flash memory programming at provisioning:	The External Loader for SFIx is either not correctly developed or the path to `path_el_sfix` is incorrect.	If this is your own External Loader, verify your project for the SFIx use case. If this is the default External Loader, verify the `path_el_sfix` setting in the file `Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini`
External Flash Driver
External Flash profile: no boot of the nonsecure application and the discovery command is as follows:	The functions `init()` or `getinfo()` of the External Flash Driver generate an error.	Fix the initialization functions in the External Flash Driver application.
External Flash API
If downloading a new image via FWU fails directly like in the traces below (SMAK_Appli):	External Flash API functions are not developed or not correctly developed. This issue might concern the initialization of the external flash memory in the nonsecure application. Either the initialization function is not correctly implemented, or the function is not called in `main()`.	The three functions in `Project_NS_App\Src\sm_external_flash.c` must be implemented in your nonsecure application project: `sm_extflash_write()` `sm_extflash_read()` `sm_extflash_erase()` Review the initialization function of your external flash memory in your nonsecure application.

5.3. External flash layout

When provisioning is running, the external_flash_layout.txt file is generated in the directory where the script is executed. This file displays the external flash memory layout.

An excerpt of the generated file with default values (configuration 0 module) in ext_flash.ini is shown below:

Flash Memory Layout (each character represents 1KB):
---------------------------------------------------------------------
| Char | Slot Name           | Size     | Start       | End         |
|------|---------------------|----------|-------------|-------------
|  S   | Secure Manager Core |    248KB |  0x90000000 |  0x9003dfff |
|  I   | ITS Factory         |     16KB |  0x90090000 |  0x90093fff |
|  N   | NS appli            |   1408KB |  0x900a0000 |  0x901fffff |
|  X   | Overlap             |          |             |             |
|  .   | Empty               |          |             |             |
---------------------------------------------------------------------
90000000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
90010000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
90020000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
90030000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS........
90040000: ................................................................
90050000: ................................................................
90060000: ................................................................
90070000: ................................................................
90080000: ................................................................
90090000: IIIIIIIIIIIIIIII................................................
900A0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900B0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900C0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900D0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900E0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900F0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90100000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90110000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90120000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90130000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90140000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90150000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90160000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90170000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90180000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90190000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901A0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901B0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901C0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901D0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901E0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
901F0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90200000: ................................................................
90210000: ................................................................
90220000: ................................................................
90230000: ................................................................
90240000: ................................................................
90250000: ................................................................
90260000: ................................................................
90270000: ................................................................
90280000: ................................................................

In case of an error, for example with this configuration:

[download_address]
# Must be in 0x90000000 address space, aligned with external flash block size, fitting in flash size
secure_manager_core = 0x90000000
module_0 = 0x90050000
FITS = 0x90090000
ns_app = 0x90020000

This error occurs during the provisioning:

2025-07-17 15:09:27,299 - ERROR - Overlap detected for NS appli download slot starting at 0x90020000.
2025-07-17 15:09:27,299 - ERROR - Please review the external flash configuration file C:\X-CUBE-SEC-M-H5_VX.Y.Z\Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_External_Flash\ext_flash.ini.
2025-07-17 15:09:27,300 - ERROR - An overview of the external flash layout can be found in C:\X-CUBE-SEC-M-H5_VX.Y.Z\Projects\STM32H573I-DK\ROT_Provisioning\SM\external_flash_layout.txt.

And the generated file external_flash_layout.txt is shown below (extract):

Flash Memory Layout (each character represents 1KB):
---------------------------------------------------------------------
| Char | Slot Name           | Size     | Start       | End         |
|------|---------------------|----------|-------------|-------------
|  S   | Secure Manager Core |    248KB |  0x90000000 |  0x9003dfff |
|  N   | NS appli            |   1408KB |  0x90020000 |  0x9017ffff |
|  X   | Overlap             |          |             |             |
|  .   | Empty               |          |             |             |
---------------------------------------------------------------------
90000000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
90010000: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
90020000: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
90030000: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXNNNNNNNN
90040000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90050000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90060000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90070000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90080000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90090000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900A0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900B0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900C0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900D0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900E0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
900F0000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90100000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90110000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90120000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90130000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90140000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90150000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90160000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90170000: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
90180000: ................................................................
90190000: ................................................................
901A0000: ................................................................
901B0000: ................................................................
901C0000: ................................................................
901D0000: ................................................................
901E0000: ................................................................
901F0000: ................................................................
90200000: ................................................................
90210000: ................................................................
90220000: ................................................................
90230000: ................................................................
90240000: ................................................................
90250000: ................................................................
90260000: ................................................................
90270000: ................................................................
90280000: ................................................................