Turns out the issue was with the timer interrupt routine clobbering a register when compiled with no optimization.

I have a workaround, but I’m also working with the compiler developers on what the proper behavior is.

Thomas

Thomas TörnblomProduct 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.com Website: www.iar.com
Twitter: www.twitter.com/iarsystems

6 feb. 2020 kl. 09:56 skrev Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>:

 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.com Website: www.iar.com
Twitter: www.twitter.com/iarsystems
--
TF-M mailing list
TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m