CI:frdm_k64f: kernel.common.stack_protection test failure

[hakehuang]

Describe the bug
kernel common stack protection test failure on frdm_k64f
initial found in v3.2.0-3560-g80f87b9480 and still exist in zephyr-v3.2.0-3758-g61f89b7b18a1

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=frdm_k64f
3. make
4. See error

Expected behavior
Test PASS

Impact
kernel stack protection

Logs and console output

*** Booting Zephyr OS build zephyr-v3.2.0-3758-g61f89b7b18a1 ***
Running TESTSUITE fatal_exception
===================================================================
START - test_fatal
test alt thread 1: generic CPU exception
E: ***** BUS FAULT *****
E:   Instruction bus error
E:   NXP MPU error, port 3
E:     Mode: Supervisor, Instruction Address: 0x20001aa4
E:     Type: Read, Master: 0, Regions: 0x8200
E: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000014
E: r3/a4:  0x20001aa4 r12/ip:  0x00000000 r14/lr:  0x000007fb
E:  xpsr:  0x40000000
E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
E: fpscr:  0x20000388
E: Faulting instruction address (r15/pc): 0x20001aa4
E: >>> ZEPHYR FATAL ERROR 27: Unknown error on CPU 0
E: Current thread: 0x20000020 (unknown)
Caught system error -- reason 27
Wrong crash type got 27 expected 35 or 20

Environment (please complete the following information):

• OS: (e.g. Linux)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used: v3.2.0-3560-g80f87b9480

[hakehuang]

@dleach02 , @mmahadevan108

[hakehuang]

all kinetis and rt10xx series has the same problem

[microbuilder]

@JordanYates Verified on FRDMK64F that this returns K_ERR_ARM_BUS_INSTRUCTION_BUS, though @hakehuang indicated this affects other NXP devices, so wondering what the best #ifdef flag is here to set the correct alternate reason, and if any other alternatives come up on other NXP chips, not having the entire catalog on my desk obviously. ;P

[microbuilder]

This catches the frdm_k64f reason code, but what other edge cases need to be handled in entry_cpu_exception, and this might become rather ungainly quickly:

#if defined(CONFIG_CPU_AARCH32_CORTEX_R) || defined(CONFIG_CPU_AARCH32_CORTEX_A)
	expected_reason = K_ERR_ARM_UNDEFINED_INSTRUCTION;
#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE)
	/* The generated exception depends on whether address 0 is valid and it is executed.
	 * It is not feasible to generically check that here, so accept either faulting reason.
	 */
	expected_reason = K_ERR_ARM_USAGE_ILLEGAL_EPSR;
#if defined(CONFIG_SOC_SERIES_KINETIS_K6X)
	/* NXP Kinetis K6x returns K_ERR_ARM_BUS_INSTRUCTION_BUS error. */
	alternate_reason = K_ERR_ARM_BUS_INSTRUCTION_BUS;
#else
	alternate_reason = K_ERR_ARM_MEM_INSTRUCTION_ACCESS;
#endif

#else
	expected_reason = K_ERR_CPU_EXCEPTION;
#endif

[JordanYates]

I agree that code isn't great. The three options I can see are:

1. Accept any code in the range K_ERR_ARM_MEM_GENERIC-K_ERR_ARM_SECURE_GENERIC
2. Add alternate_reason_2 and associated logic.
3. Turn the expected reasons into an array

[microbuilder]

3. Turn the expected reasons into an array

Makes the most sense to me to avoid alternate_reason_4 down the road.

Have time to make a PR quickly? I'll try to find some other NXP boards here to test with. I think I have an RT10x here somewhere as well.

Edit: Hopefully adding K_ERR_ARM_BUS_INSTRUCTION_BUS as a generic second alternate reason should cover all the NXP platforms, and we can drop the NXP check if we have an array of alt reasons.

[JordanYates]

Yea I'm writing something now

[dleach02]

question, what introduced this bug/problem? We didn't have this before?

[microbuilder]

question, what introduced this bug/problem? We didn't have this before?

There was a recent PR to return specific reason codes in Arm for exceptions. Until that PR, every exception generated basically the same reason code, which leads to a suboptimal debugging process when you hit a fault handler in your app.

This reason code now gives you specific details on what went wrong.