Atmel AVR32 user guide: 7. Performance counters

AVR32

6. Memory Protection Unit

The AVR32 architecture defines an optional Memory Protection Unit (MPU). This is a simpler alternative to a full MMU, while at the same time allowing memory protection. The MPU allows the user to divide the memory space into different protection regions. These protection regions have a user-defined size, and starts at a user-defined address. The different regions can have different cacheability attributes and bufferability attributes. Each region is divided into 16 subregions, each of these subregions can have one of two possible sets of access permissions.

The MPU does not perform any address translation.

6.1 Memory map in systems with MPU

An AVR32 implemetation with a MPU has a flat, unsegmented memory space. Access permissions are given only by the different protection regions.

6.2 Understanding the MPU

The AVR32 Memory Protection Unit (MPU) is responsible for checking that memory transfers have the correct permissions to complete. If a memory access with unsatisfactory privileges is attempted, an exception is generated and the access is aborted. If an access to a memory address that does not reside in any protection region is attempted, an exception is generated and the access is aborted.

The user is able to allow different privilege levels to different blocks of memory by configuring a set of registers. Each such block is called a protection region. Each region has a user-programmable start address and size. The MPU allows the user to program 8 different protection regions. Each of these regions have 16 sub-regions, which can have different access permissions, cacheability and bufferability.

The "DMMU SZ" fields in the CONFIG1 system register identifies the number of implemented protection regions, and therefore also the number of MPU registers. A system with caches also have MPU cacheability and bufferability registers.

A protection region can be from 4 KB to 4 GB in size, and the size must be a power of two. All regions must have a start address that is aligned to an address corresponding to the size of the region. If the region has a size of 8 KB, the 13 lowest bits in the start address must be 0. Failing to do so will result in UNDEFINED behaviour. Since each region is divided into 16 sub-regions, each sub-region is 256 B to 256 MB in size.

When an access hits into a memory region set up by the MPU, hardware proceeds to determine which subregion the access hits into. This information is used to determine whether the access permissions for the subregion are given in MPUAPRA/MPUBRA/MPUCRA or in MPUAPRB/MPUBRB/MPUCRB.

If an access does not hit in any region, the transfer is aborted and an exception is generated.

The MPU is enabled by writing setting the E bit in the MPUCR register. The E bit is cleared after reset. If the MPU is disabled, all accesses are treated as uncacheable, unbufferable and will not generate any access violations. Before setting the E bit, at least one valid protection region must be defined.

6.2.1 MPU interface registers

The following registers are used to control the MPU, and provide the interface between the MPU and the operating system, see Figure 6-1 on page 52. All the registers are mapped into the Sys-

32000D–04/2011 ATMEL 51

tem Register space, their addresses are presented in “System registers” on page 14. They are accessed with the mtsr and mfsr instructions.

The MPU interface registers are shown below. The suffix n can have the range 0-7, indicating which region the register is associated with.

Figure 6-1. The MPU interface registers MPUARn

MPUPSRn

MPUCRA / MPUCRB

MPUBRA / MPUBRB

MPUAPRA / MPUAPRB

MPUCR

6.2.1.1 MPU Address Register - MPUARn A MPU Address register is implemented for each of the 8 protection regions. The MPUAR registers specify the start address and size of the regions. The start address must be aligned so that its alignment corresponds to the size of the region. The minimum allowable size of a region is 4 KB, so only bits 31:12 in the base address needs to be specified. The other bits are always 0. Each MPUAR also has a valid bit that specifies if the protection region is valid. Only valid regions are considered in the protection testing.

The MPUAR register consists of the following fields:

• Base address - The start address of the region. The minimum size of a region is 4KB, so only the 20 most significant bits in the base address needs to be specified. The 12 lowermost base address bits are implicitly set to 0. If protection regions larger than 4 KB is used, the user must write the appropriate bits in Base address to 0, so that the base address is aligned to the size of the region. Otherwise, the result is UNDEFINED.

52 AVR32 32000D-04/2011

• Size - Size of the protection region. The possible sizes are shown in Table 6-1 on page 53.

Table 6-1. Protection region sizes implied by the Size field

• V - Valid. Set if the protection region is valid, cleared otherwise. This bit is written to 0 by a reset. The region is not considered in the protection testing if the V bit is cleared.

6.2.1.2 MPU Permission Select Register - MPUPSRn

A MPU Permission Select register is implemented for each of the 8 protection regions. Each MPUPSR register divides the protection region into 16 subregions. The bitfields in MPUPSR specifies whether each subregion has access permissions as specified by the region entry in either MPUAPRA or MPUAPRB.

Table 6-2. Subregion access permission implied by MPUPSR bitfields

6.2.1.3 MPU Cacheable Register A / B- MPUCRA / MPUCRB

The MPUCR registers have one bit per region, indicating if the region is cacheable. If the corresponding bit is set, the region is cacheable. The register is written to 0 upon reset.

AVR32UC implementations may optionally choose not to implement the MPUCR registers.

6.2.1.4 MPU Bufferable Register A / B- MPUBRA / MPUBRB

The MPUBR registers have one bit per region, indicating if the region is bufferable. If the corresponding bit is set, the region is bufferable. The register is written to 0 upon reset.

AVR32UC implementations may optionally choose not to implement the MPUBR registers.

6.2.1.5 MPU Access Permission Register A / B - MPUAPRA / MPUAPRB

The MPUAPR registers indicate the access permissions for each region. The MPUAPR is written to 0 upon reset. The possible access permissions are shown in Table 6-3 on page 54.

Table 6-3. Access permissions implied by the APn bits

6.2.1.6 MPU Control Register - MPUCR

The MPUCR controls the operation of the MPU. The MPUCR has only one field:

• E - Enable. If set, the MPU address checking is enabled. If cleared, the MPU address checking is disabled and no exceptions will be generated by the MPU.

6.2.2 MPU exception handling

This chapter describes the exceptions that can be signalled by the MPU.

6.2.2.1 ITLB Protection Violation

An ITLB protection violation is issued if an instruction fetch violates access permissions. The violating instruction is not executed. The address of the failing instruction is placed on the system stack.

6.2.2.2 DTLB Protection Violation An DTLB protection violation is issued if a data access violates access permissions. The violating access is not executed. The address of the failing instruction is placed on the system stack.

6.2.2.3 ITLB Miss Violation An ITLB miss violation is issued if an instruction fetch does not hit in any region. The violating instruction is not executed. The address of the failing instruction is placed on the system stack.

6.2.2.4 DTLB Miss Violation An DTLB miss violation is issued if a data access does not hit in any region. The violating access is not executed. The address of the failing instruction is placed on the system stack.

6.2.2.5 TLB Multiple Hit Violation An access hit in multiple protection regions. The address of the failing instruction is placed on the system stack. This is a critical system error that should not occur.

6.3 Example of MPU functionality

As an example, consider region 0. Let region 0 be of size 16 KB, thus each subregion is 1KB. Subregion 0 has offset 0-1KB from the base address, subregion 1 has offset 1KB-2KB and so on.

MPUAPRA and MPUAPRB each has one field per region. Each subregion in region 0 can get its access permissions from either MPUAPRA[AP0] or MPUAPRB[AP0], this is selected by the subregion's bitfield in MPUPSR0.

Let: MPUPSR0 = {0b0000_0000_0000_0000, 0b1010_0000_1111_0101} MPUAPRA = {A, B, C, D, E, F, G, H} MPUAPRB = {a, b, c, d, e, f, g, h}

where {A-H, a-h} have legal values as defined in Table 6-3.

Thus for region 0:

Table 6-4. Example of access rights for subregions

\begin{tabular}{|l|l|l|l|} \hline Subregion & Access permission & Subregion & Access permission \ \hline 0 & h & 8 & H \ \hline 1 & H & 9 & H \ \hline 2 & h & 10 & H \ \hline 3 & H & 11 & H \ \hline 4 & h & 12 & H \ \hline 5 & h & 13 & h \ \hline 6 & h & 14 & H \ \hline 7 & h & 15 & h \ \hline \end{tabular}

32000D–04/2011 ATMEL® 55

ATMEL®

56 AVR32 32000D–04/2011

7. Performance counters

7.1 Overview

A set of performance counters let users evaluate the performance of the system. This is useful when scheduling code and performing optimizations. Two configurable event counters are provided in addition to a clock cycle counter. These three counters can be used to collect information about for example cache miss rates, branch prediction hit rate and data hazard stall cycles.

The three counters are implemented as 32-bit registers accessible through the system register interface. They can be configured to issue an interrupt request in case of overflow, allowing a software overflow counter to be implemented.

A performance counter control register is implemented in addition to the three counter registers. This register controls which events to record in the counter, counter overflow interrupt enable and other configuration data.

7.2 Registers

7.2.1 Performance clock counter - PCCNT

This register counts CPU clock cycles. When it reaches 0xFFFF_FFFF, it rolls over. The overflow flag is set and an exception is generated if configured by PCCR. The register can be reset by writing to the C bit in PCCR. PCCNT can be preset to a value by writing directly to it. PCCNT is written to zero upon reset.

7.2.2 Performance counter 0,1 - PCNT0, PCNT1

These counters monitor events as configured by PCCR. When they reach 0xFFFF_FFFF, they roll over. The overflow flag is set and an exception is generated if configured by PCCR. The registers can be reset by writing the R bit in PCCR. The registers can be preset to a value by writing directly to them. PCNT0 and PCNT1 are written to zero upon reset.

7.2.3 Performance counter control register - PCCR

This register controls the behaviour of the entire performance counter system, see Figure 7-1 on page 57. This register is read and written by the mtsr and mfsr instructions. PCCR is written to zero upon reset.

Figure 7-1. Performance counter control register

32000D-04/2011 ATMEL 57

The following fields exist in PCCR, see Table 7-1 on page 58.

Table 7-1. Performance counter control register

AVR32

7.3 Monitorable events

The following events can be monitored by the performance counters, depending on the setting of CONF0 and CONF1, see Table 7-2 on page 59.

Table 7-2. Monitorable events

7.4 Usage

The performance counters can be used to monitor several different events and perform different measurements. Some of the most useful are explained below.

7.4.1 Cycles per instruction

CONF0: 0x7 (Instruction executed)

CPI = CCNT / PCNT0

Cycles-per-instruction (CPI) measures the average time it took to execute an instruction.

7.4.2 Icache miss rate

CONF0: 0x7 (Instruction executed)

CONF1: 0x0 (Icache miss)

ICMR = PCNT1 / PCNT0

The instruction cache miss rate (ICMR) mesures the fraction of instruction cache misses per executed instruction.

7.4.3 Dcache read miss rate

CONF0: 0xE (Dcache read access)

CONF1: 0xA (Dcache read miss)

DCMR = PCNT1 / PCNT0

The data cache read miss rate (DCRMR) mesures the fraction of data cache read misses per data cache read access.

7.4.4 Average instruction fetch miss latency

CONF0: 0x1 (Instruction fetch stall)

CONF1: 0x0 (Icache miss)

AIFML = PCNT0 / PCNT1

The average instruction fetch miss latency (AIFML) mesures the average number of clock cycles spent per instruction cache miss. This measure does not consider cycles spent due to ITLB misses.

7.4.5 Fraction of execution time spent stalling due to instruction fetch misses

CONF0: 0x1 (Instruction fetch stall)

AIFML = PCNT0 / PCCNT

The fraction of execution time spent stalling due to instruction fetch misses mesures the ratio of clock cycles spent waiting for an instruction to be fetched to the total number of execution cycles.

7.4.6 Average writeback stall duration

CONF0: 0x8 (Write buffer full occurrences)

CONF1: 0x9 (Write buffer full cycles)

AWSD = PCNT0 / PCNT1

The average writeback stall duration (AWSD) mesures the average number of clock cycles spent stalling due to a full writebuffer.

7.4.7 Fraction of execution time spent stalling due to writeback

CONF0: 0x9 (Write buffer full cycles)

FETW=CONF0/PCCNT

The fraction of execution time spent stalling due to writeback (FETW) is the ratio of writebuffer full stall cycles to the total number of cycles.

7.4.8 ITLB miss rate

CONF0: 0x3 (ITLB miss)

CONF1: 0x7 (Instruction count)

IMR = PCNT0 / PCNT1

The ITLB miss rate (IMR) is the ratio of ITLB misses to the number of instructions executed.

7.4.9 DTLB miss rate

CONF0: 0x4 (DTLB miss)

CONF1: 0x7 (Instruction count)

IMR = PCNT0 / PCNT1

The DTLB miss rate (DMR) is the ratio of DTLB misses to the number of instructions executed.

7.4.10 Branch prediction hit rate

CONF0: 0x17 (BTB hit)

CONF1: 0x5 (Branch executed)

BPHR = PCNT0 / PCNT1

The branch prediction hit rate (BPHR) is the ratio of BTB hits to the number of branches executed.

7.4.11 Branch prediction correct rate

CONF0: 0x5 (Branch executed)

CONF1: 0x6 (Branch mispredicted)

BPCR = PCNT1 / PCNT0

The branch prediction correct rate (BPCR) is the ratio of branch mispredictions to the total number of executed branches.

ATMEL®

62 AVR32 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 possible sources of events are listed in Table 8-1 on page 67.

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 passed to an event handler at an address specified in Table 8-1 on page 67. Most of the handlers 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 autovector 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 interrupt requests, yielding a uniform event handling scheme.

If the application is executing in the secure state, the event handling is modified as explained in "Event handling in secure state" on page 92. This is to protect from hacking secure code using 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 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 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, registers 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-

32000D-04/2011 ATMEL 63

ing the appropriate bit. Each exception handler has a dedicated handler address, and this address uniquely identifies the exception source. 3. The Mode bits are set to reflect the priority of the accepted event, and the correct regis- ter file bank is selected. The address of the event handler, as shown in Table 8-1, is loaded into the Program Counter.

The execution of the event handler routine then continues from the effective address calculated.

The rete instruction signals the end of the event. When encountered, the Return Status Register and Return Address Register are popped from the system stack and restored to the Status Reg- ister and Program Counter. If the rete instruction returns from INT0, INT1, INT2 or INT3, registers R8 to R12 and LR are also popped from the system stack. The restored Status Regis- ter contains information allowing the core to resume operation in the previous execution mode. This concludes the event handling.

8.1.2 Supervisor calls

The AVR32 instruction set provides a supervisor mode call instruction. The scall instruction is designed so that privileged routines can be called from any context. This facilitates sharing of code between different execution modes. The scall mechanism is designed so that a minimal execution cycle overhead is experienced when performing supervisor routine calls from time- critical event handlers.

The scall instruction behaves differently depending on which mode it is called from. The behav- iour is detailed in the instruction set reference. In order to allow the scall routine to return to the correct context, a return from supervisor call instruction, rets, is implemented. In the AVR32A microarchitecture, scall and rets uses the system stack to store the return address and the sta- tus register.

8.1.3 Debug requests

The AVR32 architecture defines a dedicated debug mode. When a debug request is received by the core, Debug mode is entered. Entry into Debug mode can be masked by the DM bit in the status register. Upon entry into Debug mode, hardware sets the SR[D] bit and jumps to the Debug Exception handler. By default, debug mode executes in the exception context, but with dedicated Return Address Register and Return Status Register. These dedicated registers remove the need for storing this data to the system stack, thereby improving debuggability. The mode bits in the status register can freely be manipulated in Debug mode, to observe registers in all contexts, while retaining full privileges.

Debug mode is exited by executing the retd instruction. This returns to the previous context.

8.2 Event handling in AVR32B

8.2.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-

64 AVR32 32000D-04/2011

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 in the Return Status Register and Return Address Register corresponding to the new context. Saving 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 clearing the appropriate bit. Each exception handler has a dedicated handler address, and this address uniquely identifies the exception source.

3. The Mode bits are set correctly to reflect the priority of the accepted event, and the correct register file banks are selected. The address of the event handler, as shown in Table 8-1, is loaded into the Program Counter.

The execution of the event routine then continues from the effective address calculated.

The rete instruction signals the end of the event. When encountered, the values in the Return Status Register and Return Address Register corresponding to the event context are restored to the Status Register and Program Counter. The restored Status Register contains information allowing the core to resume operation in the previous execution mode. This concludes the event handling.

8.2.2 Supervisor calls

The AVR32 instruction set provides a supervisor mode call instruction. The scall instruction is designed so that privileged routines can be called from any context. This facilitates sharing of code between different execution modes. The scall mechanism is designed so that a minimal execution cycle overhead is experienced when performing supervisor routine calls from time-critical event handlers.

The scall instruction behaves differently depending on which mode it is called from. The behaviour is detailed in the instruction set reference. In order to allow the scall routine to return to the correct context, a return from supervisor call instruction, rets, is implemented.

8.2.3 Debug requests

The AVR32 architecture defines a dedicated debug mode. When a debug request is received by the core, Debug mode is entered. Entry into Debug mode can be masked by the DM bit in the status register. Upon entry into Debug mode, hardware sets the SR[D] bit and jumps to the Debug Exception handler. By default, debug mode executes in the exception context, but with dedicated Return Address Register and Return Status Register. These dedicated registers remove the need for storing this data to the system stack, thereby improving debuggability. The mode bits in the status register can freely be manipulated in Debug mode, to observe registers in all contexts, while retaining full privileges.

Debug mode is exited by executing the retd instruction. This returns to the previous context.

32000D-04/2011 ATMEL 65

8.3 Entry points for events

Several different event handler entry points exists. For AVR32A, the reset routine is placed at address 0x8000_0000. This places the reset address in the flash memory area. For AVR32B, the reset routine entry address is always fixed to 0xA000_0000. This address resides in unmapped, uncached space in order to ensure well-defined resets.

TLB miss exceptions and scall have a dedicated space relative to EVBA where their event handler can be placed. This speeds up execution by removing the need for a jump instruction placed at the program address jumped to by the event hardware. All other exceptions have a dedicated event routine entry point located relative to EVBA. The handler routine address identifies the exception source directly.

All external interrupt requests have entry points located at an offset relative to EVBA. This autovector offset is specified by an external Interrupt Controller. The programmer must make sure that none of the autovector offsets interfere with the placement of other code. The reach of the autovector offset is IMPLEMENTATION DEFINED.

Special considerations should be made when loading EVBA with a pointer. Due to security considerations, the event handlers should be located in the privileged address space, or in a privileged memory protection region. In a system with MPU, the event routines could be placed in a cacheable protection region. In a segmented AVR32B system, some segments of the virtual memory space may be better suited than others for holding event handlers. This is due to differences in translateability and cacheability between segments. A cacheable, non-translated segment may offer the best performance for event handlers, as this will eliminate any TLB misses and speed up instruction fetch. The user may also consider to lock the event handlers in the instruction cache.

If several events occur on the same instruction, they are handled in a prioritized way. The priority ordering is presented in Table 8-1. If events occur on several instructions at different locations in the pipeline, the events on the oldest instruction are always handled before any events on any younger instruction, even if the younger instruction has events of higher priority than the oldest instruction. An instruction B is younger than an instruction A if it was sent down the pipeline later than A.

The addresses and priority of simultaneous events are shown in Table 8-1 on page 67

66 AVR32 32000D–04/2011

Table 8-1. Priority and handler addresses for events

The interrupt system requires that an interrupt controller is present outside the core in order to prioritize requests and generate a correct offset if more than one interrupt source exists for each priority level. An interrupt controller generating different offsets depending on interrupt request source is referred to as autovectoring. Note that the interrupt controller should generate autovector addresses that do not conflict with addresses in use by other events or regular program code.

32000D–□□/□□□□

The addresses of the interrupt routines are calculated by adding the address on the autovector offset bus to the value of the Exception Vector Base Address (EVBA). The INT0, INT1, INT2, INT3, and NMI signals indicate the priority of the pending interrupt. INT0 has the lowest priority, and NMI the highest priority of the interrupts. Implementations may require that EVBA is aligned in an IMPLEMENTATION DEFINED way in order to support autovectoring.

8.3.1 Description of events in AVR32A

8.3.1.1 Reset Exception

The Reset exception is generated when the reset input line to the CPU is asserted. The Reset exception can not be masked by any bit. The Reset exception resets all synchronous elements and registers in the CPU pipeline to their default value, and starts execution of instructions at address 0x8000_0000.

SR = reset_value_of_SREG; PC = 0x8000_0000;

All other system registers are reset to their reset value, which may or may not be defined. Refer to the Programming Model chapter for details.

8.3.1.2 OCD Stop CPU Exception

The OCD Stop CPU exception is generated when the OCD Stop CPU input line to the CPU is asserted. The OCD Stop CPU exception can not be masked by any bit. This exception is identical to a non-maskable, high priority breakpoint. Any subsequent operation is controlled by the OCD hardware. The OCD hardware will take control over the CPU and start to feed instructions directly into the pipeline.

RSR_DBG = SR; RAR_DBG = PC; SR[M2:M0] = B'110; SR[R] = 0; SR[J] = 0; SR[D] = 1; SR[DM] = 1; SR[EM] = 1; SR[GM] = 1;

AVR32

8.3.1.3 Unrecoverable Exception

The Unrecoverable Exception is generated when an exception request is issued when the Exception Mask (EM) bit in the status register is asserted. The Unrecoverable Exception can not be masked by any bit. The Unrecoverable Exception is generated when a condition has occurred that the hardware cannot handle. The system will in most cases have to be restarted if this condition occurs.

*(--SPSYS) = PC of offending instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'110; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x00;

8.3.1.4 TLB Multiple Hit Exception

TLB Multiple Hit exception is issued when multiple address matches occurs in the TLB, causing an internal inconsistency.

This exception signals a critical error where the hardware is in an undefined state. All interrupts are masked, and PC is loaded with EVBA + 0x04. MMU-related registers are updated with information in order to identify the failing address and the failing TLB if multiple TLBs are present. TLBEHI[ASID] is unchanged after the exception, and therefore identifies the ASID that caused the exception.

TLBEAR = FAILING_VIRTUAL_ADDRESS; TLBEHI[VPN] = FAILING_PAGE_NUMBER; TLBEHI[I] = 0/1, depending on which TLB caused the error; *(--SPSYS) = PC of offending instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'110; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x04;

32000D-04/2011 69

AMEL

8.3.1.5 Bus Error Exception on Data Access

The Bus Error on Data Access exception is generated when the data bus detects an error condition. This exception is caused by events unrelated to the instruction stream, or by data written to the cache write-buffers many cycles ago. Therefore, execution can not be resumed in a safe way after this exception. The value placed in RAR_EX is unrelated to the operation that caused the exception. The exception handler is responsible for performing the appropriate action.

*(--SPSYS) = PC of first non-issued instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'110; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x08;

8.3.1.6 Bus Error Exception on Instruction Fetch

The Bus Error on Instruction Fetch exception is generated when the data bus detects an error condition. This exception is caused by events related to the instruction stream. Therefore, execution can be restarted in a safe way after this exception, assuming that the condition that caused the bus error is dealt with.

*(--SPSYS) = PC of first non-issued instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'110; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x0C;

8.3.1.7 NMI Exception

The NMI exception is generated when the NMI input line to the core is asserted. The NMI exception can not be masked by the SR[GM] bit. However, the core ignores the NMI input line when processing an NMI Exception (the SR[M2:M0] bits are B'111). This guarantees serial execution of NMI Exceptions, and simplifies the NMI hardware and software mechanisms.

Since the NMI exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. After finishing the NMI exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream.

*(--SPSYS) = PC of first noncompleted instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'111; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x10;

70 AVR32 32000D–04/2011

8.3.1.8 INT3 Exception

The INT3 exception is generated when the INT3 input line to the core is asserted. The INT3 exception can be masked by the SR[GM] bit, and the SR[I3M] bit. Hardware automatically sets the SR[I3M] bit when accepting an INT3 exception, inhibiting new INT3 requests when processing an INT3 request.

The INT3 Exception handler address is calculated by adding EVBA to an interrupt vector offset specified by an interrupt controller outside the core. The interrupt controller is responsible for providing the correct offset.

Since the INT3 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. After finishing the INT3 exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream.

• (--SP_sys) = R8;
• (--SP_sys) = R9;
• (--SP_sys) = R10;
• (--SP_sys) = R11;
• (--SP_sys) = R12;
• (--SP_sys) = LR;
• (--SP_sys) = PC of first noncompleted instruction;
• (--SP_sys) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'101; SR[I3M] = 1; SR[I2M] = 1; SR[I1M] = 1; SR[I0M] = 1; PC = EVBA + INTERRUPT_VECTOR_OFFSET;

8.3.1.9 INT2 Exception

The INT2 exception is generated when the INT2 input line to the core is asserted. The INT2 exception can be masked by the SR[GM] bit, and the SR[I2M] bit. Hardware automatically sets the SR[I2M] bit when accepting an INT2 exception, inhibiting new INT2 requests when processing an INT2 request.

The INT2 Exception handler address is calculated by adding EVBA to an interrupt vector offset specified by an interrupt controller outside the core. The interrupt controller is responsible for providing the correct offset.

Since the INT2 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. After finishing the INT2 exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream.

• (--SP_sys) = R8;
• (--SP_sys) = R9;
• (--SP_sys) = R10;
• (--SP_sys) = R11;
• (--SP_sys) = R12;
• (--SP_sys) = LR;

*(--SPSYS) = PC of first noncompleted instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'100; SR[I2M] = 1; SR[I1M] = 1; SR[IOm] = 1; PC = EVBA + INTERRUPT_VECTOR_OFFSET;

8.3.1.10 INT1 Exception

The INT1 exception is generated when the INT1 input line to the core is asserted. The INT1 exception can be masked by the SR[GM] bit, and the SR[I1M] bit. Hardware automatically sets the SR[I1M] bit when accepting an INT1 exception, inhibiting new INT1 requests when processing an INT1 request.

The INT1 Exception handler address is calculated by adding EVBA to an interrupt vector offset specified by an interrupt controller outside the core. The interrupt controller is responsible for providing the correct offset.

Since the INT1 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. After finishing the INT1 exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream.

*(--SPSYS) = R8; *(--SPSYS) = R9; *(--SPSYS) = R10; *(--SPSYS) = R11; *(--SPSYS) = R12; *(--SPSYS) = LR; *(--SPSYS) = PC of first noncompleted instruction; *(--SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'011; SR[I1M] = 1; SR[IOm] = 1; PC = EVBA + INTERRUPT_VECTOR_OFFSET;

72 AVR32 32000D-04/2011

AVR32

8.3.1.11 INT0 Exception

The INT0 exception is generated when the INT0 input line to the core is asserted. The INT0 exception can be masked by the SR[GM] bit, and the SR[I0M] bit. Hardware automatically sets the SR[I0M] bit when accepting an INT0 exception, inhibiting new INT0 requests when processing an INT0 request.

The INT0 Exception handler address is calculated by adding EVBA to an interrupt vector offset specified by an interrupt controller outside the core. The interrupt controller is responsible for providing the correct offset.

Since the INT0 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. After finishing the INT0 exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream.

*(-SPSYS) = R8; *(-SPSYS) = R9; *(-SPSYS) = R10; *(-SPSYS) = R11; *(-SPSYS) = R12; *(-SPSYS) = LR; *(-SPSYS) = PC of first noncompleted instruction; *(-SPSYS) = SR; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'010; SR[I0M] = 1; PC = EVBA + INTERRUPT_VECTOR_OFFSET;

8.3.1.12 Instruction Address Exception

The Instruction Address Error exception is generated if the generated instruction memory address has an illegal alignment.

*(-SPSYS) = PC; *(-SPSYS) = SR; TLBEAR = FAILING_VIRTUAL_ADDRESS; TLBEHI[VPN] = FAILING_PAGE_NUMBER; SR[R] = 0; SR[J] = 0; SR[M2:M0] = B'110; SR[EM] = 1; SR[GM] = 1; PC = EVBA + 0x14;

32000D-04/2011 73