Rev. D | Page 16 of 68 | April 2014
ADSP-BF512/BF514/BF514F16/BF516/BF518/BF518F16
• Boot from SPI0 host device (BMODE = 0x4)—The proces-
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.
• Boot from OTP memory (BMODE = 0x5)—This provides
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
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.
• Boot from SDRAM (BMODE = 0x6)—This is a warm boot
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.
•Boot from UART0 host (BMODE = 0x7)—Using an auto-
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.
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.
INSTRUCTION SET DESCRIPTION
The Blackfin processor family assembly language instruction set
employs an algebraic syntax designed for ease of coding and
readability. The instructions have been specifically tuned to pro-
vide a flexible, densely encoded instruction set that compiles to
a very small final memory size. The instruction set also provides
fully featured multifunction instructions that allow the pro-
grammer to use many of the processor core resources in a single
instruction. Coupled with many features more often seen on
microcontrollers, this instruction set is very efficient when com-
piling C and C++ source code. In addition, the architecture
supports both user (algorithm/application code) and supervisor
(O/S kernel, device drivers, debuggers, ISRs) modes of opera-
tion, allowing multiple levels of access to core
processor resources.
The assembly language, which takes advantage of the proces-
sor’s unique architecture, offers the following advantages:
• Seamlessly integrated DSP/MCU features are optimized for
both 8-bit and 16-bit operations.
• A multi-issue load/store modified-harvard architecture,
which supports two 16-bit MACs or four 8-bit ALUs plus
two load/store plus two pointer updates per cycle.
• All registers, I/O, and memory are mapped into a unified
4G byte memory space, providing a simplified program-
ming model.
• Microcontroller features, such as arbitrary bit and bit-field
manipulation, insertion, and extraction; integer operations
on 8-, 16-, and 32-bit data-types; and separate user and
supervisor stack pointers.
• Code density enhancements, which include intermixing of
16-bit and 32-bit instructions (no mode switching, no code
segregation). Frequently used instructions are encoded
in 16 bits.
DEVELOPMENT TOOLS
Analog Devices supports its processors with a complete line of
software and hardware development tools, including integrated
development environments (which include CrossCore
®
Embed-
ded Studio and/or VisualDSP++
®
), evaluation products,
emulators, and a wide variety of software add-ins.
Integrated Development Environments (IDEs)
For C/C++ software writing and editing, code generation, and
debug support, Analog Devices offers two IDEs.