AT32UC3B0512AU Atmel Corporation, AT32UC3B0512AU Datasheet - Page 63

no-image

AT32UC3B0512AU

Manufacturer Part Number
AT32UC3B0512AU
Description
Manufacturer
Atmel Corporation

Specifications of AT32UC3B0512AU

Flash (kbytes)
512 Kbytes
Pin Count
64
Max. Operating Frequency
60 MHz
Cpu
32-bit AVR
# Of Touch Channels
32
Hardware Qtouch Acquisition
No
Max I/o Pins
44
Ext Interrupts
44
Usb Transceiver
1
Usb Speed
Full Speed
Usb Interface
Device + OTG
Spi
4
Twi (i2c)
1
Uart
3
Ssc
1
Graphic Lcd
No
Video Decoder
No
Camera Interface
No
Adc Channels
8
Adc Resolution (bits)
10
Adc Speed (ksps)
384
Resistive Touch Screen
No
Dac Channels
2
Dac Resolution (bits)
16
Temp. Sensor
No
Crypto Engine
No
Sram (kbytes)
96
Self Program Memory
YES
Dram Memory
No
Nand Interface
No
Picopower
No
Temp. Range (deg C)
-40 to 85
I/o Supply Class
3.0-3.6 or (1.65-1.95+3.0-3.6)
Operating Voltage (vcc)
3.0-3.6 or (1.65-1.95+3.0-3.6)
Fpu
No
Mpu / Mmu
Yes / No
Timers
10
Output Compare Channels
16
Input Capture Channels
6
Pwm Channels
13
32khz Rtc
Yes
Calibrated Rc Oscillator
Yes

Available stocks

Company
Part Number
Manufacturer
Quantity
Price
Part Number:
AT32UC3B0512AU-Z2U
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
8. Event Processing
8.1
8.1.1
32000D–04/2011
Event handling in AVR32A
Exceptions and interrupt requests
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
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
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
“Event handling in secure state” on page
the event system.
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
2. When a request is accepted, the Status Register and Program Counter of the current
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.
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-
92. This is to protect from hacking secure code using
Table 8-1 on page
Table 8-1 on page
67.
67. Most of the han-
AVR32
63

Related parts for AT32UC3B0512AU