6.2.3. Usage models

This section describes some ways to handle errors in a system. Exactly how you program the Cortex-R7 MPCore processor to handle errors depends on the configuration of your processor and system, and what you are trying to achieve.

If an abort exception is taken, the abort handler reads the information in the link register, SPSR, and fault status registers to determine the type of abort. Some types of abort are fatal to the system, and others can be fixed, and program execution resumed. For example, an MPU background fault might indicate a stack overflow, and be rectified by allocating more stack and reprogramming the MPU to reflect this. Alternatively, an asynchronous external abort might indicate that a software error meant that a store instruction occurred to an unmapped memory address. This type of abort is fatal to the system or process because no information is recorded about the address the error occurred on, or the instruction that caused the error.

Table 6.1 shows which types of abort are typically fatal because either the location of the error is not recorded or the error is unrecoverable. Some aborts that are marked as not fatal might be fatal in some systems when the cause of the error is determined. For example, an MPU background fault might indicate something that can be rectified, for example a stack overflow. It might also indicate something that is fatal, for example that because of a bug, the software has accessed a nonexistent memory location. These cases can be distinguished by determining the location where the error occurred. If an error is unrecoverable, it is normally fatal regardless of whether or not the location of the error is recorded.

Table 6.1. Types of aborts

TypeConditionsSourceSynchronousFatal
MPU faultAccess not permitted by MPU[a]MPUYesNo
Asynchronous externalAny external accessAXI3NoYes

[a] See MPU faults for more information about the types of MPU fault.


Correctable errors

You can configure the processor to respond to and automatically correct ECC errors. Connect the event output or outputs that indicate a correctable error to an interrupt controller. When such an event occurs, the interrupt input to the processor is set, and the processor takes an interrupt exception. When your interrupt handler has identified the source of the interrupt as a correctable error, it can read the ECC Error Registers to determine where the ECC error occurred. You can examine this information to identify trends in such errors. By masking the interrupt when necessary, your software can ensure that when critical code is executing, the processor corrects the errors automatically, but delays examining information about the error until after the critical code has completed.

When the processor is in debug state, any correctable error is corrected. However, in case of load instruction, the memory access replay to read the corrected data is not done, and therefore the instruction generating the error does not complete successfully. Instead, the sticky synchronous abort flag in the DBGDSCR is set.

Debugging cache and TCM access

See Cache and TCM Debug Operation Register.

Copyright © 2012, 2014 ARM. All rights reserved.ARM DDI 0458C
Non-ConfidentialID112814