tfm_demo_s#
Overview#
The Trusted Firmware M (TF-M) demo application provides a sanity check for the TF-M core and RoT services. It can be used as a template for a new application which requires functionality of the TF-M Secure Services.
NOTE: The TF-M main() functions have a non-standard location: - Secure main() is in the tf-m\secure_fw\spm\cmsis_psa\main.c file. - Non-Secure main() is in the tf-m-tests\app\main_ns.c file.
Workspace structure:
tfm_s_crypto_client: Project creating the static library required by the secure processing environment (S)
tfm_demo_s: Project running in the secure processing environment (S)
tfm_demo_ns: Project running in the non-secure processing environment (NS)
Supported Boards#
FRDM-MCXN236
Hardware requirements
Micro USB cable
FRDM-MCXN236 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXN947
Hardware requirements
Micro USB cable
FRDM-MCXN947 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger in your IDE to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development in SDK
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. If IDE allows the two projects in single workspace, the user can also find the project with <application_name>. This project contains both secure and non-secure projects in one workspace (Keil MDK, IAR) and it allows to user easy transition from one to another project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
If IDE (Keil MDK, IAR) allows to manage download both output files as single download, the secure project is configured to download both secure and non-secure output files so debugging can be fully managed from secure project.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXN947T
Hardware requirements
Micro USB cable
FRDM-MCXN947T board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger in your IDE to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development in SDK
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. If IDE allows the two projects in single workspace, the user can also find the project with <application_name>. This project contains both secure and non-secure projects in one workspace (Keil MDK, IAR) and it allows to user easy transition from one to another project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
If IDE (Keil MDK, IAR) allows to manage download both output files as single download, the secure project is configured to download both secure and non-secure output files so debugging can be fully managed from secure project.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-RW612
Hardware requirements
Micro USB cable
FRDM-RW612 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
RW61x specific changes/adaptations of TF-M
1. Use RW61x ROMAPI Flash driver for Flash memory writes
A CMSIS Flash driver glue layer is added which does delegate Flash operations to the ROMAPI Flash driver:
tf-m/platform/ext/target/nxp/common/CMSIS_Driver/Driver_Flash_iap_rw61x.c
2. Use OCOTP for nv rollback counters
An implementation that uses OCOTP as backend for NV counters is available in:
tf-m/platform/ext/target/nxp/rdrw61x/nv_counters.c
tf-m/platform/ext/target/nxp/rdrw61x/platform_sp.c
A RAM emulation of the OTP fuses is provided. This emulation offers more fuses than are available in OCOTP. This emulation is done for mainly two reasons:
during development/testing one does not want to make permanent changes to an IC
the available number of fuses available in OCOTP is very limited and therefore the max achievable counter/max achievable object writes is not big enough for the amount needed for all the TF-M tests to run.
The RAM emulation is enabled by defining preprocessor flag:
OCOTP_NV_COUNTERS_RAM_EMULATION
This flag is enabled in the default SDK build. Building without the flag being defined results in a build error for safety reasons (not to accidentially enable OTP writes) and requires to remove an #error line from the respective source file.
3. Use IPED and rollback protection for ITS service
An additional Flash driver is introduced and used for ITS:
tf-m/platform/ext/target/nxp/common/CMSIS_Driver/Driver_Flash_iap_rw61x_iped.c
This driver makes use of the RW61x HW supported IPED. By using device specific encryption keys, this binds the external Flash to the IC. In addition to encryption, also rollback protection is introduced in this driver layer and therefore a security level similar to an internal Flash.
For development/debugging encryption and rollback protection can be selectively enabled/disabled with preprocessor defines. In the default SDK build, both features are enabled, one can set following options to enable/disable these:
RW61X_IPED_ENCRYPT_ENABLE : 1/0
RW61X_IPED_ITS_ROLLBACK_PROTECTION_ENABLE : 1/0
4. Use ELS/S50 keys as ROT for HUK and IAK
It is possible to rely on NXP-provisioned data as ROT for HUK and IAK. The RW61x boot ROM bootloader installs several keys in ELS keyslots that are usable as ROT.
For HUK, the TF-M mechanism of built-in keys is reused. Upon startup a HUK is derived from the DIE_INT_MK_SK (loaded by RW61x boot ROM) and stored in the builtin_key_loader of TF-M. The TF-M default TF-M mechanisms for deriving sub keys from this can then me used.
For IAK, no key is loaded to the builtin_key_loader. Instead, when an attestation signature is done, a key is derived from NXP_DIE_EL2GOPUBLIC_MK_SK (loaded by RW61x boot ROM) on the fly at the point in time the signature is calculated. Only asymmetric attestation is supported by this mechanism.
Both of them can be individually be enabled or disabled with preprocessor flags:
USE_ELS_PKC_HUK
USE_ELS_PKC_IAK
MCX-N5XX-EVK
Hardware requirements
Micro USB cable
MCX-N5XX-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger in your IDE to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development in SDK
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. If IDE allows the two projects in single workspace, the user can also find the project with <application_name>. This project contains both secure and non-secure projects in one workspace (Keil MDK, IAR) and it allows to user easy transition from one to another project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
If IDE (Keil MDK, IAR) allows to manage download both output files as single download, the secure project is configured to download both secure and non-secure output files so debugging can be fully managed from secure project.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
MCX-N9XX-EVK
Hardware requirements
Micro USB cable
MCX-N9XX-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger in your IDE to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development in SDK
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. If IDE allows the two projects in single workspace, the user can also find the project with <application_name>. This project contains both secure and non-secure projects in one workspace (Keil MDK, IAR) and it allows to user easy transition from one to another project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
If IDE (Keil MDK, IAR) allows to manage download both output files as single download, the secure project is configured to download both secure and non-secure output files so debugging can be fully managed from secure project.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
RD-RW612-BGA
Hardware requirements
Micro USB cable
RDRW612bga board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
RW61x specific changes/adaptations of TF-M
1. Use RW61x ROMAPI Flash driver for Flash memory writes
A CMSIS Flash driver glue layer is added which does delegate Flash operations to the ROMAPI Flash driver:
tf-m/platform/ext/target/nxp/common/CMSIS_Driver/Driver_Flash_iap_rw61x.c
2. Use OCOTP for nv rollback counters
An implementation that uses OCOTP as backend for NV counters is available in:
tf-m/platform/ext/target/nxp/rdrw61x/nv_counters.c
tf-m/platform/ext/target/nxp/rdrw61x/platform_sp.c
A RAM emulation of the OTP fuses is provided. This emulation offers more fuses than are available in OCOTP. This emulation is done for mainly two reasons:
during development/testing one does not want to make permanent changes to an IC
the available number of fuses available in OCOTP is very limited and therefore the max achievable counter/max achievable object writes is not big enough for the amount needed for all the TF-M tests to run.
The RAM emulation is enabled by defining preprocessor flag:
OCOTP_NV_COUNTERS_RAM_EMULATION
This flag is enabled in the default SDK build. Building without the flag being defined results in a build error for safety reasons (not to accidentially enable OTP writes) and requires to remove an #error line from the respective source file.
3. Use IPED and rollback protection for ITS service
An additional Flash driver is introduced and used for ITS:
tf-m/platform/ext/target/nxp/common/CMSIS_Driver/Driver_Flash_iap_rw61x_iped.c
This driver makes use of the RW61x HW supported IPED. By using device specific encryption keys, this binds the external Flash to the IC. In addition to encryption, also rollback protection is introduced in this driver layer and therefore a security level similar to an internal Flash.
For development/debugging encryption and rollback protection can be selectively enabled/disabled with preprocessor defines. In the default SDK build, both features are enabled, one can set following options to enable/disable these:
RW61X_IPED_ENCRYPT_ENABLE : 1/0
RW61X_IPED_ITS_ROLLBACK_PROTECTION_ENABLE : 1/0
4. Use ELS/S50 keys as ROT for HUK and IAK
It is possible to rely on NXP-provisioned data as ROT for HUK and IAK. The RW61x boot ROM bootloader installs several keys in ELS keyslots that are usable as ROT.
For HUK, the TF-M mechanism of built-in keys is reused. Upon startup a HUK is derived from the DIE_INT_MK_SK (loaded by RW61x boot ROM) and stored in the builtin_key_loader of TF-M. The TF-M default TF-M mechanisms for deriving sub keys from this can then me used.
For IAK, no key is loaded to the builtin_key_loader. Instead, when an attestation signature is done, a key is derived from NXP_DIE_EL2GOPUBLIC_MK_SK (loaded by RW61x boot ROM) on the fly at the point in time the signature is calculated. Only asymmetric attestation is supported by this mechanism.
Both of them can be individually be enabled or disabled with preprocessor flags:
USE_ELS_PKC_HUK
USE_ELS_PKC_IAK
FRDM-MCXA287
Hardware requirements
Micro USB cable
MCXL255-M33 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
[INF][PS] Encryption alg: 0x5500100
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-IMXRT700
Hardware requirements
Micro USB cable
frdmimxrt700 board
Personal Computer
Board settings
Switch the JP45 jumper to the 2-3 configuration and the JP46 jumper to the 2-3 configuration to enable XSPI1 memory access. Switch the SW10 boot mode switch to the 11 XSPI1 flash configuration.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-RT700 - TF-M Integration Notes
1- Internal Trusted Storage (ITS) Support
The current TF-M implementation for the FRDM-RT700 platform supports Internal Trusted Storage (ITS) using the external flash (XSP1). While this enables persistent storage capabilities, it is important to note the following limitations and considerations:
Unprotected External Flash: The XSP1 flash used for ITS is external and does not provide encryption or hardware-based protection by default. This means that sensitive data stored in this region is potentially vulnerable to unauthorized access.
User Responsibility for Security: It is the user’s responsibility to ensure appropriate protection mechanisms are in place for the XSP1 flash region. This may include implementing custom encryption, access control, or secure boot mechanisms.
Alternative ITS in RAM: For applications requiring higher security guarantees, users may opt to configure ITS to use RAM-based storage. While this approach sacrifices persistence across power cycles, it offers better protection for sensitive data in scenarios where external flash cannot be adequately secured.
Future Enhancements
Support for IPED-based protection of the XSP1 flash is planned in future TF-M releases for FRDM-RT700. This will enable hardware-enforced isolation and encryption, significantly improving the security of ITS data stored in external flash.
MCIMX93-EVK
Hardware requirements
USB Type-C cable
MCIMX93-EVK board
J-Link Debug Probe
12V~20V power supply
Personal Computer
Board settings
Note
Please load the application from u-boot in Single boot mode. By default the example assumes secure binary will be loaded in TCM and non secure binary in OCRAM. If you are booting Linux on Cortex A with this example running on cortex M33, donot use ethos driver to avoid conflict as ethos driver used OCRAM.
This example can be run from TCM memory also without using OCRAM. To do so, check Section “Compile TF-M to work only from TCM” below.
Prepare the Demo
Connect 12V~20V power supply and J-Link Debug Probe to the board, switch SW301 to power on the board.
Connect a USB Type-C cable between the host PC and the J1401 USB port on the target board.
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Download the demo binaries to the target board.
Reference “Running an application by U-Boot” https://mcuxpresso.nxp.com/mcuxsdk/latest/html/boards/i.MX/mcimx93evk/gettingStarted/topics/running_an_application_by_u-boot.html#running-an-application-by-u-boot Reference ‘Getting Started with MCUXpresso SDK for MCIMX93-EVK.pdf’ to download the demo binaries on board.
Download the tfm_demo_s_cm33.bin to TCM, tfm_demo_ns_cm33.bin to OCRAM. Then boot the cortex M33 core. fatload mmc 1 0x80000000 tfm_demo_s_cm33.bin; cp.b 0x80000000 0x201e0000 0x20000 fatload mmc 1 0x80020000 tfm_demo_ns_cm33.bin; cp.b 0x80020000 0x20480000 0x18000; dcache flush; bootaux 0x1ffe0000 0
Prints will appear on the serial terminal for Cortex M-33
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TF-M Features supported on MCIMX93EVK
Default secure binary on TCM ( max codesize 128K, data size 128K) , non secure binary to be loaded on ocram ( codesize 192k, data size 192k)
TF-M platform port assumes the trdc configuration has been done by cortex A core and secure privileged access has been granted to cortex M core domain. It would further program TRDC to divide resources between secure and non secure domain on cortex m core ( see platform/ext/target/target_cfg.c for more details)
Crypto partition is software based. Crypto accelerator is not supported on the platform.
By default storage is emulated on RAM ( ITS_ON_RAM, PS_ON_RAM). There is no flash support available as by default evk board comes without flash
SDK currently supports only medium profile builds.
Compile TF-M to work only from TCM
Total TCM available for code is only 128K on this platform. To shift both secure and non secure binaries to TCM, the code sizes of both binaries should not be more than 128K. To enable that, in file tf-m/platform/ext/target/nxp/mcimx93evk/partition/flash_layout.h comment the following line at line number 21 and recompile. #define NS_PARTITION_ON_OCRAM 1
In current configuration, if you disable the above option, given below is the Secure and Non secure code size chosen. You can change that based on your usecase in the flash-layout.h file. #define IMAGE_S_CODE_SIZE (96 * 1024) /* Secure Binary code Max size / #define IMAGE_NS_CODE_SIZE (32 * 1024) / Non Secure Binary code Max size */
If such a change is done secure and non secure binaries should be loaded on required offsets in TCM. Example steps to do so from u-boot are given below: fatload mmc 1 0x80000000 tfm_demo_s_cm33.bin fatload mmc 1 0x80018000 tfm_demo_ns_cm33.bin cp.b 0x80000000 0x201e0000 0x20000; bootaux 0x1ffe0000 0
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
MCXW23-EVK
Hardware requirements
Micro USB cable
MCXW23-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
KW47-EVK
Hardware requirements
Mini/Micro USB cable
KW47-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
MIMXRT700-EVK
Hardware requirements
Micro USB cable
mimxrt700evk board
Personal Computer
Board settings
Switch the JP45 jumper to the 2-3 configuration and the JP46 jumper to the 2-3 configuration to enable XSPI1 memory access. Switch the SW10 boot mode switch to the 11 XSPI1 flash configuration.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
RT700EVK - TF-M Integration Notes
1- Internal Trusted Storage (ITS) Support
The current TF-M implementation for the RT700EVK platform supports Internal Trusted Storage (ITS) using the external flash (XSP1). While this enables persistent storage capabilities, it is important to note the following limitations and considerations:
Unprotected External Flash: The XSP1 flash used for ITS is external and does not provide encryption or hardware-based protection by default. This means that sensitive data stored in this region is potentially vulnerable to unauthorized access.
User Responsibility for Security: It is the user’s responsibility to ensure appropriate protection mechanisms are in place for the XSP1 flash region. This may include implementing custom encryption, access control, or secure boot mechanisms.
Alternative ITS in RAM: For applications requiring higher security guarantees, users may opt to configure ITS to use RAM-based storage. While this approach sacrifices persistence across power cycles, it offers better protection for sensitive data in scenarios where external flash cannot be adequately secured.
Future Enhancements
Support for IPED-based protection of the XSP1 flash is planned in future TF-M releases for RT700EVK. This will enable hardware-enforced isolation and encryption, significantly improving the security of ITS data stored in external flash.
FRDM-MCXA577
Hardware requirements
Micro USB cable
MCXL255-M33 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
[INF][PS] Encryption alg: 0x5500100
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXW23
Hardware requirements
Micro USB cable
FRDM-MCXW23 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXW71
Hardware requirements
Mini/Micro USB cable
FRDM-MCXW71 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
MCX-W72-EVK
Hardware requirements
Mini/Micro USB cable
MCX-W72-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
MCX-W71-EVK
Hardware requirements
Mini/Micro USB cable
MCX-W71-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXW72
Hardware requirements
Mini/Micro USB cable
FRDM-MCXW72 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
KW45B41Z-EVK
Hardware requirements
Mini/Micro USB cable
KW45B41Z-EVK board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500100
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-KW43
Hardware requirements
Micro USB cable
FRDMKW43 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.4
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
Creating an empty ITS flash layout.
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.
FRDM-MCXL255
Hardware requirements
Micro USB cable
MCXL255-M33 board
Personal Computer
Board settings
No special settings are required.
Prepare the Demo
Connect a micro USB cable between the PC host and the CMSIS DAP USB port on the board
Open a serial terminal with the following settings:
115200 baud rate
8 data bits
No parity
One stop bit
No flow control
Use secure project to download the program to target board. Please refer to “TrustZone application debugging” below for details.
Launch the debugger to begin running the demo.
Running the demo
The log below shows the output of the TFM demo in the terminal window:
Booting TF-M v2.1.1
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled
[INF][PS] Encryption alg: 0x5500100
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
Non-Secure system starting...
TrustZone Application Development
Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project.
The secure project is stored in <application_name><application_name>_s directory. The non-secure project is stored in <application_name><application_name>_ns directory.
The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project.
TrustZone application compilation
Please compile secure project firstly since CMSE library is needed for compilation of non-secure project. After successful compilation of secure project, compile non-secure project.
TrustZone application debugging
Download both output file into device memory
Start execution of secure project since secure project is going to be executed after device RESET.
Device header file and secure/non-secure access to the peripherals
Both secure and non-secure project uses identical device header file. The access to secure and non-secure aliases for all peripherals is managed using compiler macro __ARM_FEATURE_CMSE.
For secure project using <PERIPH_BASE> means access through secure alias (address bit A28=1), using <PERIPH_BASE>_NS means access through non-secure alias(address bit A28=0) For non-secure project using <PERIPH_BASE> means access through non-secure alias (address bit A28=0). The non-secure project doesn’t have access to secure memory or peripherals regions so the secure access is not defined.