ATUC64L4U Atmel Corporation, ATUC64L4U Datasheet - Page 60

• Manufacturer Part Number: ATUC64L4U
• Manufacturer: Atmel Corporation

Specifications of ATUC64L4U

• Flash (kbytes): 64 Kbytes
• Pin Count: 48
• Max. Operating Frequency: 50 MHz
• Cpu: 32-bit AVR
• # Of Touch Channels: 17
• Hardware Qtouch Acquisition: Yes
• Max I/o Pins: 36
• Ext Interrupts: 36
• Usb Transceiver: 1
• Usb Speed: Full Speed
• Usb Interface: Device
• Spi: 1
• Twi (i2c): 2
• Uart: 4
• Lin: 4
• Ssc: 1
• Graphic Lcd: No
• Video Decoder: No
• Camera Interface: No
• Adc Channels: 8
• Adc Resolution (bits): 12
• Adc Speed (ksps): 460
• Analog Comparators: 8
• Resistive Touch Screen: No
• Temp. Sensor: Yes
• Crypto Engine: No
• Sram (kbytes): 16
• Self Program Memory: YES
• Dram Memory: No
• Nand Interface: No
• Picopower: Yes
• Temp. Range (deg C): -40 to 85
• I/o Supply Class: 1.62 to 3.6
• Operating Voltage (vcc): 1.62 to 3.6
• Fpu: No
• Mpu / Mmu: Yes / No
• Timers: 6
• Output Compare Channels: 18
• Input Capture Channels: 12
• Pwm Channels: 35
• 32khz Rtc: Yes
• Calibrated Rc Oscillator: Yes

Figure 5-1.
5.3
5.4
5.5
32002F–03/2010
Secure state boot sequence
Secure state debugging
Events in secure state
ATMEL
Typical secure state use scenario
Empty device
At system boot time, hardware state machines preloads the secure state address registers with
an initial value programmed into a secure section in the flash. Also, the SS bit in the status reg-
ister is preloaded with the value of the Secure State Enable (SSE) fuse from the flash. This
preloading is done before the system has completed the boot sequence, so the secure state
address registers and SR[SS] are initialized before code starts executing and before the debug
system has been enabled.
Normally, debugging when executing in secure state should be turned off to prevent compromis-
ing the secure code. However, it is useful to allow debugging of the secure state code during
development of this code. A fuse in flash, called Secure State Debug Enable (SSDE), can be
programmed to enable debugging of secure state code.
Normal RISC state interrupt and exception handling has been described in
handling” on page
tions are received in secure state:
Note that in the secure state, all exception sources share the same handler address. It is there-
fore not possible to separate different exception causes when in the secure world. The secure
world system must be designed to support this, the most obvious solution is to design the secure
software so that exceptions will not arise when executing in the secure world.
• A sscall instruction will set SR[GM]. In secure state, SR[GM] masks both INT0-INT3, and
• sscall has handler address at 0x8000_0004.
• Exceptions have a handler address at 0x8000_0008.
• NMI has a handler address at 0x8000_000C.
• BREAKPOINT has a handler address at 0x8000_0010.
• INT0-INT3 are not autovectored, but have a common handler address at 0x8000_0014.
NMI. Clearing SR[GM], INT0-INT3 and NMI will remove the mask of these event sources.
INT0-INT3 are still additionally masked by the I0M-I3M bits in the status register.
COMPANY A
(Secret IP)
22. This behavior is modified in the following way when interrupts and excep-
Secure memories
programmed
SSE set
COMPANY B
(Application)
SSE + flash security
All memories
programmed
fuse set
Section 3.7 ”Event
END USER
AVR32
60