AT32UC3A4128S Atmel Corporation, AT32UC3A4128S Datasheet - Page 60

• Manufacturer Part Number: AT32UC3A4128S
• Manufacturer: Atmel Corporation

Specifications of AT32UC3A4128S

• 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: AES
• 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

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