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örnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1x-apple-data-detectors://6/1 SE-750 23 Uppsala, SWEDENx-apple-data-detectors://6/1 Mobile: +46 76 180 17 80tel:+46%2076%20180%2017%2080 Fax: +46 18 16 78 01tel:+46%2018%2016%2078%2001 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
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.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m