35
32117DS–AVR-01/12
AT32UC3C
relative to EVBA. The autovector offset has 14 address bits, giving an offset of maximum 16384
bytes. The target address of the event handler is calculated as (EVBA | event_handler_offset),
not (EVBA + event_handler_offset), so EVBA and exception code segments must be set up
appropriately. The same mechanisms are used to service all different types of events, including
interrupt requests, yielding a uniform event ha ndling scheme.
An interrupt cont roller does t he priority ha ndling of the int errupts and p rovides the autovect or off-
set to the CPU.
4.5.1 System Stack Issues
Event handling in AVR32UC uses the system stack pointed to by the system stack pointer,
SP_SYS, for pushing and popping R8-R12, LR, status register, and return address. Since event
code may be timing-critical, SP_SYS should po int to memory addresses in the IRAM section,
since the timing of accesses to this memory section is both fast and deterministic.
The user must also make sure that the system stack is large enough so that any event is able to
push the required registers to stack. If the system stack is full, and an event occurs, the system
will enter an UNDEFINED state.
4.5.2 Exceptions and Inter r upt Requests
When an event other than scall or deb ug request is received by the core, the following act ions
are performed atomically:
1. The pending e vent will not be accepted if it is masked. The I3M, I2M, I1M, I0M, EM, and
GM bits in the Status Re gister are used to mask different events. Not all events can be
masked. A few critical ev ents (NMI, Unrecoverable Exception, TLB Multiple Hit, and
Bus Error) can not be masked. When an event is accepted, hardware automa tically
sets the mask bits co rresponding t o all sour ces with eq ual or lo w er priority. This inhibits
acceptance 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
necessary state if other priority schemes are desired. It is the event source’s respons-
ability 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, reg-
isters R8-R12 and LR are a lso automatically stored to stack. Storing the Status
Register ensur es that the core is retu rned to the previous execution mode when the
current event handling is comple ted. When exceptions o ccur, both the EM and GM bit s
are set, a nd the application may manually enable nested exceptions if desired by clear-
ing the appropriate bit. Each exception handler has a dedicated handler address, and
this address un iqu ely iden tifie s th e exception source.
3. The Mode bits are set to reflect the priority of the accepted event, and the corr ect regi s-
ter file bank is selected. The address of the event handler, as shown in Table 4-4 on
page 38, is loaded into the Program Counter.
The execution of the event handler routin e then continues from the effective address calculated.
The rete instruction signals the end of the event. When encountered, the Return Status Regist er
and Return Addr ess Register ar e popped f rom t he system st ack and r est ored to t he Statu s Re g-
ister and Program Counter. If the rete instruction returns from INT0, INT1, INT2, or INT3,
registers R8-R12 and LR are also popped from the system stack. The restored Status Register
contains informa tion allowin g th e core t o resum e ope ra tion in t he p re vious e xecut ion mode. T his
concludes the event handling.