|Non-Confidential||PDF version||ARM 100400_0001_03_en|
|Home > Level One Memory System > Fault handling > Usage models|
How you program the Cortex®‑R8 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.
The following table 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 non-existent 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 the location of the error is recorded.
Table 6-1 Types of aborts
|MPU fault||Access not permitted by MPU||MPU||Yes||No|
|Asynchronous external||Any external access||AXI3||No||Yes|
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 the case of a 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.
Refer to the Cache and TCM Debug Operation Register.