Engineer-to-Engineer Notea

EE-240Technical notes on using Analog Devices DSPs, processors and development tools
Visit our Web resources http://www.analog.com/ee-notes and http://www.analog.com/processors or
e-mail processor.support@analog.com or processor.tools.support@analog.com for technical support.

ADSP-BF533 Blackfin® Booting Process
Contributed by Hiren Desai

Rev 4 – September 29, 2008

Introduction
This EE-Note describes the booting process for the ADSP-BF531, ADSP-BF532, and ADSP-BF533
Blackfin® processors. Differences between silicon revision levels are noted.
This EE-Note discusses:


Boot modes



Loader file header information



Initialization codeMulti-application (multi-DXE) management

The Booting Process
Booting is the process of loading application code/data, stored in an external memory device (or externalhost), into the various internal and external memories of the Blackfin processor. This is handled by the onchip Boot ROM which is located in Blackfin memory at address 0xEF00 0000 to 0xEF00 03FF. Figure 1
shows the sequence of operations taken from source code to the final target stand-alone system.

.ASM, .C, .CPP
Source Files.DOJ(s)Assembler and/orCompiler.DXE(s)LinkerLoader.LDR

Target System

ADSP-BF53x
Processor

Booting
Upon
RESET

External
MemoryFigure 1. ADSP-BF531/BF532/BF533 Stand-Alone System
Copyright 2004-2008, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application ofcustomers’ products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are propertyof their respective holders. Information furnished by Analog Devices applications and development tools engineers is believed to be accurate and reliable, however
no responsibility is assumed by Analog Devices regarding technical accuracy and topicality of the content provided in Analog Devices Engineer-to-Engineer Notes.

aBoot Modes (Silicon Revision 0.3)*
Blackfin processors can boot from a flash/PROM via asynchronous Bank 0 of the EBIU or an SPI device(memory or host) via the SPI interface. Table 1 lists ADSP-BF531/BF532/BF533 processor booting
modes, which are selected by the state of the BMODE[1:0] pins when the RESET signal is de-asserted.
BMODE[1:0] Description (See also Specific Blackfin Boot Modes)
00

Executes from external 16-bit memory connected to ASYNC Bank0 (bypass Boot ROM)

01

Boots from 8/16-bit flash/PROM

10

Boots from a SPI host in SPI Slave mode

11

Boots from a 8/16/24-bit addressable SPI memory in SPI Master mode with support for
Atmel AT45DB041B, AT45DB081B, and AT45DB161B DataFlash® devices

Table 1. Blackfin ADSP-BF531/BF532/BF533 Booting Modes* For boot modes supported on previous revisions of silicon, refer to the Appendix: Boot Modes vs. Silicon Revisions.

As Figure 1 illustrates, the loader utility (elfloader.exe) parses the input executable file (.DXE) andcreates a loader file (.LDR)*, consisting of blocks preceded by headers. This loader file is thenprogrammed/burned into the external memory/device. The headers are read and parsed by the on-chip
Boot ROM during booting.
* Refer to the VisualDSP++® Loader Manual for 16-Bit Processors [1] for information on switches loader files
Loader File is programmed/burned into the External Memory/Device
ADSP-BF531/BF532/BF533 Processor

Flash/PROM or SPI

10-Byte Header for Block 1
Block 1

10-Byte Header for Block 1

L1 Memory

10-Byte Header for Block 2
Block 2Block 1

Block 1

Block 3

10-Byte Header for Block 2

Block 2
10-Byte Header for Block 3

10-Byte Header for Block 3

App.
Code/
Data

Block 3Block 3...........
10-Byte Header for Block n

10-Byte Header for Block n

0xEF00 0000

Block nOn-Chip Boot
ROM

Block nSDRAM……………..

Block 2Loader File

Figure 2. ADSP-BF531/BF532/BF533 Boot Process

L

Booting into scratchpad memory (0xFFB0 0000 – 0xFFB0 0FFF) is not supported. If booting toscratchpad memory is attempted, the processor will hang within the on-chip Boot ROM.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 2 of 28

aHeader Information
As shown in Figure 3, each 10-byte header within the loader file consists of a 4-byte ADDRESS field, a 4byte COUNT field, and a 2-byte FLAG field.
10-Byte Header for Block 1
Block 1

32-Bit ADDRESS
10-Byte Header for Block 2
Block 2

32-Bit COUNT

10-Byte Header for Block 3

16-Bit FLAG

Block 3……………..
10-Byte Header for Block n

Figure 3. 10-Byte Header Contents

This 10-byte header, which precedes each block in the loader file, contains the following information usedby the on-chip Boot ROM during the boot process:

ADDRESS (4 bytes) – the target address, to which the block will be booted within memory



COUNT (4 bytes) – the number of bytes in the block

FLAG (2 bytes) – block type and control commands:
15

14

13

12

FINAL
0 - Non-Last Block
1 - Last Block

11

10

9

8

7

6

5

4

3

2

1

0
ZEROFILL
0 - Non-Zero Fill Block
1 - Zero-Fill BlockPFLAG 3:0
PF number for
SPI slave booting

RESVECT
0 - ADSP-BF531/BF532
1 - ADSP-BF533
INIT
0 - Non-Init Block
1 - Init Block
IGNORE
0 - Non-Ignore Block
1 - Ignore Block

Figure 4. Individual Control Bits of the FLAG Word

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 3 of 28

a
The FLAG bits include:

Bit 0: ZEROFILL - Indicates that the block is a buffer with zeros. ZEROFILL blocks have no
payload data. They simply instruct the on-chip Boot ROM to zero COUNT bytes starting from
ADDRESS in memory. This yields a condensed loader file for applications with large zero buffers. It
is also very helpful for ANSI-C compliant projects which often require large buffers to be zeroed
during boot time.



Bit 1: RESVECT – Indicates the reset vector after booting. All ADSP-BF531/BF532/BF533
derivatives use the same Boot ROM. This bit is set to 0 for the ADSP-BF531/BF532 and it is set to
1 for the ADSP-BF533. After booting is complete, the on-chip Boot ROM uses this bit to jump toaddress 0xFFA0 0000 for the ADSP-BF533 or to address 0xFFA0 8000 for the ADSPBF531/BF532.

L

After a hardware reset, the reset vector (stored in the EVT1 register) is set to 0xFFA0 0000
or 0xFFA0 8000, depending on the RESVECT bit. If bit 4 (No Boot on Software Reset) of
the SYSCR register is set and a software reset is issued, the processor will vector to theaddress set in the EVT1 register. This reset vector can be reconfigured to another address
during runtime and hence, an application can vector to an address other than 0xFFA0 0000
or 0xFFA0 8000 after a software reset. If the reset vector is modified during runtime,ensure that the reset vector address within the EVT1 register is a valid instruction address.
This address can be internal instruction memory, SDRAM memory, or asynchronous
memory. The EVT1 register does not have a default value. The value within this register
will be retained after a reset is issued. When BMODE = 00, the on-chip Boot ROM is
bypassed and you must initialize the EVT1 register before issuing a software reset.



Bit 3: INIT – An initialization block (Init Block) is a block of code that executes before the actual
application code boots over it. When the on-chip Boot ROM detects an Init Block, it boots theblock into internal memory and makes a CALL to it (initialization code must have an RTS at theend). After the initialization code is executed, it is typically overwritten with application code. See
Figure 5.



Bit 4: IGNORE – Indicates a block that is not booted into memory. It instructs the Boot ROM toskip COUNT bytes of the boot stream. In master boot modes, the Boot ROM can just modify its
source address pointer. In slave boot modes, the Boot ROM must actively trash the payload data.
The current VisualDSP++® tools support IGNORE blocks for global headers only (currently the 4byte DXE Count, see Multi-Application (Multi-DXE) Management section below).

Bits 8:5: PFLAG - These bits are used for SPI Slave mode boot (BMODE = 10). PFLAG indicates thePFx number used for the host wait (HWAIT) signal from the Blackfin processor to the Master SPI
host. This value can be between 1 – 15 (0x1 – 0xF) for ADSP-BF531/BF532/BF533 processors.
Refer to the SPI Slave Mode Boot via Master Host (BMODE = 10) section below for further
information on the usage of this PF strobe.

Bit 15: FINAL – Indicates boot process is complete after this block. After processing a FINAL
block, the on-chip Boot ROM jumps to the reset vector address stored in the EVT1 register. The
processor is still in Supervisor mode and in the lowest priority interrupt (IVG15) when it jumps toL1 memory for code execution.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 4 of 28

aL

Unlike ADSP-BF535 processors, ADSP-BF531/BF532/BF533 processors do not require a secondstage loader. The FLAG field of the 10-byte header provides ADSP-BF531/BF532/BF533
processors with all the information needed to execute a single-stage boot sequence without theneed for a second-stage loader.

Initialization Code (Init Code)Init Code is a feature that allows the execution of a piece code before the actual application is booted in.
This code can serve a number of purposes including initializing the SDRAM controller, or changing PLL
settings, the SPI baud rate, or EBIU wait states for faster boot time, etc. The Init Code is added to thebeginning of the loader file stream via the elfloader –Init Init_Code.DXE command-line switch, where
Init_Code.DXE refers to the user-provided custom initialization code executable.
ADSP-BF531/BF532/BF533 Processor
Flash/PROM or SPI Device
Header for Init Block

L1 Memory

Init Block

Init BlockA

Header for L1 Block

L1 Block
Header for SDRAM Block

SDRAM Block

App.
Code/
Data

........
Header for Block n

Block n0xEF00 0000
On-Chip Boot
ROM

SDRAM

ADSP-BF531/BF532/BF533 Processor
Flash/PROM or SPI Device

After Init Code
Execution

Header for Init Block

L1

Init Block
L1 BlockA

Init Block
Header for L1 Block

L1 Block
Header for SDRAM Block

SDRAM Block

App.
Code/
Data

........
Header for Block n

0xEF00 0000

Block nOn-Chip Boot
ROM
SDRAM
SDRAM Block

Figure 5. Initialization Code Execution / Boot

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 5 of 28

aWhen the on-chip Boot ROM detects a block with the INIT bit set, it will first boot it into Blackfin
memory and then execute it, by issuing a CALL to its target address. For this reason, you must terminate
the Init Code with an RTS instruction to ensure that the processor vectors back to the on-chip Boot ROM
for the rest of the boot process.

L

It is your responsibility to save all processor registers modified by Init Code and to restore them
before the Init Code returns. At a minimum, it is recommended that every Init Code saves the
ASTAT, RETS, and all Rx and Px registers. The Blackfin processor provides sufficient stack space inscratchpad memory (0xFFB0 0000 – 0xFFB0 0FFF). The Init Code can perform push and pop
operations through the stack pointer SP. Listing 1 shows an example Init Code file that
demonstrates the setup of the SDRAM controller.

#include <defBF532.h>.section program;/********************************************************************/[--SP] = ASTAT;// Save registers onto Stack[--SP] = RETS;[--SP] = (R7:0);[--SP] = (P5:0);/********************************************************************//*******Init Code Section********************************************//*******SDRAM Setup************/
Setup_SDRAM:
P0.L = lo(EBIU_SDRRC);
P0.H = hi(EBIU_SDRRC);// SDRAM Refresh Rate Control Register
R0 = 0x074A(Z);W[P0] = R0;
SSYNC;
P0.L = lo(EBIU_SDBCTL);
P0.H = hi(EBIU_SDBCTL);
R0 = 0x0001(Z);W[P0] = R0;
SSYNC;// SDRAM Memory Bank Control Register

P0.L = lo(EBIU_SDGCTL);
P0.H = hi(EBIU_SDGCTL); // SDRAM Memory Global Control Register
R0.H = 0x0091;
R0.L = 0x998D;[P0] = R0;
SSYNC;/********************************************************************/(P5:0) = [SP++];// Restore registers from Stack(R7:0) = [SP++];
RETS = [SP++];
ASTAT = [SP++];/********************************************************************/
RTS;
Listing 1. Example Init Code

Typically, an Init Code consists of a single section and is represented by a single block within the bootstream. This block has, of course, the INIT bit set. Nevertheless, an Init Block can also consist of multiple
sections. Then, multiple blocks represent the Init Code within the boot stream. Only the last block has the
ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 6 of 28

a
INIT bit set. The elfloader utility ensures that the last of these blocks vectors to the Init Code’s entry
address. If this is too challenging for the elfloader, it keeps the INIT bit cleared even for the last block andissues one extra block afterward. This extra block has the INIT bit set, but does not provide any payload
data (COUNT = 0). It only instructs the on-chip Boot ROM to execute a CALL instruction to the given
ADDRESS.

Although Init Code .DXE files are built through their own VisualDSP++ projects, they differ fromstandard projects. Init Codes provide a callable sub-function only, and thus, they look more like a librarythan an application. An Init Code is always a heading for the regular application code. Consequently,
regardless whether the Init Code consists of one or multiple blocks, it is not terminated by a FINAL bit
indicator, which would cause the Boot ROM to terminate the boot process.

Multi-Application (Multi-DXE) Management
In addition to pre-boot initialization, the Init Code feature can also be used for boot management. A loader
file (.LDR) can store multiple applications if multiple executables (.DXE files) are listed on the elfloader
command line. The elfloader creates multiple boot streams with the individual executables appended one
after the other with the Init Code DXE located at the beginning (see Figure 6).
1st
Boot
Stream

10-Byte Header for Count
4-Byte Count for Init Code DXE

nd

2
Boot
StreamInit Code

10-Byte Header for Count

10-Byte Header for Block 1

st

4-Byte Count for 1 DXE

Block 1st

1 DXE Application

10-Byte Header for Block 2
Block 2

3rd
Boot
Streamth

4
Boot
StreamEtc..

10-Byte Header for Countnd

4-Byte Count for 2
2

nd

DXE

DXE Application

10-Byte Header for Block 3
Block 3……………….

10-Byte Header for Countrd

4-Byte Count for 3 DXE
rd

3 DXE Application……………………….

Loader File

Figure 6. Multi-DXE Loader File Contents

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 7 of 28

a
The ADSP-BF531/BF532/BF533 loader file (.LDR) structure allows you to determine the boundary
between executables (DXE applications) stored in external memory, and hence, the ability to boot in a
specific DXE application. Each .DXE file that is parsed and placed within the .LDR file is preceded by an
IGNORE block. Currently, this IGNORE block contains a 4-byte count value, which is the number of bytes
contained within the DXE application including headers. In other words, it is the offset to the next DXE
application. In the future, the IGNORE block might be used to hold information in addition to the 4-byte
count value. Note that each IGNORE block is headed by a 10-byte header.
With this DXE count information, a user can essentially “jump” through whole DXE application within
the .LDR file until the DXE application chosen to be booted in is reached. Listing 2 shows a piece of Init
Code that demonstrates how to stream through multiple DXE applications from an 8-bit flash. Assuming
the .LDR file contains one Init Code DXE and two DXE applications, the Init Code jumps through the.LDR file to boot in the second DXE application.
#include <defbf533.h>.section program;[--SP] = ASTAT;// save registers onto Stack[--SP] = RETS;[--SP] = (r7:0);[--SP] = (p5:0);[--SP] = LC0;[--SP] = LT0;[--SP] = LB0;/******************************/
BOOT_DXE:
R0.H = 0x2000;// R0 = start of ASYNC Bank 0
R0.L = 0x0000;
P1 = 2;// Number of DXEs to jump over (CANNOT BE ZERO!!)// After first iteration, R0 will point to DXE1// After second iteration, R0 will point to DXE2LSETUP(ADD_DXE_COUNT_BEGIN, ADD_DXE_COUNT_END) LC0 = P1;
ADD_DXE_COUNT_BEGIN:
R1 = 0xA;// Skip over 10 bytes for the 1st 10-byte header
R1 = R1 << 1;// Multiply by 2 since we are booting from a 16-bit// flash (compensate for zero padding)
R0 = R0 + R1;
P0 = R0;// P0 points to 4-Byte DXE COUNT
R0 = W[P0++](Z);// R0 = xx | Bits[7:0] of DXE COUNT
R1 = W[P0++](Z);// R1 = xx | Bits[15:8] of DXE COUNT
R1 = R1 << 8;
R2 = W[P0++](Z);// R2 = xx | Bits[23:16] of DXE COUNT
R2 = R2 << 16;
R3 = W[P0++](Z);// R3 = xx | Bits[31:24] of DXE COUNT
R3 = R3 << 24;
R0 = R0 | R1;// R0 = Bits[15:0] of DXE COUNT
R2 = R2 | R3;// R2 = Bits[31:16] of DXE COUNT
R3 = R0 | R2;// R3 = DXE COUNT
R0 = P0;R0 = R0 + R3;// Modify pointer by the DXE COUNT so now R0 points
P0 = R0;// to next DXE
ADD_DXE_COUNT_END:
NOP;/******************************/DONE:
LB0 = [SP++];// Restore Regs

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 8 of 28

aLT0 = [SP++];
LC0 = [SP++];(p5:0) = [SP++];(r7:1) = [SP++];
RETS = [SP++];
RETS = [SP++];
ASTAT = [SP++];
RTS;//----->DO NOT RESTORE R0<------// Modify SP by one for R0 case// Pop off the real value of RETS

Listing 2. Example Init Code for Multi-DXE Boot

Note that the date register, R0, is not restored at the end of the Init Code because R0 is the external pointerfor a flash/PROM boot (BMODE = 01). When the processor returns back to the on-chip Boot ROM after
the RTS instruction, the on-chip Boot ROM will continue booting from the location stored in R0. Similarly,
if the boot mode is set for SPI booting (BMODE = 11), the external pointer is stored in R3. Hence, for an
SPI boot, do not restore R3 within the Init Code for a multi-DXE application.
Attached to this EE-Note is a multi-DXE boot example (BF533 Ez Kit Multiple DXE Boot.zip) thatuses the ADSP-BF533 EZ-KIT Lite® board. The ZIP file contains two blink application projects and an
Init Code project. Upon RESET, the on-chip Boot ROM will boot in the Init Code. The Init Code will thenwait until PF8 (SW4 push button) or PF9 (SW5 push button) are asserted. If PF8 is asserted, DXE1 will bebooted in and executed. If PF9 is asserted, DXE2 will be booted in and executed. DXE1 is an applicationthat blinks alternate LEDs on the board, and DXE2 is an application that blinks all the LEDs on the board.

Specific Blackfin Boot Modes
Now that we have a general understanding of the boot process for the ADSP-BF531, ADSP-BF532, and
ADSP-BF533 processors, the remainder of the this EE-Note will discuss information relevant to each bootmode such as hardware interface, loader file structure, and expected pin behavior. Execution from external
16-bit memory (BMODE = 00) is discussed in Running Programs from Flash on ADSP-BF533 Blackfin
Processors (EE-239) [3].
For the following sections, the ASM blink example for the ADSP-BF533 EZ-KIT Lite board with Init
Code will be used. This example is included with this EE-Note.

L

Note that for each of the boot modes listed below, addresses 0xFF80 7FF0 – 0xFF80 7FFF (last16 bytes of L1 Data Bank A) must be reserved. This memory range is used by the on-chip Boot
ROM to store header information of each block within the loader file. After booting, this memory
range can be used by the application during runtime. See Appendix for silicon revisions 0.1 and
0.2.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 9 of 28

a8-Bit Flash/PROM Boot (BMODE = 01)

Since the EBIU on the Blackfin processor is 16 bits wide (hence no ADDR[0]), an 8-bit flash/PROM will
occupy only the lower 8 bits of the data bus (D[7:0]). Figure 7 illustrates the pin-to-pin connections
between the Blackfin processor and an 8-bit flash/PROM:
ADSP-BF533

VDDEXT
8-Bit Flash/PROM
10KΩ_______
AMS(0)
____
AOE
____
AWE

____
AMS
___
OE__

___
R/W or WR

ADDR[N+1:1]

ADDR[N:0]

DATA[7:0]

DATA[7:0]

Figure 7. Connections Between a Blackfin Processor and an 8-Bit Flash/PROM

Listing 3 shows a loader file created for an 8-bit flash/PROM in Intel hex format (from example.zip
attached to this EE-Note). It is split into different sections to illustrate the loader file’s structure.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 10 of 28

aIntel Hex Overhead
ADDRESS of 10-Byte Header
COUNT of 10-Byte Header
FLAG of 10-Byte Header
DXE Count

10-Byte Header for Init Code DXE Count Block
Init Code DXE Count
10-Byte Header for Block 1 of Init Code DXE:020000040000FA
10-Byte Header for Block 2 of Init Code DXE:0A0000004080A0FF04000000120061:04000A005C00000096:20000E000000A0FF460000000200660167014005C00408E1180A48E1C0FF80E14A070097D7
Block 1 of Init Code DXE:20002E00240008E1140A48E1C0FF80E101000097240008E1100A48E1C0FF00E18D9940E16F:10004E009100009324008004000527012601100072
Block 2 of Init Code DXE:0C005E000000A0FF020000000A00660184:0A006A004080A0FF040000001200F7
10-Byte Header for DXE1 Count:0400740088020000FE:200078000000A0FF7E02000002808161113E08E1082048E1E0FF00E1D00040E1A0FF00927A:2000980000E1D20040E1A0FF0092009200E1F60040E1A0FF009200E1F80040E1A0FF00925D:2000B80000E1FA0040E1A0FF009200E1FC0040E1A0FF009200E1FE0040E1A0FF009200E1BA
DXE1 Count Block:2000D800000140E1A0FF009200E1020140E1A0FF009200E1040140E1A0FF009200E106015F
10-Byte Header for Block 1 of:2000F80040E1A0FF009200E1080140E1A0FF009200E10A0140E1A0FF00924EE1B0FF0EE14F:2001180000047E3208E1CC0148E1A0FF583E08E13C2048E1E0FF00E1C00040E1A0FF0092BF:2001380080E1008040009F0011007B0108E1CC0148E1A0FF50002000FF2F002008E13007FE:2001580048E1C0FF0095104A009708E1080748E1C0FF80E10000104A00923090709000200C:200178001100002000200020002000200020002000200020002080E1000081E10100A2E0D0:20019800062001900A90110801020850100008E1300748E1C0FF0095004A009708E10807FC:2001B80048E1C0FF80E10000004A009230907090002008E1300748E1C0FF0095084A00979C
Block 1 of DXE1
:2001D80008E1080748E1C0FF80E10000084A00923090709000200000000048E1C0FF08E131:2001F800040A00E1B07B40E1B07B0093240048E1C0FF08E1080A00E1B07B40E1B07B0093FC:20021800240048E1C0FF08E1000A0082796008560097240049E1272009E1040000600897F5:20023800240049E1272009E1060080E1FFFF0897240010000000FFE3D2FF08E1300748E1F3:20025800C0FF00E100000097240008E1340748E1C0FF00600097240008E1400748E1C0FFEC:20027800009501E1000F08560097240049E1272009E105000C9923E1C0001C55FB61AA6027:200298009A5494560A9B2400D243056000E3260008E1000748E1C0FF009521E10001485416:2002B800010C0318AA60056021E100024854010C0318FA61056021E100044854010C03183D:2002D8009A61056021E100084854010C0410050CD81BDF2F0D60DD2F0AE100004AE18003BB:0802F800A2E00220000010004A:00000001FF
Listing 3. Example Intel Hex Loader FileL

The loader file in Listing 3 was built for silicon revision 0.3. Loader files built for silicon revision
0.2 and below have a slightly different loader file structure.

When this loader file is programmed into an 8-bit flash connected to ASYNC Bank 0 of the Blackfin
processor, the contents of memory (starting at location 0x2000 0000) viewed from the Blackfin will look
like Figure 8.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 11 of 28

a0x20000000

xx

0x40

0x20000002

xx

0x00

0x20000004

xx

0x80

0x20000006xx

0x20000008

Data Data[15 : 8] [7 : 0]0x2000001C

xx

0x00

0x2000001E

xx

0x00

0x20000020

xx

0xA0

0xFF

0x20000022

xx

0xFF

xx

0x04

0x20000024

xx

0x46

0x2000000A

xx

0x00

0x20000026

xx

0x00

0x2000000C

xx

0x00

0x20000028

xx

0x00

0x2000000E

xx

0x00

0x2000002A

xx

0x00

0x20000010

xx

0x12

0x2000002C

xx

0x02

0x20000012

xx

0x00

0x2000002E

xx

0x00

0x20000014

xx

0x5C

0x20000030

xx

0x66

0x20000016

xx

0x00

0x20000032

xx

0x01

0x20000018

xx

0x00

0x20000034

xx

0x67

0x2000001A

xx

0x00

0x20000036

xx

0x01

…………….

……

……

ADDRESS

COUNT

FLAG

DXE Count
Block

ADDRESSADDRESS

Data Data[15 : 8] [7 : 0]

ADDRESS

COUNT

FLAG

Block 1 ofInit Code
DXE

Figure 8. 8-Bit Flash/PROM Memory Contents Viewed from Blackfin Memory Window

Figure 9 shows the start of a boot sequence for an 8-bit flash/PROM boot.

ADDRESS

COUNT

FLAG

10-Byte Header for Init Code DXE Count Block

Initial core byte read from location
0x0 of the flash to determine 8-bit
flash (0x40) or 16-bit flash (0x60).

Note that each read of an 8-bit flash
will have the data in the leastsignificant byte of the 16-bit bus.

Figure 9. Timing Diagram for 8-Bit Flash Boot Sequence

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 12 of 28

a16-Bit Flash/PROM Boot (BMODE = 01)

Figure 10 illustrates the pin-to-pin connections between the Blackfin processor and a 16-bit flash/PROM:
ADSP-BF533

VDDEXT
16-Bit Flash/PROM
10KΩ_______
AMS(0)
____
AOE
____
AWE

____
AMS
___
OE
__ ___
R/W or WR

ADDR[N+1:1]

ADDR[N:0]

DATA[15:0]

DATA[15:0]

Figure 10. Connections Between a Blackfin Processor and a 16-Bit Flash/PROM

If we create a loader file for a 16-bit flash/PROM from the example attached to this EE-Note, it will be
exactly the same as the one shown in Listing 3, except that the ADDRESS of the 10-byte header for the DXE
count blocks will be 0xFF80 0060 instead of 0xFF80 0040 as in the case of an 8-bit flash/PROM. This
will cause the first byte of the loader file to be 0x60 instead of 0x40. The on-chip Boot ROM uses thisfirst byte to determine whether an 8- or a 16-bit flash/PROM is connected. If the first byte is 0x60, it
assumes a 16-bit flash/PROM; if the first byte is 0x40, it assumes an 8-bit flash/PROM.
When this loader file is programmed into a 16-bit flash connected to ASYNC Bank 0 of the Blackfin
processor, the contents of memory (starting at location 0x2000 0000) viewed from the Blackfin processor
will look like Figure 11.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 13 of 28

aData Data[15 : 8] [7 : 0]0x20000000

0x00

0x60

0x20000002

0xFF

0x80

0x20000004

0x00

0x04

0x20000006

0x00

0x00

0x20000008

0x00

0x12

FLAG

0x2000000A

0x00

0x5C

DXE CountBlock0x2000000C

0x00

0x00

0x2000000E

0x00

0x00

0x20000010

0xFF

0xA0

0x20000012

0x00

0x46

0x20000014

0x00

0x00

0x20000016

0x00

0x02

0x20000018

0x01

0x66

…………….

……

……

0x2000005C

0x00

0x10

ADDRESSCOUNT

ADDRESSCOUNT
FLAG
Block 1 ofInit CodeDXE

ADDRESSADDRESS

Data Data[15 : 8] [7 : 0]0x2000005E

0x00

0x00

…………….

……

……

0x20000066

0x00

0x0A

0x20000068

0x01

0x66

0x2000002A

0x00

0x60

…………….

……

……

0x20000072

0x00

0x12

0x20000074

0x02

0x88

0x20000076

0x00

0x00

0x20000078

0x00

0x00

…………….

……

……

0x20000080

0x80

0x02

0x20000082

0x61

0x81

…………….

……

……

0x200002FE

0x00

0x10

10-ByteHeader for
Block 2 ofInit CodeBlock 2 ofInit Code
10-ByteHeader for
DXE1
Count
DXE1
Count
10-ByteHeader for
Block 1 of
DXE1Block 1 of
DXE1Figure 11. 16-Bit Flash/PROM Memory Contents Viewed from Blackfin Memory WindowL

The loader file structure (Figure 11) for a 16-bit flash/PROM is supported only by siliconrevision 0.3 and above. Silicon revision 0.2 and below of the ADSP-BF531/BF532/BF533
supports only 8-bit booting. Hence, if a width of 16 bits is chosen for silicon revision 0.2 andbelow, the output loader file will be zero-padded to “simulate” an 8-bit boot from a 16-bit
flash/PROM. This loader file, when programmed into flash/PROM memory, will look like
Figure 8 with zeros in the upper 8 bits (DATA[15:8]) of the data bus.

Figure 12 shows the start of a boot sequence for a 16-bit flash/PROM boot.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 14 of 28

aNote that each readof a 16-bit flash
will populate thefull 16-bit bus.

ADDRESS

COUNT

F.

10-Byte Header for Init CodeDXE Count Block

ADDRESS

COUNT

F.

10-Byte Header for Block 1 of Init
Code DXE

Block 1of Init
Code
DXE…
……..

Initial core byte read of flash
location 0x0 determines 8-bit flash(0x40) or 16-bit flash (0x60).
Figure 12. Timing Diagram for 16-bit Flash Boot SequenceL

The processor will perform an initial core byte read of location 0x0 of the flash to determine thememory width of the flash. When booting from a FIFO, the first byte (which is part of first 10-byteheader contained within the loader file) must be sent twice: once for this initial core read and once
for the actual boot sequence.

SPI Slave Mode Boot via Master Host (BMODE = 10)

For SPI slave mode booting, the ADSP-BF531/BF532/BF533 is configured as an SPI slave device and ahost is used to boot the processor.

L

This boot mode is not supported in silicon revision 0.2 and below of the ADSPBF531/BF532/BF533 processors.

Figure 13 shows the pin-to-pin connections needed for this mode. The host does not need any knowledgeof the loader file stream to boot the Blackfin processor. It must be configured to send one byte at a timefrom the loader file (ASCII format). In this setup, PFx is the host wait (HWAIT) signal from the Blackfin
processor to the master host device. This will be the signal used by the Blackfin processor to “hold off”
the host during certain times within the boot process (specifically during init code execution and zero-fillblocks). When PFx is asserted (high), the master host device must discontinue sending bytes to theBlackfin processor. When PFx is de-asserted (low), the master host device will resume sending bytes from
where it left off. Since the PFx pin is not driven by the slave until the first block has been processed,
consider using a resistor to pull down the HWAIT signal.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 15 of 28

a
ADSP-BF533(Slave SPI Device)
Host(Master SPI Device)
SPICLK_____
S_SEL

SPICLK
_____
SPISS

MOSI

MOSI

MISO

MISO

FLAG / Interrupt(HWAIT)

PFx
10KΩ
GND

Figure 13. Connections Between Host (SPI Master) and Blackfin Processor (SPI Slave)

L

The host must ensure that the Blackfin is out reset before sending any bytes. Any bytes sent to theBlackfin processor prior to reset will be lost and the booting sequence will fail.

This PFx number is going to be user-defined and will be embedded within the loader file. The elfloader
utility will embed this number in PFLAG bit field (bits[8:5] of the FLAG word) within every 10-byte header.
It does this by using the –pflag number command-line switch where number is the intended PFx flag
used by the Blackfin slave and has a value between 1 and 15.

L

If the –pflag number switch is not used, the default value placed within bits 8:5 of the FLAG will
be 0, indicating that PF0 will be assumed as the HWAIT signal to the host. Since PF0 is multiplexedwith the /SPISS pin, which is mandatory for successful SPI slave boot, always use the –pflag
switch and specify a value other than 0.

L

Due to an anomaly within the Rev 0.3 Boot Rom, the SPI Control and DMA5 Configuration
Registers will not have their default values after booting.

On a system where the Slave’s CCLK = 333 MHz, SCLK = 66.6 MHz, the Host was tested to have amaximum SPI Baud Rate = 1 MHz.
Attached to this EE-Note is an example host code (Host_Code.zip) for when an ADSP-BF532 processor
is used as the host.
Below are timing diagrams of a SPI Slave mode boot using an ADSP-BF532 processor as the host and an
ADSP-BF533 processor as the slave SPI device. On the host side, PF4 is used as the /CS which isconnected to the /SPISS of the slave ADSP-BF533. PF13 of the SPI slave (ADSP-BF533 processor) isconnected to PF15 of the host (ADSP-BF532 processor). This connection will be the HWAIT signal to holdoff the host. All the timing diagrams are from the SPI slave point of view.
The loader file used (SPI_Slave_HostFile.ldr) is the same one as in Listing 3, except two more blocks
are added to show the functionality of this boot mode: a zero-fill block going to location 0xFFA0 0300

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 16 of 28

awith a byte count of 0x4000 and a data block going to location 0xFFA0 4300 with the following values:
0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF, and 0x19.
Figure 14 shows the full SPI Slave mode boot sequence.
Full SPI Slave Mode Boot Sequence

Configuration of HWAIT(PF13) after first 10-byteheader is received.

Assertion of HWAIT(PF13) during Init Code
Execution.

Assertion of HWAIT(PF13) during Zero Fill
Block.

Figure 14. Timing Diagram for SPI Slave Mode Boot Sequence

After the SPI slave receives the first 10-byte header from the host, it knows which PFx flag to configure as
the HWAIT signal. In this case, we are using PF13. Note the de-assertion of PF13 in Figure 15 after bits 8:5of the FLAG field are processed.

L

For debug purposes, Figure 15 has been captured using a pull-up resistor on PF13. For normal
operation, a pull-down resistor is recommended, in which case PF13 would be low all the time.

0x40

0x80
0xA0
ADDRESS

0xFF

0x04

0x00

0x00
COUNT

0x00

0xB2

0x01
FLAG

10-Byte Header for Init Code DXE Count Block
Note the configuration of PF13 after
the first FLAG is received which has
the PF number stored in bits[8:5]

Figure 15. SPI Slave Mode Boot Sequence: Start of Boot Sequence

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 17 of 28

aAfter that, the host sends out the 4-byte Init Code DXE Count Block, the 10-byte header for Block 1 ofthe Init Code DXE, and then Block 1 itself.

0x5C 0x00 0x00 0x00 0x00 0x00 0xA0 0xFF 0x46 0x00 0x00 0x00 0xA2 0x01 0x66 0x01 0x67
ADDRESSCOUNT
FLAG

Init Code DXE Count

10-Byte Header for Block 1 of Init Code DXE

Block 1 of Init Code….

Figure 16. SPI Slave Mode Boot Sequence: Boot Block 1 of Init Code DXE

After the full Init Code DXE is booted into Blackfin memory, the slave SPI Blackfin processor will thenassert the HWAIT signal, PF13, to indicate to the host not to send any more bytes during Init Codeexecution. Since the Blackfin processor core is running much faster than the SPI interface, the Init Codewill execute at a much faster rate compared to the rate at which bytes are sent from the host.

0x00 0x00 0xA0 0xFF
ADDRESS

0x02 0x00 0x00 0x00 0xAA 0x01 0x66 0x01
COUNT
FLAG

10-Byte Header for Block 2 of Init Code DXE

Block 20x40 0x80 0xA0 0xFF
ADDRESS

10-Byte Header DXE1
Count Block…

Assertion of HWAIT (PF13) during shortduration of Init Code execution.

Figure 17. SPI Slave Mode Boot Sequence: Boot Block 2 of Init Code DXE

Figure 18 shows the processing of a zero-fill block for this boot mode. When the on-chip Boot ROM
encounters a zero-fill block, it asserts HWAIT, PF13, to hold off the host from sending any more bytes.
During this time, it MemDMAs 0x4000 zeros to locations 0xFFA0 0300 – 0xFFA0 4300. When done, theon-chip Boot ROM de-asserts HWAIT and the host continues to send the remaining bytes of the bootprocess (10-byte header for Block 3 and Block 3 itself).

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 18 of 28

aNote that the next byte of data will be sent by the host and it will sit
in the FIFO until HWAIT is de-asserted. In this case it is the first
byte (0x00) of the 10-Byte header for Block 3 of DXE1.

ADDRESS=0xFFA00300

COUNT=
0x00004000

FLAG
0x01A3

10-Byte Header for Block 2
of DXE1 (Zero Fill Block)Assertion of HWAIT (PF13) during zero-fill block processing.
Processor is zero-filling memory via MemDMA during this time.
Figure 18. SPI Slave Mode Boot Sequence: Boot Zero-Fill Block (Block 2 of DXE1)

10-Byte Header for
Block 3 of DXE1
(Last Block)

Block 3 of DXE1

Figure 19. SPI Slave Mode Boot Sequence: Boot Block 3 of DXE1 (Last Block)

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 19 of 28

a
SPI Master Mode Boot via an SPI Memory (BMODE = 11)

For SPI master mode booting, the ADSP-BF531/BF532/BF533 processor is configured as a SPI masterconnected to a SPI memory. The following shows the pin-to-pin connections needed for this mode.
VDDEXTADSP-BF533(Master SPI Device)
10KΩ

SPICLK

10KΩ

SPI Memory(Slave SPIPF2SPICLK
__
CS

MOSI

MOSI

MISO

MISO

Figure 20. Blackfin – SPI Memory Pin-to-Pin Connections

L

A pull-up resistor on MISO is required for this boot mode to work properly. For this reason, the
ADSP-BF531/BF532/BF533 processor reads a 0xFF on the MISO pin if the SPI memory is not
responding (i.e., no data written on the MISO pin by the SPI memory).

Although the pull-up resistor on the MISO line is mandatory, additional pulling resistors might also be
worthwhile as well: 1) Pull up the PF2 signal to ensure the SPI memory is not activated while the Blackfin
processor is in reset. 2) Pull down on the SPICLK for cleaner scope plots.

L

On silicon revision 0.2 and below, the CPHA and CPOL bits within the SPI Control (SPICTL) register
were both set to 1 (refer to the Hardware Reference Manual [2] for information on these bits). For
this reason, the SPI memory may detect an erroneous rising edge on the clock signal when it
recovers from three-state. If the boot process fails because of this situation, a pull-up resistor on
the SPICLK signal will alleviate the problem. On silicon revision 0.3, this was fixed by setting
CPHA = CPOL = 0 within the SPI Control register. Silicon revision 0.3 is robust against a pull-up
resistor on SPICLK. Therefore, boards that are populated with either silicon revisions can safely
pull SPICLK up. However, you may notice, if looking on a scope, that on silicon revision 0.3,
SPICLK goes unexpectedly high while PF2 is de-asserted.

The SPI memories supported by this interface are standard 8/16/24-bit addressable SPI memories (readsequence explained below) and the following Atmel SPI DataFlash devices: AT45DB041B,
AT45DB081B, AT45DB161B*.
* Attached to this EE-Note is example code that programs the Atmel DataFlash devices via an ADSP-BF532 Blackfin
processor (see Program_Atmel.zip).

Standard 8/16/24-bit addressable SPI memories are memories that take in a read command byte of 0x03
followed by one address byte (for 8-bit addressable SPI memories), two address bytes (for 16-bit

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 20 of 28

aaddressable SPI memories), or three address bytes (for 24-bit addressable SPI memories). After thecorrect read command and address are sent, the data stored in the memory at the selected address is shiftedout on the MISO pin. Data is sent out sequentially from that address with continuing clock pulses. Analog
Devices has tested the following standard SPI memory devices.


8-bit addressable SPI memory: 25LC040 from Microchip

16-bit addressable SPI memory: 25LC640 from Microchip

24-bit addressable SPI memory: M25P80 from STMicroelectronics

SPI Memory Detection Routine

Since BMODE = 11 supports booting from various SPI memories, the on-chip Boot ROM will detect what
type of memory is connected. To determine the type of memory (8-, 16-, or 24-bit addressable) connectedto the processor, the on-chip Boot ROM sends the following sequence of bytes to the SPI memory until
the memory responds back. The SPI memory does not respond back until it is properly addressed. The onchip Boot ROM does the following.
1. Sends the read command, 0x03, on the MOSI pin then does a dummy read of the MISO pin.
2. Sends an address byte, 0x00, on the MOSI pin then does a dummy read of the MISO pin.
3. Sends another byte, 0x00, on the MOSI pin and checks whether the incoming byte on the MISO pin isanything other than 0xFF (value from the pull-up resistor; refer to the following NOTE). An incoming
byte that is not 0xFF means that the SPI memory has responded back after one address byte and an 8bit addressable SPI memory device is assumed to be connected.
4. If the incoming byte is 0xFF, the on-chip Boot ROM sends another byte, 0x00, on the MOSI pin andchecks whether the incoming byte on the MISO pin is anything other than 0xFF. An incoming byte
other than 0xFF means that the SPI memory has responded back after two address bytes and a 16-bit
addressable SPI memory device is assumed to be connected.
5. If the incoming byte is 0xFF, the on-chip Boot ROM sends another byte, 0x00, on the MOSI pin andchecks whether the incoming byte on the MISO pin is anything other than 0xFF. An incoming byte
other than 0xFF means that the SPI memory has responded back after three address bytes and a 24-bit
addressable SPI memory device is assumed to be connected.
6. If an incoming byte is 0xFF (meaning no devices have responded back), the on-chip Boot ROM
assumes that one of the following Atmel DataFlash devices are connected: AT45DB041B,
AT45DB081B, or AT45DB161B. These DataFlash devices have a different read sequence than the
one described above for standard SPI memories. If you require more information, refer to data sheets[4], [5], and [6] for these devices. The on-chip Boot ROM determines which of the above Atmel
DataFlash memories are connected by reading the status register. The main difference between the
DataFlashes listed above is the number of bytes per page. The AT45DB041B and AT45DB081B have
264 bytes/page while the AT45DB161B has 528 bytes/page. To determine which one of these areconnected to the Blackfin, the on-chip Boot ROM reads the status register of the DataFlash whichcontain the device density bits. If the device density bits = 1011 (binary), the on-chip Boot ROM willassume an AT45DB161B is connected and address the part accordingly. Otherwise, it will assume an
AT45DB041B or AT45DB081B is connected and address it appropriately. Since the creation of thesilicon revision 0.3 on-chip Boot ROM code, Atmel introduced further derivatives of their

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 21 of 28

a
DataFlashes. If a user plans on using one of these other derivatives, they must make sure the devicehas 264 bytes per page otherwise, the boot sequence will fail.

L

For the SPI memory detection routine explained above, the on-chip Boot ROM in silicon revision
0.2 and below checks whether the incoming data on the MISO pin is 0x00 (first byte of the loaderfile). The on-chip Boot ROM in silicon revision 0.3 checks whether the incoming data on the MISO
pin is anything other than 0xFF. For this reason, SPI loader files built for silicon revision 0.2 andbelow must have the first byte as 0x00. For silicon revision 0.3, the first byte of the loader file isset to 0x40.

The SPI Baud Rate register is set to 133, which, when based on a 54 MHz system clock, results in a
54 MHz/(2*133) = 203 kHz baud rate. On the ADSP-BF533 EZ-KIT Lite board, the default system clock
frequency is 54 MHz.
The following diagrams show the boot sequence for a SPI Master mode boot using a 16-bit addressable
SPI memory (25LC640 from Microchip). The loader file used is the same as shown in Listing 3. All
figures are captured using silicon revision 0.3.
Figure 21 shows the full SPI Master mode boot sequence.
Full SPI Master Mode Boot Sequence

Note the de-assertion of the PF2 (/CS) line for each DMA sequence. The On-Chip Boot
ROM sets up a DMA sequence for each 10-Byte Header and each Block. These DMA
sequences are preceded by a core driven read command (0x03) and address byte(s).

Figure 21. Timing Diagram for SPI Master Mode Boot Sequence

Initially, the on-chip Boot ROM determines the SPI memory type connected: an 8/16/24-bit addressable
or an Atmel DataFlash.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 22 of 28

aStart ofbootsequence

DSP sends
out Read
Command(0x03)DSP sends
out 1staddress
byte(0x00)DSP sends out anotherbyte and the SPI memory
responds back with thebyte located at address
0x0 (value of 0x40)

DSP sends
out 2ndaddress
byte(0x00)

After this address byte issent out, a 16-bit
addressable SPI memoryis properly addressed andready to send back data.

SPI Memory Detection Routine
Figure 22. SPI Master Mode Boot Sequence: SPI Memory Detection Sequence

Note that Figure 22 has been captured using a silicon revision 0.3 part. On silicon revision 0.2, the SPICLK
will be high prior to and in between transfers.
The on-chip Boot ROM has detected that a 16-bit addressable SPI memory is connected at this point.
Next, it issues the read command and sends out address 0x0000 to read in the first 10-byte header for theInit Code DXE Count Block.

DSP sends out
read command,
0x03 and then 2
address bytes:
addr[15:8] first
and thenaddr[7:0].

0x40

0x80
0xA0
ADDRESS

0xFF

0x04

0x00
0x00
COUNT

0x00

0x12
0x00
FLAG

10-Byte Header for Init Code DXE Count Block

Figure 23. SPI Master Mode Boot Sequence: Boot 10-Byte Header for Init Code DXE Count Block

Since the Init Code DXE Count Block is a 4-byte ignore block, the on-chip Boot ROM will then issue theread command and send out address 0x000E for the 10-byte header for Block 1 of the Init Code DXE.
After this header is read in, the on-chip Boot ROM will know where Block 1 will reside in memory andhow many bytes to boot into that location.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 23 of 28

a

DSP sends out
read command,
0x03 and then 2
address bytes:
addr[15:8] =0x0, addr[7:0]= 0x0E

0x00

0x00
0xA0
ADDRESS

0xFF

0x46

0x00
0x00
COUNT

0x00

0x02
0x00
FLAG

10-Byte Header for Block 1 of Init Code DXE

Figure 24. SPI Master Mode Boot Sequence: Boot 10-Byte Header for Block 1 of Init Code DXE

Once this information is processed, the on-chip Boot ROM will again issue a read command and send out
address 0x0018 to boot in Block 1 of the Init Code DXE.

DSP sends out
read command,
0x03 and then2 address bytes:
addr[15:8] =0x0, addr[7:0]= 0x18

0x66

0x01

0x67

0x01

0x40

0x05

0xC0

0x04

0x08

0xE1

Block 1 of Init Code DXE…….

Figure 25. SPI Master Mode Boot Sequence: Boot Block 1 of Init Code DXE

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 24 of 28

aAppendix: Boot Modes vs. Silicon Revisions
The following boot mode options apply to all ADSP-BF531/BF532/BF533 derivatives.
Silicon Revision 0.1

1

BMODE[1:0]

Description

00

Executes from external 16-bit memory connected to ASYNC Bank0 (bypass Boot ROM)

01

Boots from 8/16-bit flash/PROM. (Only 8-bit boot supported)1

10

Boots from an 8-bit addressable SPI memory in SPI Master mode

11

Boots from a 16-bit addressable SPI memory in SPI Master mode

Only 8-bit boot is supported. A 16-bit flash will be zero-padded to “simulate” an 8-bit boot.

Table 2. Silicon Revision 0.1 Boot Modes

On Silicon revision 0.1, IGNORE and INIT Blocks are not supported.

L

Note that for Silicon Revision 0.1, addresses 0xFF90 0000 – 0xFF90 000F (first 16 bytes of L1
Data Bank B) must be reserved. This memory range is used by the on-chip boot ROM to store
header information of each block within the loader file. After booting, this memory range can beused by the application during runtime.

Silicon Revision 0.2

Silicon revision 0.2 introduced 24-bit SPI mode. An SPI device auto-detection enables 8/16/24-bit
memory devices to be covered by one BMODE configuration. Furthermore, silicon revision 0.2 introduced
the INIT code functionality.
BMODE[1:0]

Description

00

Executes from external 16-bit memory connected to ASYNC Bank0 (bypass Boot ROM)

01

Boots from 8/16-bit flash/PROM. (Only 8-bit boot supported). 1

10

Reserved

11

Boots from a 8/16/24-bit addressable SPI memory in SPI Master mode (pull-up required on MISO). 2, 3

Only 8-bit boot is supported. A 16-bit flash will be zero-padded to “simulate” an 8-bit boot.
Zero-fill blocks are not supported for SPI Master mode booting in silicon revision 0.2 due to an error in the on-chip Boot
ROM. Zeros must be included within the loader file for this mode.
3
The first byte of an SPI bootable loader file must be 0x00.
1
2

Table 3. Silicon Revision 0.2 Boot Modes

L

Note that for Silicon Revision 0.2, addresses 0xFF80 7FE0 – 0xFF80 7FFF (last 32 bytes of L1
Data Bank A) must be reserved. This memory range is used by the on-chip boot ROM to store
header information of each block within the loader file. After booting, this memory range can beused by the application during runtime.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 25 of 28

a

L

Notes

1, 2, 3

above are taken care of by the elfloader utility only if invoked in 0.2 mode (use the –si-revision 0.2 command-line switch), which is the default case in the current VisualDSP++
3.5 tools. This, however, will change in future tools releases when silicon revision 0.3 becomes
available.

Silicon Revision 0.3

Silicon revision 0.3 introduced SPI slave booting. SPI Master mode supports DataFlash devices from
Atmel in addition to standard 8/16/24-bit SPI memories. It also features true 16-bit flash/PROM mode.
The support for software reset has been cleaned up as well.
BMODE[1:0]

Description

00

Executes from external 16-bit memory connected to ASYNC Bank0 (bypass Boot
ROM)

01

Boots from 8/16-bit flash/PROM

10

Boots from an SPI host in SPI Slave mode

11

Boots from an 8/16/24-bit addressable SPI memory in SPI Master mode with support
for the following Atmel DataFlash devices: AT45DB041B, AT45DB081B, andAT45DB161B

Table 4. Silicon Revision 0.3 Boot Modes

L

Note that for Silicon Revision 0.3, addresses 0xFF80 7FF0 – 0xFF80 7FFF (last 16 bytes of L1
Data Bank A) must be reserved. This memory range is used by the on-chip boot ROM to store
header information of each block within the loader file. After booting, this memory range can beused by the application during runtime.

L

To enable silicon revision 0.3 features, the elfloader utility must be invoked in 0.3 mode (use the –si-revision 0.3 command-line switch). This will be the default case in future updates of theL

VisualDSP++ 3.5 tools, as soon as silicon revision 0.3 is available. The current version of theelfloader utility (pre-silicon revision 0.3) defaults to 0.2 mode, and should be called by the –sirevision 0.3 command-line switch for silicon revision 0.3 features.
The on-chip Boot ROM of silicon revision 0.3 is completely backward compatible with siliconrevision 0.2. Customers with silicon revisions 0.2 and 0.3 must invoke the elfloader utility withthe –si-revision 0.2 command-line switch.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 26 of 28

aAppendix: Blackfin Loader File Viewer
The Blackfin Loader File Viewer (LdrViewer) available from http://www.blackfin.org/tools) is avery useful utility that takes a loader file as an input and breaks it down and categorizes it into individual.DXE files and displays it as individual blocks with headers (ADDRESS, COUNT, and FLAG). This handy
utility can help you view a loader file’s content. When the file in Listing 3 is loaded into the LdrViewer,
the GUI contents will look like the following:

Figure 26. Blackfin Loader File Viewer Utility

Note that the LdrViewer utility is not part of the standard VisualDSP++ software toolset.

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 27 of 28

aReferences[1] VisualDSP++ 3.5 Loader Manual for 16-bit Processors. Rev 1.0, October 2003. Analog Devices, Inc.
[2] ASDP-BF533 Blackfin Processor Hardware Reference. Rev 3.3, September 2008. Analog Devices, Inc.
[3] Running Programs from Flash on ADSP-BF533 Blackfin Processors (EE-239). Rev 1, May 2004. Analog Devices Inc.
[4] AT45DB041B DataFlash Datasheet. April 2004. Atmel Inc.
[5] AT45DB081B DataFlash Datasheet. November 2003. Atmel Inc.
[6] AT45DB161B DataFlash Datasheet. November 2003. Atmel Inc.

Document History
Revision

Description

Rev 4 – September 29, 2008
by M. Kokaly-Bannourah•

Added informational bullet for Figure 15.

Rev 3 – January 11, 2005
by H. Desai•

Added informational bullets for reserved memory regions

Rev 2 – December 17, 2004
by H. Desai

•
•
•
•
•
•
•

Added pull-ups to the /AMS0 for all flash boot figures
Added a pull-up to PF2 in Figure 20
Described pull-up or pull-down on SPICLK in Figure 20
Specified maximum SPI Baud Rate for SPI Slave Mode Boot
Indicated that rev. 0.1 does not support IGNORE and INIT Blocks
Changed the term “feedback strobe” to host wait (HWAIT) signal
Added a discussion on Atmel DataFlash derivatives

Rev 1 – June 03, 2004
by H. Desai

Initial Release

ADSP-BF533 Blackfin® Booting Process (EE-240)

Page 28 of 28