3.8.4. Aborts

When the processor memory system cannot complete a memory access successfully, an abort is generated. Aborts can occur for a number of reasons, for example:

An error occurring on an instruction fetch generates a prefetch abort. Errors occurring on data accesses generate data aborts. Aborts are also categorized as being either synchronous, previously known as precise, or asynchronous, previously known as imprecise.

When a prefetch or data abort occurs, the processor takes the appropriate type of exception. See Exception entry and exit summary for more information. Additional information about the type of abort is stored in registers, and signaled as events. See Fault handling for more information about the types of fault that can cause an abort and the information that the processor provides about these faults.

Prefetch aborts

When a Prefetch Abort (PABT) occurs, the processor marks the prefetched instruction as invalid, but does not take the exception until the instruction is to be executed. If the instruction is not executed, for example because a branch occurs while it is in the pipeline, the abort does not take place.

All prefetch aborts are synchronous.

Data aborts

An error occurring on a data memory access can generate a data abort. If the instruction generating the memory access is not executed, for example, because it fails its condition codes, or is interrupted, the data abort does not take place.

A Data Abort (DABT) can be either synchronous or asynchronous, depending on the type of fault that caused it.

The Cortex-R5 processor implements the base restored Data Abort model, as opposed to a base updated Data Abort model.

With the base restored Data Abort model, when a Data Abort exception occurs during the execution of a memory access instruction, the processor hardware always restores the base register to the value it contained before the instruction was executed. For more information, see the ARM Architecture Reference Manual.

Synchronous aborts

A synchronous abort, also known as a precise abort, is one for which 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 asynchronous abort, also known as an imprecise abort, is one for which the exception is taken on a later instruction than 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.

Asynchronous aborts can be generated by store instructions to Normal-type or Device-type memory. 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 to indicate that an asynchronous abort cannot be accepted, the A-bit. 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 actually 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.

Only one pending asynchronous abort of each asynchronous abort type is supported. The processor supports the following pending asynchronous aborts:

  • AXI-master port external error.

    If a subsequent external error is signaled while another one is pending, the later one is ignored and only one abort is taken.

  • One TCM write external error for each TCM port.

  • Cache write parity or ECC error.

    If a subsequent cache parity or ECC error is signaled while another one is pending, the later one is normally ignored and only one abort is taken. However, if the pending error was correctable, and the later one is not correctable, the pending error is ignored, and one abort is taken for the error that cannot be corrected.

  • AXI peripheral port external error from either main or virtual interface access.

    If a subsequent AXI peripheral port error is signalled while another one is pending, the later one is ignored and only one abort is taken.

  • AHB peripheral port external error.

Memory barriers

When a store instruction, or series of instructions has been executed to normal-type or device-type memory, 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. Abort exceptions are only taken because of these errors if they are not masked, that is, the CPSR A-bit is clear. If the A-bit is set, the aborts are held pending.

Aborts in Strongly Ordered and Device memory

When a memory access generates an abort, the instruction generating that access is abandoned, even if it has not completed all its memory accesses, and the abort exception is taken. The abort handler can then do one of the following:

  • fix the error and return to the instruction that was abandoned, to re-execute it

  • perform the appropriate data transfers on behalf of the aborted instruction and return to the instruction after the abandoned instruction

  • treat the error as fatal and terminate the process.

If the abort handler returns to the abandoned instruction, some of the memory accesses generated are repeated. The effect is that multiword load/store instructions can access the same memory location twice. The first access occurs before the abort is detected, and the second when the instruction is restarted.

In Strongly Ordered or Device type memory, repeating memory accesses might have unacceptable side-effects. Therefore, if the abort handler can fix the error and re-execute the aborted instruction, you must ensure that for all memory errors on multiword load/store instructions, either:

  • all side effects of repeating accesses are inconsequential

  • the error must either occur on the first word accessed or not at all.

The instructions that this rule applies to are:

  • All forms of ARM instructions LDM, and LDRD, all forms of STM, STRD including VFP variants, and unaligned LDR, STR, LDRH, and STRH

  • Thumb instructions LDMIA, LDRD, SDRD, PUSH, POP, and STMIA including VFP variants, and unaligned LDR, STR, LDRH, and STRH.

Abort handler

If you configure the processor with parity or ECC on the caches or the TCMs, and the abort handler is in one of these memories, then it is possible for a parity or ECC error to occur in the abort handler. If the error is not recoverable, then a synchronous abort occurs and the processor loops until the next interrupt. The LR and SPSR values for the original abort are also lost. Therefore, you must construct software that ensures that no synchronous aborts occur when in the abort handler. This means the abort handler must be in external memory and not cached.

Copyright © 2010-2011 ARM. All rights reserved.ARM DDI 0460C
Non-ConfidentialID021511