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,

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.

I tried this on my side on STM32L562e_dk board with TF-M repo: enable "-mfloat-abi=softfp" in NS side and use TF-M default "-mfloat-abi=soft" option, and changed FP registers in non-secure thread first, then do PSA call. When system is in secure thread mode, no crash found even FPCCR_S.LSPACT = 1.

Do you have FP instruction in secure thread? If there is no FP instruction, the processor will not stack FP registers even LSPACT flag is set.
I tried this on my side on STM32L562e_dk board with TF-M repo: enable "-mfloat-abi=softfp" in NS side and use TF-M default "-mfloat-abi=soft" option, and changed FP registers in non-secure thread first, then do PSA call. When system is in secure thread mode, no crash found even FPCCR_S.LSPACT = 1.

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.

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.

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."

Yes, it crashes even without Lazy Stacking. It is a bit more deterministic as is. It crashes in the first secure exception entry, after the transition to secure domain from non-secure.

But for Zephyr, are you using soft FP or hardware FP?

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.

Hi Feder,

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.

Merged.

Hi @ioannisg,
FYI. Feder is on holiday and will back to office on 10th May.
Thanks.

Setting this to High for now - but feel free to re-triage this was not appropriate.

Hi Feder,

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.

The first patch for this:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9730

Currently GNU 10-2020-q4-major cannot support CMSE well (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getting_started/tfm_sw_requirement.rst#n54).
So this GNU version won't be supported in TF-M.

I built with

In T911#10554, @davidhuziji wrote:

I will run the GCC version later to check if there are more warnings. Will collect all the warnings and fix them in one shot later.

Would fix after the release. Mark as a long term goal.

Okay, I run into a fault when apply this patch on AN521, may need some investigations :
Running Test Suite Core non-secure interactive tests (TFM_CORE_TEST_2XXX)...

Executing 'TFM_CORE_TEST_2001'

Description: 'Interactive tests'

Segmentation fault

You will need to apply this patch in order for the interactive tests to function as without it the secure part will never build with that part enabled https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/9431
After applying that and building using:

cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=off -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DTFM_INTERACTIVE_TEST=on -DTFM_PERIPH_ACCESS_TEST=ON -DTFM_IRQ_TEST=ON ..

And running it, the first test passes but the freezes at the same point as yours does, it does not continue with the next task

I took a look at this test case, the interactive test suit is disabled by default. Could you append some logs or command on your platform of TFM_CORE_TEST_2001
The test from my side on AN521 will stop after scenario 1:

Executing 'TFM_CORE_TEST_2001'

Description: 'Interactive tests'

Scenario 1 - SequentialTrying to acquire the TFM core from NS [seq_task]NS Lock: acquired [seq_task]Secure call to tfm_spm_core_test_sfn_veneer(&in_vec, 1, NULL, 0) failed, generic!NS Lock: releasing... [seq_task]Scenario 1 - test finished

@oyvind.ronningstad@nordicsemi.no This issue is on the Nordic platform. Can you take a look at it?

Assigned to Ken for the warning fix.

I will run the GCC version later to check if there are more warnings. Will collect all the warnings and fix them in one shot later.

Test results:
FPGA:

Above patch has been abandoned, as it is not important at the current stage.

Verified that it passed the compiling & running tests, with the reverted patch.
Thank you for the quick response/fix~

Apparently, the patch didn't work for GCC. Sorry about that.
It has been reverted for the time being:
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/7651

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7577

Hello,
Here are 2 commits to introduce the support of external flash for secondary slot
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7412
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7413

The whole problem has boiled down to a flash write issue and it has been worked around by c32710c7fc8514dd0d072a01549e23a94278ee17.

Verified with https://github.com/zephyrproject-rtos/zephyr/pull/30226

This issue is now fixed and can be closed

Patch fixed and merged

Closed the previous issue https://developer.trustedfirmware.org/T845 as duplicate

Internal ref : https://jira.arm.com/browse/IOTPSW-3471

Thanks, everybody.

Tested changes on LPC55S69, both patches seem good here.

Related code reviews:

• https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5534
• https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6517

The latest FVP claims to have resolved this problem. This needs to be re-tested on latest AN521 FVP.

Change has been successfully submitted