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

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.

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

I tried on my side with steps above, and I still cannot reproduce your issue.
Please confirm NSACR register is configured correctly, and check the FP related registers before the FP instruction causing crash.

TF-M currently support "-mfloat-abi=soft" as default, but doesn't support the setting in Zephyr "-mfloat-abi=softfp". Because they are totally different things.

But why? These ABIs are link-compatible, I do not see the problem. GCC allows these binaries to link successfully.

I mean TF-M itself current FP option is "-mfloat-abi=soft", not the "-mfloat-abi=softfp" which is used in Zephyr. It doesn't matter with setting for Zephyr.

This is the explanation for "FP_SOFTABI" in Zephyr.
"config FP_SOFTABI
bool "Floating point Soft ABI"
help

	  This option selects the Floating point ABI in which hardware floating
	  point instructions are generated but soft-float calling conventions."

The first thing I want to confirm is "I compile zephyr and Tf-M with soft FP". As you know, TF-M is default with soft FP.

1. But for Zephyr, are you using soft FP or hardware FP?
2. Is it possible for you to share the compile options and linker options for the source file including the "Non-Secure interrupt" crashing?
3. Is it possible to show the assembly code for the "Non-Secure interrupt"?
4. Please have a try to disable lazy FP stacking, to see whether still crash.

If you didn't change TF-M while integrating into your project, PSA call(handler mode) cannot be interrupted by non-secure interrupt like you mentioned, the reason is non-secure exceptions are de-prioritized (AIRCR.PRIS = 1) in TF-M.
Non-secure interrupt can only be active when system in thread mode.

For the concern you mentioned, yes, we need to add extra steps in secure scheduler, I am still working on this part.

1. When secure doing secure calls: a. if lazy fp is disabled, hardware will push/pop FP context automatically during exception entry/return. b. if lazy fp is enable, for isolation 1, secure scheduler will save and restore FP context, but not invalidate FP context; for isolation 2 and 3, secure scheduler will trigger lazy fp stacking, hardware will push FP context to thread' stack and invalidate them automatically.
2. When non-secure doing secure calls, non-secure side will SG to secure world in tfm_nspm_thread_entry, then doing secure calls as same as above. FP context of non-secure can be restored when bxns lr to non-secure side.