Module 5 – 23ECE144

Exceptions in Cortex M3
 Module 5- Content
• Exception Types
• Definitions of Priority
• Vector Tables
• Interrupt Inputs and Pending Behaviour
• Fault Exceptions, Bus Faults, Memory Management Faults, Usage
Faults, Hard Faults, Dealing with Faults
• Supervisor Call and Pendable Service Call
Exception
Types
Definitions of Priority

• 3 fixed priority, 256 levels of programmable priority

• Priority levels could be 8, 16, 32. This reduction of levels is implemented by cutting out the Least Significant
Bit (LSB) part of the priority configuration registers.
• possible priority levels of 0x00 (high priority), 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, and 0xE0 (the lowest)

• If more bits more priority levels, but increases gate count and power consumption.
• The reason for removing the LSB of the register instead of the Most Significant Bit (MSB) is to make it easier
to port software from one Cortex-M3 device to another.
• preempt priority level: whether an interrupt can take place when the
processor is already running another interrupt handler.

• subpriority level value is used only when two exceptions with the
same preempt priority level occurred at the same time. In this case,
the exception with higher subpriority (lower value) will be handled
first.
• width of the configuration registers is 3 (bit 7 to bit 5 are available)
• priority group is set to 5, you can have four levels of preempt priority levels (bit 7
to bit 6),
• inside each preempt level there are two levels of subpriority (bit 5).
 Vector Table
• When an exception takes place, the processor needs starting address of
the exception handler which is stored in the vector table of the
memory.

• By default, the vector table starts at memory address 0, and the vector
address is arranged according to the exception number times four.

• address 0x0 should be boot code, usually it will be either Flash

memory or ROM devices, and the value cannot be changed at run time

• the vector table can be relocated to other memory locations in the code
or Random Access Memory (RAM) region by setting a register in the
NVIC called the vector table offset register (address 0xE000ED08).
 Interrupt Inputs and Pending Behavior
• When an interrupt input is asserted, it will be pended, which means it is put into a
state of waiting for the processor to process the request

• if the pending status is cleared before the processor starts responding to the
pended interrupt, the interrupt can be cancelled

• The pending status of the interrupt can be accessed in the NVIC and is writable,
can clear a pending interrupt or use software to pend a new interrupt by setting the
pending register.
• When the processor starts to execute an interrupt, the interrupt becomes active and the
pending bit will be cleared automatically

• When an interrupt is active, cannot start processing the same interrupt again, until the
interrupt service routine is terminated with an interrupt return

• Then the active status is cleared, and the interrupt can be processed again if the pending
status is 1. It is possible to repend an interrupt before the end of the interrupt service
routine.
• If an interrupt source continues to hold the interrupt request signal active, the
interrupt will be pended again at the end of the interrupt service routine
• If an interrupt is pulsed several times before the processor starts processing it, it will be
treated as one single interrupt request
• If an interrupt is deasserted and then pulsed again during the interrupt service
routine, it will be pended again
 Fault Exceptions
• Bus faults
• Memory management faults
• Usage faults
• Hard faults
 Bus Faults
• Bus faults are produced when an error response is received during a transfer on the AHB
interfaces.

• It can happen at these stages:

• Instruction fetch, commonly called prefetch abort

• Data read/write, commonly called data abort

• Bus faults can also occur during the following:

• Stack PUSH in the beginning of interrupt processing, called a stacking error

• Stack POP at the end of interrupt processing, called an unstacking error

• Reading of an interrupt vector address (vector fetch) when the processor starts the interrupt
handling sequence
1. When these types of bus faults (except vector fetches) take place and if the bus fault handler is
enabled and no other exceptions with the same or higher priority are running, the bus fault handler
will be executed.

2. If the bus fault handler is enabled but at the same time the core receives another exception handler
with higher priority, the bus fault exception will be pending.

3. Finally, if the bus fault handler is not enabled or when the bus fault happens in an exception handler
that has the same or higher priority than the bus fault handler, the hard fault handler will be
executed instead.

4. If another bus fault takes place when running the hard fault handler, the core will enter a lockup
state.
 What Can Cause AHB Error Responses?

Attempts to access an invalid memory region

• The device is not ready to accept a transfer

• Attempts to carry out a transfer with a transfer size not supported by the target
device

• The device does not accept the transfer for various reasons
 Memory Management Faults
• Memory management faults can be caused by memory accesses that violate the
setup in the MPU or by certain illegal accesses

• Some of the common MPU faults include the following:

• Access to memory regions not defined in MPU setup

• Writing to read-only regions

• An access in the user state to a region defined as privileged access only

• When a memory management fault occurs and if the memory management handler is
enabled, the memory management fault handler will be executed.

• If the fault occurs at the same time a higher-priority exception takes place, the other
exceptions will be handled first and the memory management fault will be pended.

• If the processor is already running an exception handler with the same or higher
priority or if the memory management fault handler is not enabled, the hard fault
handler will be executed instead.

• If a memory management fault takes place inside the hard fault handler or the NMI
handler, the processor will enter the lockup state
• The memory management fault handler needs to be enabled. This is done by the
MEMFAULTENA bit in the System Handler Control and State register in the NVIC.

• If the vector table has been relocated to RAM, the memory management fault handler starting
address should be set up in the vector table first.

• Memory Management Fault Status register (MFSR) to indicate the cause of the memory
management fault.

• If the status register indicates that the fault is a data access violation (DACCVIOL bit) or an
instruction access violation (IACCVIOL bit), the offending code can be located by the stacked
program counter.

• If the MMARVALID bit in the MFSR is set, it is also possible to determine the memory
address location that caused the fault from the Memory Management Address register (MMAR)
in the NVIC.
 Usage faults
• Usage faults can be caused by a number of things:

• Undefined instructions

• Coprocessor instructions

• Trying to switch to the ARM state

• Invalid interrupt return (link register contains invalid/incorrect values)

• Unaligned memory accesses using multiple load or store instructions

• When a usage fault occurs and if the usage fault handler is enabled, normally the usage
fault handler will be executed.

• However, if at the same time a higher-priority exception takes place, the usage fault will
be pended.

• If the processor is already running an exception handler with the same or higher priority
or if the usage fault handler is not enabled, the hard fault handler will be executed instead.

• If a usage fault takes place inside the hard fault handler or the NMI handler, the processor
will enter the lockup state.
• The usage fault handler is enabled by setting the USGFAULTENA bit
in the System Handler Control and State register in the NVIC.
• If the vector table has been relocated to RAM, the usage fault handler
starting address should be set up in the vector table first.
• The NVIC provides a Usage Fault Status register (UFSR) for the
usage fault handler to determine the cause of the fault.
• Inside the handler, the program code that causes the error can also be
located using the stacked program counter value.
 Hard faults
• The hard fault handler can be caused by usage faults, bus faults, and memory management faults if their
• handler cannot be executed. In addition, it can also be caused by a bus fault during vector fetch (reading
• of a vector table during exception handling). In the NVIC, there is a hard fault status register that can
• be used to determine whether the fault was caused by a vector fetch. If not, the hard fault handler will
• need to check the other FSRs to determine the cause of the hard fault.
 Dealing with Faults
Fault-handling Methods:

• Reset: This can be carried out using the SYSRESETREQ control bit in the Application Interrupt and
Reset Control register in the NVIC. This will reset most parts of the system apart from the

• Debug Logic. Depending on the application, if you do not want to reset the whole system, you could reset
just the processor using the VECTRESET bit.

• Recovery: In some cases, it might be possible to resolve the problem that caused the fault exception. For
example, in the case of coprocessor instructions, the problem can be resolved using coprocessor
emulation software.

• Task Termination: For systems running an OS, it is likely that the task that caused the fault will be
terminated and restarted if needed.
 Supervisor Call and Pendable Service Call
• Supervisor Call (SVC) and Pendable Service Call (PendSV) are two exceptions targeted at
software and operating systems. SVC is for generating system function calls.

• For example, instead of allowing user programs to directly access hardware, an operating system
may provide access to hardware through an SVC.

• So, when a user program wants to use certain hardware, it generates the SVC exception using
SVC instructions, and then the software exception handler in the operating system is executed
and provides the service the user application requested.

• In this way, access to hardware is under the control of the OS, which can provide a more robust
system by preventing the user applications from directly accessing the hardware.
• SVC can also make software more portable because the user application does not
need to know the programming details of the hardware.

• The user program will only need to know the application programming interface
(API) function ID and parameters; the actual hardware-level programming is
handled by device drivers
System Handler Control and State register
• To enable the bus fault handler, you need to set the BUSFAULTENA bit in the
System Handler Control and State register in the NVIC. Before doing that, make
sure that the bus fault handler starting address is set up in the vector table if the
vector table has been relocated to RAM.