Version 1.1

New Features

  • Upgraded MCUBoot to v1.6.0., default is now the upstream MCUBoot instead of the TF-M fork.

  • TF-Fuzz tool for fuzz testing PSA APIs.

  • Updated Source code folder structure.

  • IAR compiler support.

  • LPCXpresso55S69-EVK board support.

  • Add Profile Small.

  • Enable Ninja CMake Generator.

  • FVP_SSE300_MPS2 platform support.

  • Rename SST(Secure STorage) to PS(Protected Storage) and partition moved from PSA Root of Trust to Application Root of Trust.

  • NUCLEO-L552ZE-Q and DISCO-L562QE platform support.

  • Restructure documentation to make it more user-friendly.

  • Enable Attestation service to use symmetric key algorithm.

  • Use CMSIS for testing from tf-m-tests repository. This removes dependency on the external CMSIS_5 repo.

New Platforms supported

New Platforms limitations

  • LPCXpresso55S69-EVK doesn’t support BL2.

  • LPCXpresso55S69-EVK doesn’t support ARMCLANG and IARARM toolchain. Patch with support for IARARM is available at #4023

  • FVP_SSE300_MPS2 doesn’t support GNUARM and IARARM toolchain. Patch with support for IARARM is available at #4574

Known issues

Some open issues exist and will not be fixed in this release.

All the supported GNUARM toolchain versions generate corrupt veneer
code for Armv8-M baseline architecture, when the -Os optimization flag
is used. This affects the AN519 and AN539 platforms built with GNUARM
toolchain and Minsizerel build type.


PSA Arch Crypto tests have several known failures.

See this link for detailed analysis of the failures :

AN521 FVP soft reset via AIRCR does not reset MPC / PPC / MPU and will
cause boot failure. This is known issue for AN521 FVP. This will cause
the system to not boot after a warm reset during PSA Arch FF testing.


There are 2 additional failures for PSA-Arch Crypto tests with CC-312
other than the known failures. This is due to limitation of CC-312
implementation as it does not support MD_NONE hashing mode causing the
additional failures.


Boot up fails if there is unexpected data in flash on Musca-A. The boot
is successful and the tests pass if all the associated (PS/ITS/NV
Counter) flash areas are erased.


When PS/ITS are using Flash on Musca-B1, PSA Arch FF test fails due to
known warm reset limitation in the platform. There is an issue with
Musca-B1 QSPI flash that causes this failure. The fix is under


Issues fixed since 1.0

The eflash driver on Musca-B1 can return random failures hence
triggering random failures during PSA Arch ITS and PSA Arch PS tests.
This happens when ITS/SST is configured to use flash.


Release build of PSA Arch Crypto tests have a different number of tests
when built for AN521 FVP. This is an issue in the PSA Arch Crypto

Issue for PSA Arch Tests project :

Copyright (c) 2020, Arm Limited. All rights reserved.