6.2.1 Fault classes

The classes of fault that can occur are MPU faults, external faults, debug events, synchronous aborts, and asynchronous aborts.

MPU faults

The MPU can generate an abort for various reasons. MPU faults are always synchronous, and take priority over other types of abort. If an MPU fault occurs on an access that is not in the TCM, and is Non-Cacheable, or has generated a cache-miss, the AXI3 transactions for that access are not performed.

Related concepts

External faults

A memory access performed through the AXI3 master interface can generate two different types of error response, a slave error (SLVERR) or decode error (DECERR). These are known as external errors, because they are generated by the AXI3 system outside the processor. Synchronous aborts are generated for instruction fetches. All loads and stores generate asynchronous aborts.

Debug events

The debug logic in the processor can be configured to generate breakpoints or vector capture events on instruction fetches, and watchpoints on data accesses. If the processor is software-configured for monitor-mode debugging, an abort is taken when one of these events occurs, or when a BKPT instruction is executed.

Related reference

Synchronous
aborts

An abort is synchronous when the exception is guaranteed to be taken on the instruction that generated the aborting memory access. The abort handler can use the value in the Link Register (r14_abt) to determine which instruction generated the abort, and the value in the Saved Program Status Register (SPSR_abt) to determine the state of the processor when the abort occurred.

Asynchronous
aborts

An abort is asynchronous when the exception is taken on an instruction after the instruction that generated the aborting memory access. The abort handler cannot determine which instruction generated the abort or the state of the processor when the abort occurred. Therefore, asynchronous aborts are normally fatal.

All external aborts on both loads and stores to any memory
type, that is, Normal, Device, or Strongly-Ordered, generate asynchronous
aborts on the Cortex®‑R8 processor. When the store instruction is
committed, the data is normally written into a buffer that holds
the data until the memory system has sufficient bandwidth to perform
the write access. This gives read accesses higher priority. The
write data can be held in the buffer for a long period, during which
many other instructions can complete. If an error occurs when the
write is finally performed, this generates an asynchronous abort.

Asynchronous abort masking

The nature of asynchronous aborts means that they can occur while the processor is handling a different abort. If an asynchronous abort generates a new exception in such a situation, the r14_abt and SPSR_abt values are overwritten. If this occurs before the data is pushed to the stack in memory, the state information about the first abort is lost. To prevent this from happening, the CPSR contains a mask bit, the A-bit, to indicate that an asynchronous abort cannot be accepted. When the A-bit is set, any asynchronous abort that occurs is held pending by the processor until the A-bit is cleared, when the exception is taken. The A-bit is automatically set when abort, IRQ, or FIQ exceptions are taken, and on reset. You must only clear the A-bit in an abort handler after the state information has either been stacked to memory, or is no longer required.

The processor supports only one pending asynchronous external
abort. If a subsequent asynchronous external abort is signaled while
another one is pending, the later one is ignored and only one abort
is taken.

Memory barriers

When a store instruction, or series of instructions has been executed, it is sometimes necessary to determine whether any errors occurred because of these instructions. Because most of these errors are reported asynchronously, they might not generate an abort exception until some time after the instructions are executed.

To ensure that all possible errors have been reported, you
must execute a DSB instruction. If the CSPR A-bit
is clear, these errors are not masked and the abort exceptions are
taken. If the A-bit is set, the aborts are held pending.