63
32000D–04/2011
AVR32
8.
Event Processing
Due to various reasons, the CPU may be required to abort normal program execution in order to
handle special, high-priority events. When handling of these events is complete, normal program
execution can be resumed. Traditionally, events that are generated internally in the CPU are
called exceptions, while events generated by sources external to the CPU are called interrupts.
The AVR32 has a powerful event handling scheme. The different event sources, like Illegal
Opcode and external interrupt requests, have different priority levels, ensuring a well-defined
behaviour when multiple events are received simultaneously. Additionally, pending events of a
higher priority class may preempt handling of ongoing events of a lower priority class.
When an event occurs, the execution of the instruction stream is halted, and execution control is
dlers are placed sequentially in the code space starting at the address specified by EVBA, with
four bytes between each handler. This gives ample space for a jump instruction to be placed
there, jumping to the event routine itself. A few critical handlers have larger spacing between
them, allowing the entire event routine to be placed directly at the address specified by the
EVBA-relative offset generated by hardware. All external interrupt sources have autovectored
interrupt service routine (ISR) addresses. This allows the interrupt controller to directly specify
the ISR address as an address relative to EVBA. The address range reachable by this autovec-
tor offset is IMPLEMENTATION DEFINED. Implementations may require EVBA to be aligned in
an IMPLEMENTATION DEFINED way in order to support autovectoring.
The same mechanisms are used to service all different types of events, including external inter-
rupt requests, yielding a uniform event handling scheme.
If the application is executing in the secure state, the event handling is modified as explained in
the event system.
8.1
Event handling in AVR32A
8.1.1
Exceptions and interrupt requests
When an event other than scall or debug request is received by the core, the following actions
are performed atomically:
1.
The pending event will not be accepted if it is masked. The I3M, I2M, I1M, I0M, EM and
GM bits in the Status Register are used to mask different events. Not all events can be
masked. A few critical events (NMI, Unrecoverable Exception, TLB Multiple Hit and Bus
Error) can not be masked. When an event is accepted, hardware automatically sets the
mask bits corresponding to all sources with equal or lower priority. This inhibits accep-
tance of other events of the same or lower priority, except for the critical events listed
above. Software may choose to clear some or all of these bits after saving the neces-
sary state if other priority schemes are desired. It is the event source’s responsability to
ensure that their events are left pending until accepted by the CPU.
2.
When a request is accepted, the Status Register and Program Counter of the current
context is stored to the system stack. If the event is an INT0, INT1, INT2 or INT3, regis-
ters R8 to R12 and LR are also automatically stored to stack. Storing the Status
Register ensures that the core is returned to the previous execution mode when the
current event handling is completed. When exceptions occur, both the EM and GM bits
are set, and the application may manually enable nested exceptions if desired by clear-