Figure 24. Non-Secure Image Format - ST STM32CubeL5 User Manual

To use the Non-Secure image secondary slot, data shall be written at the correct format in the Non-Secure image
secondary slot area as illustrated hereafter:
Parameters
Candidate image written in the "Non-Secure image secondary" slot.
Actions
At each product reset TOE (TFM_SBSFU application) checks if a new Non-Secure image has been pre-loaded by
the non- secure application in the "Non-Secure image secondary" slot. The new non-secure image shall be
programmed at the beginning of the "Non-Secure image secondary" slot and shall comply with the image format
(image header + image data) as defined by TFM_SBSFU application. When compiling TFM_Appli non-secure
project delivered in STM32Cube_FW_L5_V1.1.0 SW package (\Projects\STM32L562E-DK\Applications\TFM
\TFM_Appli\STM32CubeIDE\ Project_ns.uvprojx) the TFM_Appli Non-secure sign binary with the right format is
automatically generated (TFM_Appli\Binary\tfm_ns_sign.bin). When a new Non-secure image is detected,
TFM_SBSFU application will launch the update procedure of the Non-secure Image (that verifies the data before
updating the firmware).
Errors:
Candidate image is not installed in the "Secure image primary" slot in case of following errors:
• Version dependency failure: version of secure image non consistent with version of the non-secure image.
Candidate image is not installed in the "Secure image primary" slot and is erased from "Secure image secondary"
slot in case of following errors:
• Image size not consistent
• Flash reading errors (double ECC errors).
• Version check failure: Image version < previous valid image installed
• Version dependency failure: version of secure image non consistent with version of the non-secure image.
• Image signature failure: image not authentic
Candidate image is not installed in the "Secure image primary" slot and TOE is blocked in an infinite loop:
Flash writing or flash erasing error could be reported by the flash driver used by the application to write data in the
Secure image secondary" slot area.
PSA API interface
The PSA API interfaces the secure services hosted in the secure application ROT. These API are used (or called)
by the Non-secure world, but can also be called by the secure application ROT(secure services running in secure
domain with unprivileged rights), it provides a programmatic interface to trigger secure functionalities running in
secure domain with privileged rights. The integrator calls these C APIs and builds a complete secure application
by compiling the TOE source code with application RoT code. The detailed parameters, actions and error
messages are described in the PSA developer APIs [PSA_ST_API], [PSA_CRYPTO_API] and
[PSA_ATTESTATION_API].
UM2745 - Rev 1
Figure 24. Non-secure image format
Operational guidance for the role integrator
UM2745
page 27/36