Wow, what a great post! I like it very much and cool that I recognized about 90% of them without hovering to see the Real DP-100 Exam Questions

The 1.4.x branch is only intended for security fixes.
https://developer.trustedfirmware.org/w/collaboration/tf_m_security_patch_release/

Thanks for your check. Would you also backport the patch to TF-M 1.4?

I think you're right.
The Secure PendSV is masked by NSPE, although it has the same priority value 0x80.
It has to have a lower value to preempt the NSPE, having an equal priority value does not work.

If it's an RTX issue, then please contact RTX people. Thanks very much.

This issue has been fixed by:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10402

Ran into this as well when porting a new target and trying to get all constellations of test suites up and running. It seems to be an issue with how thread joins are handled during RtxThreadExit in RTX 5.5.0. Tracing the disassembly in the kernel makes me think there's some sort of optimisation bug in the precompiled libraries, since the idle thread is marked for running instead of the test thread (which was waiting on the join).

This issue has been fixed.

Note that as part of this activity the following bug in the Qemu porting of the mps2-an521 board has been found and fixed with the following pull request:

Patches available here:

As you know, for secure and non-secure side are closely related in TF-M. In latest TF-M v1.3 release, FP support (in secure side either non-secure side) are not official announced, so the problem you reported is not a TF-M bug.

Thank you for letting us know the problem when you are using TF-M, this is helpful for all stakeholder of TF-M.

Hi Feder,
Honestly, I've only faced this issue when doing some advance scheduling manipulations on the Non-Secure side (modifying LSPACT, FPCA, etc.), so not in mainline TF-M/RTOS use-cases. Please disregard it for now.

In T921#10778, @ioannisg wrote:

However, this is only a partial solution. That is because a Secure thread re-scheduling will clear the .FPCA flag, but leave the LSPACT set, meaning that a NS IRQ with FP instructions will trigger again an FP stacking. But this FP stacking will be done on the memory where FPCAR is pointing at, and FPCAR is only updated in exception entry, if .FPCA is set. As a result, it does not seem that you avoid a stack corruption.

Let me know if you've understood this argumentation, or you need more information.

Any updates here, Feder?

However, this is only a partial solution. That is because a Secure thread re-scheduling will clear the .FPCA flag, but leave the LSPACT set, meaning that a NS IRQ with FP instructions will trigger again an FP stacking. But this FP stacking will be done on the memory where FPCAR is pointing at, and FPCAR is only updated in exception entry, if .FPCA is set. As a result, it does not seem that you avoid a stack corruption.

Hi Feder, correct; setting CPACR_S solves the problem of Secure No-Coprocessor Usage Fault.

Please try to add code below just before setting NSACR in tfm_arch_config_extensions() and let me know the result. Thanks!

Hi Feder,

IAR Embedded Workbench for Arm is an integrated development work environment and the included IAR C/C++ Compiler generates the fastest performing, although there are tons of projects like CV Makers which are based on IAR.