arch: arm: cortex_m: fix stack overflow error detection

In rare cases when a thread may overflow its stack, the
core will not report a Stacking Error. This is the case
when a large stack array is created, making the PSP cross
beyond the stack guard; in this case a MemManage fault
won't cause a stacking error (but only a Data Access
Violation error). We fix the fault handling logic so
such errors are reported as stack overflows and not as
generic CPU exceptions.

Signed-off-by: Ioannis Glaropoulos <[email protected]>

Author: ioannisg

arch/arm/core/aarch32/cortex_m/fault.c

@@ -256,8 +256,16 @@ static uint32_t mem_manage_fault(z_arch_esf_t *esf, int from_hard_fault,
 	 *
 	 * By design, being a Stacking MemManage fault is a necessary
 	 * and sufficient condition for a thread stack corruption.
+	 * [Cortex-M process stack pointer is always descending and
+	 * is never modified by code (except for the context-switch
+	 * routine), therefore, a stacking error implies the PSP has
+	 * crossed into an area beyond the thread stack.]
+	 *
+	 * Data Access Violation errors may or may not be caused by
+	 * thread stack overflows.
 	 */
-	if (SCB->CFSR & SCB_CFSR_MSTKERR_Msk) {
+	if ((SCB->CFSR & SCB_CFSR_MSTKERR_Msk) ||
+		(SCB->CFSR & SCB_CFSR_DACCVIOL_Msk)) {
 #if defined(CONFIG_MPU_STACK_GUARD) || defined(CONFIG_USERSPACE)
 		/* MemManage Faults are always banked between security
 		 * states. Therefore, we can safely assume the fault
@@ -310,7 +318,7 @@ static uint32_t mem_manage_fault(z_arch_esf_t *esf, int from_hard_fault,
 
 				reason = K_ERR_STACK_CHK_FAIL;
 			} else {
-				__ASSERT(0,
+				__ASSERT(!(SCB->CFSR & SCB_CFSR_MSTKERR_Msk),
 					"Stacking error not a stack fail\n");
 			}
 		}