SAM9RL64 Atmel Corporation, SAM9RL64 Datasheet - Page 245

• Manufacturer Part Number: SAM9RL64
• Manufacturer: Atmel Corporation

Specifications of SAM9RL64

• Flash (kbytes): 0 Kbytes
• Pin Count: 217
• Max. Operating Frequency: 240 MHz
• Cpu: ARM926
• Hardware Qtouch Acquisition: No
• Max I/o Pins: 118
• Ext Interrupts: 118
• Usb Transceiver: 1
• Usb Speed: Hi-Speed
• Usb Interface: Device
• Spi: 1
• Twi (i2c): 2
• Uart: 5
• Ssc: 2
• Sd / Emmc: 1
• Graphic Lcd: Yes
• Video Decoder: No
• Camera Interface: No
• Adc Channels: 6
• Adc Resolution (bits): 10
• Adc Speed (ksps): 220
• Resistive Touch Screen: Yes
• Temp. Sensor: No
• Crypto Engine: No
• Sram (kbytes): 64
• Self Program Memory: NO
• External Bus Interface: 1
• Dram Memory: sdram
• Nand Interface: Yes
• Picopower: No
• Temp. Range (deg C): -40 to 85
• I/o Supply Class: 1.8/3.3
• Operating Voltage (vcc): 1.08 to 1.32
• Fpu: No
• Mpu / Mmu: No / Yes
• Timers: 3
• Output Compare Channels: 3
• Input Capture Channels: 3
• Pwm Channels: 4
• 32khz Rtc: Yes
• Calibrated Rc Oscillator: No

Debug in Depth
Bit 33 of scan chain 1 is used to force the ARM7TDMI core to resynchronize back to
MCLK. The penultimate instruction of the debug sequence is scanned in with bit 33 set
HIGH. The final instruction of the debug sequence is the branch and this is scanned in
with bit 33 LOW. The core is then clocked to load the branch into the pipeline. Now, the
RESTART instruction is selected in the TAP controller. When the state machine enters
the RUN-TEST-IDLE state, the scan chain reverts back to system mode and clock
resynchronization to MCLK occurs in the core. The ARM7TDMI core then resumes
normal operation, fetching instructions from memory. The delay, until the state machine
is in the RUN-TEST-IDLE state, enables conditions to be set up in other devices in a
multiprocessor system without taking immediate effect. Then, when the
RUN-TEST-IDLE state is entered, all processors resume operation simultaneously.
The function of DBGACK is to tell the rest of the system when the core is in debug
state. This can be used to inhibit peripherals such as watchdog timers that have real time
characteristics. Also, DBGACK can be used to mask out memory accesses which are
caused by the debugging process. For example, when the core enters debug state after a
breakpoint, the instruction pipeline contains the breakpointed instruction plus two other
instructions that have been prefetched. On entry to debug state, the pipeline is flushed.
Therefore, on exit from debug state, the pipeline must be refilled to its previous state.
Because of the debugging process, more memory accesses occur than is normally
expected. Any system peripheral that is sensitive to the number of memory accesses can
be inhibited by using DBGACK.
For example, imagine a fictitious peripheral that simply counts the number of memory
cycles. This device must return the same answer after a program has been run both with
and without debugging. Figure B-6 on page B-28 shows the behavior of the core on exit
from the debug state.
ARM DDI 0029G
Copyright © 1994-2001. All rights reserved.
B-27