tests: portability: tests/portability/cmsis_rtos_v2 fails on nrf5340dk_nrf5340_cpuappns

[PerMac]

Describe the bug
The test test_semaphor from the test suite under tests/portability/cmsis_rtos_v2 fails on nrf5340dk_nrf5340_cpuappns causing the rest of tests in the test suite to fail. It causes >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU. The suite is terminated then only by the timeout.

To Reproduce
Steps to reproduce the behavior:

1. have nrf5340dk connected
2. go you your zephyr dir
3. call ./scripts/twister -T /home/maciej/zephyrproject2/zephyr/tests/portability/cmsis_rtos_v2/ -p nrf5340dk_nrf5340_cpuappns --device-testing --device-serial /dev/ttyACM2 -v --inline-logs
4. See error

Expected behavior
The test passes

Impact
not clear

Logs and console output

===================================================================
START - test_semaphore
ASSERTION FAIL [thread->base.pended_on] @ WEST_TOPDIR/zephyr/kernel/sched.c:585
ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/spinlock.h:129
Recursive spinlock 0x20042230
E: r0/a1:  0x00000004  r1/a2:  0x00000081  r2/a3:  0x00000001
E: r3/a4:  0x000542c5 r12/ip:  0x80000000 r14/lr:  0x0005879d
E:  xpsr:  0x41000025
E: Faulting instruction address (r15/pc): 0x0005bb24
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Fault during interrupt handling
E: Current thread: 0x20040d54 (Mutex_check)
E: Halting system

Environment (please complete the following information):

• OS: Ubuntu 18.04
• Toolchain Zephyr SDK 0.12.2
• Commit SHA or Version used zephyr-v2.5.0-1069-g4fbd0cb0ca6b

[ioannisg]

Thanks for the report @PerMac , I 'll take a look. I wonder if this kernel panic is specific to an _NS build, or this gets to fail on other platforms as well. In principle, this failure does not look related to security in cortex-m....

[PerMac]

I haven't seen it on any other nrf platform I am handling. In particular, the test suite passes on nrf5340dk_nrf5340_cpuapp

[ioannisg]

Will take a look as soon as possible

[ioannisg]

@oyvindronningstad do you reproduce this on nRF9160_ns?

[oyvindronningstad]

@ioannisg I cannot reproduce this on 91ns.

I reproduced it on 53ns in both zephyr and nrf (upmerge)

It only happens with TFM, not with SPM.

[ioannisg]

Thanks @oyvindronningstad , I am looking into this right now.

[ioannisg]

The failure is probably just appearing on nRF5340 NS, but it is only because the osDelay() function does not work as expected, and the scheduling order is not always what the test expects.