ADSP-BF514KSWZ-4F4 Analog Devices Inc, ADSP-BF514KSWZ-4F4 Datasheet - Page 19

• Manufacturer Part Number: ADSP-BF514KSWZ-4F4
• Description: Low-Pwr BF Proc W/flash & Cnsmr Conctvty
• Manufacturer: Analog Devices Inc
• Series: Blackfin®r
• Type: Fixed Pointr

Specifications of ADSP-BF514KSWZ-4F4

• Interface: I²C, PPI, RSI, SPI, SPORT, UART/USART
• Clock Rate: 400MHz
• Non-volatile Memory: FLASH (4Mbit)
• On-chip Ram: 116kB
• Voltage - I/o: 1.8V, 2.5V, 3.3V
• Voltage - Core: 1.30V
• Operating Temperature: 0°C ~ 70°C
• Mounting Type: Surface Mount
• Package / Case: 176-LQFP Exposed Pad, 176-eLQFP, 176-HLQFP
• Architecture: Modified Harvard
• Format: Fixed Point
• Clock Freq (max): 400MHz
• Device Input Clock Speed: 400MHz
• Ram Size: 48KB
• Program Memory Size: 1024KB
• Operating Temp Range: 0C to 70C
• Operating Temperature Classification: Commercial
• Mounting: Surface Mount
• Pin Count: 176
• Package Type: LQFP EP
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

Table 9. Booting Modes (Continued)
BMODE2–0 Description
011
100
101
110
111
• Idle/no boot mode (BMODE = 0x0)—In this mode, the
• Boot from 8-bit or 16-bit external flash memory
• Boot from internal SPI memory (BMODE = 0x2)—The
• Boot from external SPI EEPROM or flash
• Boot from SPI0 host device (BMODE = 0x4)—The proces-
• Boot from OTP memory (BMODE = 0x5)—This provides
processor goes into idle. The idle boot mode helps recover
from illegal operating modes, such as when the user has
mis configured the OTP memory.
(BMODE = 0x1)—In this mode, the boot kernel loads the
first block header from address 0x2000 0000 and—depend-
ing on instructions containing in the header—the boot
kernel performs 8-bit or 16-bit boot or starts program exe-
cution at the address provided by the header. By default, all
configuration settings are set for the slowest device possible
(3-cycle hold time, 15-cycle R/W access times, 4-cycle
setup).
The ARDY is not enabled by default, but it can be enabled
by OTP programming. Similarly, all interface behavior and
timings can be customized by OTP programming. This
includes activation of burst-mode or page-mode operation.
In this mode, all signals belonging to the asynchronous
interface are enabled at the port muxing level.
processor uses the internal PH8 GPIO signal to load code
previously loaded to the 4M bit internal SPI flash con-
nected to SPI0. Only available on the ADSP-BF512F/
ADSP-BF514F/ADSP-BF516F/ADSP-BF518F.
(BMODE = 0x3)—8-bit, 16-bit, 24-bit or 32-bit address-
able devices are supported. The processor uses the PG15
GPIO signal (at SPI0SEL2) to select a single SPI
EEPROM/flash device connected to the SPI0 interface;
then submits a read command and successive address bytes
(0x00) until a valid 8-, 16-, 24-, or 32-bit addressable device
is detected. Pull-up resistors are required on the SSEL and
MISO signals. By default, a value of 0x85 is written to the
SPI0_BAUD register.
sor operates in SPI slave mode and is configured to receive
the bytes of the LDR file from an SPI host (master) agent.
In the host, the HWAIT signal must be interrogated by the
host before every transmitted byte. A pull-up resistor is
required on the SPI0SS input. A pull-down on the serial
clock may improve signal quality and booting robustness.
a stand-alone booting method. The boot stream is loaded
from on-chip OTP memory. By default the boot stream is
expected to start from OTP page 0x40 on and can occupy
ADSP-BF512/BF512F, BF514/BF514F, BF516/BF516F, BF518/BF518F
Boot from external SPI memory (EEPROM or flash)
Boot from SPI0 host
Boot from OTP memory
Boot from SDRAM
Boot from UART0 Host
Rev. A | Page 19 of 72 | August 2010
For each of the boot modes, a 16-byte header is first read from
an external memory device. The header specifies the number of
bytes to be transferred and the memory destination address.
Multiple memory blocks may be loaded by any boot sequence.
Once all blocks are loaded, program execution commences from
the address stored in the EVT1 register.
Prior to booting, the pre-boot routine interrogates the OTP
memory. Individual boot modes can be customized or even dis-
abled based on OTP programming. External hardware,
especially booting hosts may watch the HWAIT signal to deter-
mine when the pre-boot has finished and the boot kernel starts
the boot process. By programming OTP memory, the user can
instruct the preboot routine to also customize the PLL, the
SDRAM Controller, and the Asynchronous Interface.
The boot kernel differentiates between a regular hardware reset
and a wakeup-from-hibernate event to speed up booting in the
later case. Bits 6-4 in the system reset configuration (SYSCR)
register can be used to bypass pre-boot routine and/or boot ker-
nel in case of a software reset. They can also be used to simulate
a wakeup-from-hibernate boot in the software reset case.
The boot process can be further customized by “initialization
code.” This is a piece of code that is loaded and executed prior to
the regular application boot. Typically, this is used to configure
the SDRAM controller or to speed up booting by managing
PLL, clock frequencies, wait states, or serial bit rates.
The boot ROM also features C-callable function entries that can
be called by the user application at run time. This enables sec-
ond-stage boot or boot management schemes to be
implemented with ease.
• Boot from SDRAM (BMODE = 0x6)—This is a warm boot
• Boot from UART0 host (BMODE = 0x7)—Using an auto-
all public OTP memory up to page 0xDF. This is 2560
bytes. Since the start page is programmable the maximum
size of the boot stream can be extended to 3072 bytes.
scenario, where the boot kernel starts booting from address
0x0000 0010. The SDRAM is expected to contain a valid
boot stream and the SDRAM controller must be configured
by the OTP settings.
baud handshake sequence, a boot-stream formatted
program is downloaded by the host. The host selects a bit
rate within the UART clocking capabilities.
When performing the autobaud, the UART expects a “@”
(0x40) character (eight bits data, one start bit, one stop bit,
no parity bit) on the RX0 signal to determine the bit rate.
The UART then replies with an acknowledgement com-
posed of 4 bytes (0xBF—the value of UART0_DLL and
0x00—the value of UART0_DLH). The host can then
download the boot stream. To hold off the host the Blackfin
processor signals the host with the boot host wait
(HWAIT) signal. Therefore, the host must monitor
HWAIT before every transmitted byte.