Issue Summary :

The customer is observing a peculiar issue with the FreeRTOS vPortEnterCritical() and vPortExitCritical() functions on Cortex-A53.

When they added frequently-called code inside a critical section (causing thousands of calls to vPortEnterCritical()/vPortExitCritical() per second), they started seeing non-deterministic synchronous aborts.
• Most aborts were instruction aborts, with the faulting address pointing to uxIdleTaskStack or TaskP_Object.
• Occasionally, PC alignment faults were also observed.

When the customer replaced vPortEnterCritical()/vPortExitCritical() with HwiP_disable()/HwiP_restore() for the critical sections, the mysterious aborts stopped occurring.

Debug & Analysis :
• I tried to reproduce the issue internally but could not trigger the aborts on our setup.
• On reviewing the A53 FreeRTOS port code, we found that the critical section implementation on A53 does not include synchronization barriers (DSB/ISB), unlike the R5 implementation.
• On ARMv8-A cores, the CPU and memory system may reorder or speculate instructions/memory accesses around interrupt mask operations.
• Without explicit barriers, memory updates inside or before the critical section may not be fully visible, or speculative execution may occur across interrupt enable/disable instructions.
• This can corrupt sensitive data structures (e.g., task stack, TaskP_Object), which matches the abort addresses the customer observed.

Root Cause (Suspected ) :

The A53 critical section implementation is missing synchronization barriers (DSB and ISB instructions) around the interrupt mask/unmask operations.
This omission can cause memory ordering and instruction synchronization issues under heavy usage, leading to stack corruption and instruction aborts.