AT32UC3A3128 Atmel Corporation, AT32UC3A3128 Datasheet - Page 24

• Manufacturer Part Number: AT32UC3A3128
• Manufacturer: Atmel Corporation

Specifications of AT32UC3A3128

• Flash (kbytes): 128 Kbytes
• Pin Count: 144
• Max. Operating Frequency: 66 MHz
• Cpu: 32-bit AVR
• # Of Touch Channels: 32
• Hardware Qtouch Acquisition: No
• Max I/o Pins: 110
• Ext Interrupts: 110
• Usb Transceiver: 1
• Usb Speed: Hi-Speed
• Usb Interface: Device + OTG
• Spi: 6
• Twi (i2c): 2
• Uart: 4
• Lin: 4
• Ssc: 1
• Sd / Emmc: 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): 128
• Self Program Memory: YES
• External Bus Interface: 1
• Dram Memory: sdram
• Nand Interface: Yes
• Picopower: No
• Temp. Range (deg C): -40 to 85
• I/o Supply Class: 3.0 to 3.6
• Operating Voltage (vcc): 3.0 to 3.6
• Fpu: No
• Mpu / Mmu: Yes / No
• Timers: 6
• Output Compare Channels: 18
• Input Capture Channels: 12
• Pwm Channels: 12
• 32khz Rtc: Yes
• Calibrated Rc Oscillator: Yes

3.7.2
3.7.3
3.8
3.8.1
3.8.2
32002F–03/2010
Special concerns
Supervisor calls
Debug requests
System stack
Clearing of pending interrupt requests
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.
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.
Debug mode is exited by executing the retd instruction. This returns to the previous context.
Event handling in AVR32UC, like in all AVR32A architectures, 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 exception code may be timing-critical, SP_SYS should point 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.
When an interrupt request is accepted by the CPU, the interrupt handler will eventually be
called. The interrupt handler is responsible for performing the required actions so that the
requesting module disasserts the interrupt request before the interrupt routine is exited with rete.
Failing to do so will cause the interrupt handler to be re-entered after the rete instruction has
been executed, since the interrupt request is still active. Different interrupt sources have differ-
ent ways of disasserting requests, for example reading an interrupt cause register or writing to
specific control registers. Refer to the module-specific documentation for information on how to
disassert interrupt requests.
Disasserting an interrupt request often requires that a bus access is performed to the requesting
module. An example of such an access is to read an interrupt cause register. There will be a
latency from the execution of the load or store instruction that is to disassert the interrupt request
and the actual disassertion of the request. This latency can be caused by the bus system and
internal latencies in the interrupting module. It is important that the programmer makes sure that
the interrupt request has actually been disasserted before returning from the interrupt with rete.
AVR32
24