AT32UC3A4128 Atmel Corporation, AT32UC3A4128 Datasheet - Page 31
![no-image](/images/manufacturer_photos/0/0/79/atmel_corporation_sml.jpg)
AT32UC3A4128
Manufacturer Part Number
AT32UC3A4128
Description
Manufacturer
Atmel Corporation
Datasheets
1.AT32UC3A0128.pdf
(377 pages)
2.AT32UC3A0128.pdf
(33 pages)
3.AT32UC3A0128.pdf
(159 pages)
4.AT32UC3A3128.pdf
(91 pages)
5.AT32UC3A3128.pdf
(1012 pages)
Specifications of AT32UC3A4128
Flash (kbytes)
128 Kbytes
Pin Count
100
Max. Operating Frequency
66 MHz
Cpu
32-bit AVR
Hardware Qtouch Acquisition
No
Usb Transceiver
1
Usb Speed
Hi-Speed
Usb Interface
Device + OTG
Spi
6
Twi (i2c)
2
Uart
4
Sd / Emmc
2
Graphic Lcd
No
Video Decoder
No
Camera Interface
No
Adc Channels
8
Adc Resolution (bits)
10
Resistive Touch Screen
No
Temp. Sensor
No
Crypto Engine
No
Sram (kbytes)
128
Self Program Memory
YES
Dram Memory
No
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
6
Input Capture Channels
6
32khz Rtc
Yes
Calibrated Rc Oscillator
Yes
Available stocks
Company
Part Number
Manufacturer
Quantity
Price
Company:
Part Number:
AT32UC3A4128S-C1UR
Manufacturer:
ATMEL
Quantity:
2 620
Company:
Part Number:
AT32UC3A4128S-CIUT
Manufacturer:
ATMEL
Quantity:
350
Part Number:
AT32UC3A4128S-CIUT
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
Company:
Part Number:
AT32UC3A4128S-U
Manufacturer:
ATMEL
Quantity:
12 914
Company:
Part Number:
AT32UC3A4128SC101
Manufacturer:
STM
Quantity:
6 278
Company:
Part Number:
AT32UC3A4128SC1UT
Manufacturer:
ATMEL
Quantity:
6 055
4. Secure state
4.1
32000D–04/2011
Mechanisms implementing the Secure State
Revision 3 of the AVR32 architecture introduces a secure execution state. This state is intended
to allow execution of a proprietary secret code alongside code of unknown origin and intent on
the same processor. For example, a company with a proprietary algorithm can program this
algorithm into the secure memory sections of the device, and resell the device with the pro-
grammed algorithm to an end customer. The end customer will not be able to read or modify the
preprogrammed code in any way. Examples of such preprogrammed code can be multimedia
codecs, digital signal processing algorithms or telecom software stacks. Whereas previous
approaches to this problem required the proprietary code and the end user application to exe-
cute on separate devices, the secure state allows integration of the two codes on the same
device, saving cost and increasing performance since inter-IC communication is no longer
required.
In order to keep the proprietary code secret, this code will execute in a “secure world”. The end
user application will execute in a “nonsecure world”. Code in the nonsecure world can request
services from the secure world by executing a special instruction, sscall. This instruction is exe-
cuted in the context of an API specified by the provider of the proprietary code. The sscall
instruction can be associated with arguments passed in registers or memory, and after execu-
tion of the requested algorithm, the secure world returns results to the requesting nonsecure
application in registers or in memory.
Hardware is implemented to divide the memory resources into two sections, one secure and one
non-secure section. The secure section of the memories can only be accessed (read, written or
executed) from code running in the secure world. The nonsecure section of the memories can
be read, written or executed from the nonsecure world, and read or written from the secure
world.
The customer can choose if his application will enable the secure state support or not. An
IMPLEMENTATION DEFINED mechanism, usually a Flash fuse, is used to enable or disable
secure state support. If this mechanism is programmed so as to disable the secure state, the
system will boot in nonsecure world, and its behavior will be identical to previous devices imple-
menting older revisions of the AVR32 architecture. If the system is set up to enable secure state
support, the system will boot in the secure state. This allows configuration and startup of the
secure world application before execution is passed to the nonsecure world.
The following architectural mechanisms are used to implement the secure state:
• The sscall and retss instructions are used for passing between the secure and nonsecure
• The secure world has a dedicated stack pointer, SP_SEC, which is automatically banked into
• The SS bit is set in the status register whenever the system is in the secure state. Only sscall
• Interrupts and exceptions have special handler addresses used when receiving interrupts or
• A set of secure system registers are used to configure the secure world behavior, and to aid
worlds.
the register file whenever executing in the secure world.
and retss can alter this bit.
exceptions in the secure world. This allows executing the interrupt or exception handler in the
secure world, or jumping back into the nonsecure world to execute the handler there.
in communication between the secure and nonsecure worlds. These registers can be written
when in the secure world, but only read when in the nonsecure world.
AVR32
31