tests/kernel/fatal/kernel.common.stack_sentinel fails on FRDM-KW41Z

[galak]

With commit: aed767a

Running via:

./scripts/sanitycheck -p frdm_kw41z --device-testing --device-serial /dev/serial/by-id/usb-ARM_DAPLink_CMSIS-DAP_0201000028634e45000b5002673a0032a101000097969900-if01 -s tests/kernel/fatal/kernel.common.stack_sentinel

Get the following output:

***** Booting Zephyr OS build v2.0.0-rc1-173-gaed767a98c00 *****
Running test suite fatal
===================================================================
starting test - test_fatal
test alt thread 1: generic CPU exception
FATAL: ***** HARD FAULT *****
FATAL: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000000
FATAL: r3/a4:  0x20000ac4 r12/ip:  0x20000158 r14/lr:  0x00000735
FATAL:  xpsr:  0x40000000
FATAL: Faulting instruction address (r15/pc): 0x20000ac4
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 0
test alt thread 2: initiate kernel oops
FATAL: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000003
FATAL: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x00003991
FATAL:  xpsr:  0x01000000
FATAL: Faulting instruction address (r15/pc): 0x00000756
FATAL: >>> ZEPHYR FATAL ERROR 3: Kernel oops
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 3
test alt thread 3: initiate kernel panic
FATAL: r0/a1:  0x00000004  r1/a2:  0x00000000  r2/a3:  0x00000004
FATAL: r3/a4:  0x00000000 r12/ip:  0x00000756 r14/lr:  0x00003991
FATAL:  xpsr:  0x01000000
FATAL: Faulting instruction address (r15/pc): 0x0000076e
FATAL: >>> ZEPHYR FATAL ERROR 4: Kernel panic
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 4
test alt thread 4: fail assertion
ASSERTION FAIL [0] @ ZEPHYR_BASE/tests/kernel/fatal/src/main.c:123
	intentionally failed assertion
FATAL: r0/a1:  0x00000004  r1/a2:  0x0000007b  r2/a3:  0x000042d8
FATAL: r3/a4:  0x00000791 r12/ip:  0x0000076e r14/lr:  0x00000799
FATAL:  xpsr:  0x21000000
FATAL: Faulting instruction address (r15/pc): 0x00003c84
FATAL: >>> ZEPHYR FATAL ERROR 4: Kernel panic
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 4
test stack sentinel overflow - timer irq
posting 1024 bytes of junk to stack...
FATAL: ***** HARD FAULT *****
FATAL: r0/a1:  0x00000002  r1/a2:  0xbbbbbbbb  r2/a3:  0xf0f0f0f0
FATAL: r3/a4:  0x200006d8 r12/ip:  0x20000000 r14/lr:  0x00001477
FATAL:  xpsr:  0x0100000f
FATAL: Faulting instruction address (r15/pc): 0x00002f30
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 0
Wrong crash type got 0 expected 2

[ioannisg]

I don't have the board to test this. Does not seem to fail on frdm_k64f, @galak

[galak]

I don't have the board to test this. Does not seem to fail on frdm_k64f, @galak

Agreed, this failure seemed unique to the FRDM-KW41Z. Which is a Cortex-M0+ so not sure if maybe a core or memory size issue.

[andrewboie]

test stack sentinel overflow - timer irq
posting 1024 bytes of junk to stack...
FATAL: ***** HARD FAULT *****
FATAL: r0/a1:  0x00000002  r1/a2:  0xbbbbbbbb  r2/a3:  0xf0f0f0f0
FATAL: r3/a4:  0x200006d8 r12/ip:  0x20000000 r14/lr:  0x00001477
FATAL:  xpsr:  0x0100000f
FATAL: Faulting instruction address (r15/pc): 0x00002f30
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 0
Wrong crash type got 0 expected 2

Cortex M0 fatal error handling code is incorrectly reporting this as a CPU exception instead of a stack overflow

[ioannisg]

I'll try with another Cortex M0+ I have available, and report back

[ioannisg]

Test passes on nrf51_pca10028 (Cortex-M0) but fails, similarly, on atsamr21_xpro (Cortex-M0+)

[ioannisg]

Looks like the root cause of this is that an SVC is triggered inside an interrupt, and the interrupt has equal priority. @andrewboie @galak why do we not reserve an IRQ level for SVC in Cortex-m0?

[ioannisg]

I know that without the BASEPRI, then, irq_lock() will disable SVC interrupts, as well; that might be the reason for not reserving the highest priority for SVC. But then, @andrewboie there is a bug in Z_ARCH_EXCEPT For ARM Cortex-M Baseline, cause svc's may not be blocked due to insufficient priority.

[galak]

Verified on FRDM-KW41Z that it fixes the issue.