Hi Thomas,

A brief description of this test scenario is in docs\user_guides\services\core_test_services_integration_guide.rst:

<quote> - S code waits for an interrupt (calling ``psa_wait()``), the handler is in the service that is waiting, ``psa_eoi()`` is called after ``psa_wait()`` returns (``IRQ_TEST_SCENARIO_4``) <end quote>

ConfigRegression.cmake is using the library model, so that implementation needs to be considered.

In this scenario only a secure interrupt is involved.

The sequence is the following (only relevant code parts are mentioned):

1. spm_irq_test_1_prepare_test_scenario_internal() starts the secure timer. 2. spm_irq_test_1_execute_test_scenario() enters a while loop, waiting the signal for the timer to be set call psa_wait(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, PSA_BLOCK); 3. at some point the interrupt is triggered, and the signal is set for the interrupt. The interrupt handler is run, and it sets a flag timer0_triggered. SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ_isr() is the interrupt handler function in this case, and this function executes an explicit "DSB" instruction to be sure that the write to the flag is committed. (The flag is declared as volatile) 4. When the function spm_irq_test_1_execute_test_scenario() exits the loop, it calls pas_eoi(), and returns.

At the moment I don't see a flaw in this scenario, which of course gives no guarantee that there isn't a flaw in it somewhere.

We often test TF-M in FVP, and found that from time to time the FVP runs slower (seems to be executing less cycles per minute) than usual. In this cases IRQ testcases appeared to be hanging, although if we waited for the necessary number of cycles to be executed by the FVP, these tests always passed.

Did you have a chance to have a look at it with a debugger? If so, where exactly is the execution stucked? Have the interrupt been triggered as expected?

Regards, Mate

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, February 6, 2020 9:56 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4?

How is the IRQ_TEST_SCENARIO_4 supposed to work?

I suspect that there might be a lurking race condition somewhere in that test.

Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations.

Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem.

Thomas --

Thomas T�rnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems