Mechanisms that can cause the processor to take an exception because of a memory access are:

Collectively these are called aborts. Accesses that cause aborts are said to be aborted. If the memory request that aborts is an instruction fetch, then a Prefetch Abort exception is raised if and when the processor attempts to execute the instruction corresponding to the aborted access.

If the aborted access is a data access or a cache maintenance operation, a Data Abort exception is raised.

All Data Aborts, and aborts caused by cache maintenance operations, cause the Data Fault Status Register (DFSR) to be updated so that you can determine the cause of the abort.

For all Data Aborts, excluding external aborts, other than on translation, the Fault Address Register (FAR) is updated with the address that caused the abort. External Data Aborts, other than on translation, can all be imprecise and therefore the FAR does not contain the address of the abort. See Imprecise Data Abort mask in the CPSR/SPSR for more details on imprecise Data Aborts.

For all prefetch aborts the processor updates the Instruction Fault Address Register (IFAR) with the address of the instruction that causes the abort.

When the EA bit is set, see c1, Secure Configuration Register, all external aborts are trapped to the Secure Monitor mode, and only the Secure versions of the FSR and FAR registers are updated. In all other cases, the FAR or FSR registers are updated in the world corresponding to the state of the core that caused the aborted access. For example if the core is in Secure state, the Secure version of the FAR and FSR are updated, even in the case when the aborted access has been performed with NS rights because of the NS Attribute being Non-secure in the MMU.