Analog Devices EE239v01 Application Notes

Engineer-to-Engineer Note EE-239

a

Technical notes on using Analog Devices DSPs, processors and development tools

Contact our technical support at [e-mail] and at [e-mail]
Or vi sit our o n-li ne r esou rces htt p:/ /www.analog.com/ee-notes and http://www.analog.com/processors

Running Programs from Flash on ADSP-BF533 Blackfin® Processors

Contributed by Steve K Rev 1 – May 22, 2004

Introduction

This document describes the process of setting up an application to run on the ADSP-BF533 Blackfin®
processor via flash memory, instead of being loaded from VisualDSP++® 3.5 via an emulator. It uses the
ADSP-BF533 EZ-KIT Lite™ evaluation system as an example board.

Minimum requirements:

• VisualDSP++ 3.5 (base release or Update)

• ADSP-BF533 Blackfin processor, silicon revision 0.2 or higher

The EZ-KIT Lite example program “Blink” is used to demonstrate the procedures. It can be found in the

..\Blackfin\EZ-Kits\ADSP-BF533\Examples\Blink\C directory within the VisualDSP++ installation.

The document considers two approaches:

• Running the program via the ADSP-BF533 Blackfin processor boot ROM

• Running the program directly from flash memory, via bypass mode

Initial Steps: Running Under the Emulator

Begin by coping the Blink example from the VisualDSP++ installation to a new working directory, and
build it to verify that it works, as follows:

1. Copy the

2. Start VisualDSP++.

3. Use

4. Rebuild all.

5. Load the program into the ADSP-BF533 EZ-KIT Lite board (via an in-circuit emulator or USB agent)

and run it.

6. Observe the six LEDs, blinking on and off in sequence.
This program is running entirely from internal L1 memory, using L1 Instruction memory and L1 Data A

and L1 Data B memory. No caches are enabled. SDRAM is not used.

..\Blackfin\EZ-Kits\ADSP-BF533\Examples\Blink\C directory to a new location.

Project->Open to open BF533 Flags C.dpj in the new location.

In the

Copyright 2004, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of
customers’ products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property
of 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.

ISRs.c file, Timer0_ISR()uses the code shown in Listing 1 to generate the blinking sequence.

if(sLight_Move_Direction)
{
if((ucActive_LED = ucActive_LED >> 1) == 0x00) ucActive_LED = 0x20;
}
else
{
if((ucActive_LED = ucActive_LED << 1) == 0x40) ucActive_LED = 0x01;
}

Listing 1. LED sequence in Blink application

a

While following the various stages of this document, you may find it helpful to modify this piece of code
to produce different sequences. This will help verify that on power-up your EZ-KIT Lite board is now
running a newly modified program. Listing 2 shows suggested alternative sequences.

if (++ucActive_LED == 0x40)
ucActive_LED = 1; // alternative 1: count up

if (ucActive_LED-- == 0)
ucActive_LED = 0x40; // alternative 2: count down

Listing 2. Suggested alternative LED sequences

Booting from Flash Devices

ADSP-BF533 Blackfin processors feature an on-chip boot ROM that contains a boot kernel. If the
BMODE pins are programmed in “boot from flash” mode, the kernel processes a boot stream stored in the
flash memory and decomposes it into blocks of code and data. These blocks are copied to RAM areas
within the memory space. The boot stream is created by the loader utility after building a
contained within a loader file that must be programmed into the flash memory. After the boot kernel has
copied the blocks to their respective destinations, the kernel jumps to the start of L1 Instruction memory
and starts executing from there. Consequently, all code and data have been copied to their final
destinations before the application code starts running.

Creating a Boot Stream

1. In Project->Project Options, on the Project tab, under Target, change Type to DSP loader file.

2. On the

3. On the

4. On the

Load tab, set Boot mode to Flash and set Output width to 16-bit.
Load tab under Boot kernel options, clear the Use boot kernel option.
Load tab under ROM splitter options, ensure that Enable ROM splitter is not selected.

5. Close the Project Options dialog box.

6. Save project changes via

Project->Save.

7. Rebuild the project.

.DXE file, and is

When the project is rebuilt (after creating
Elfloader utility to generate the boot stream from this

Debug\BF533 Flags C.dxe), VisualDSP++ will invoke the

.DXE file. The boot stream will be created in the

loader file Debug\BF533 Flags C.ldr.

Running Programs from Flash on ADSP-BF533 Blackfin® Processors (EE-239) Page 2 of 14

Programming the Boot Stream into the EZ-KIT Lite Board

1. Select Tools->Flash Programmer. The Flash Programmer window opens.

a

2. In the

Lite\BF533EZFLASH.DXE

3. Click on

4. In the

5. Click on

Driver File field, browse to the file …\Blackfin\Flash Programmer Drivers\ADSP-BF533 EZ-kit

.

Load Driver. The Status circle will change from red to yellow and then to green.

Data File field, browse to the file Debug\BF533 Flags C.ldr in your project.

Load File. The boot stream from the loader file will be programmed into the EZ-KIT Lite

board’s flash memory.

6. Exit the Flash Programmer.

7. Exit VisualDSP++.

8. Power-cycle the EZ-KIT Lite board. Observe the LEDs blinking on power-up.

Using the Boot Kernel and SDRAM

If any of the application is mapped to SDRAM – such as if the USE_CACHE option of the standard .LDF files
is employed – the SDRAM will need to be initialized before the boot kernel can copy a block from the
boot stream into SDRAM. This can be achieved through the use of initialization blocks.

The loader utility can be given an initialization file. This is a .

BF533_ASM.ldf

file. The loader utility extracts the executable code section (program section), and inserts it

DXE file built for the target using the ADSP-

into the boot stream with a special marker. The marker indicates to the boot kernel that it should execute
the code within the block immediately after copying it. Thus, the block can be used to set up SDRAM
before application components are copied into it.

The initialization object file must contain code that operates like a function that considers all registers to
be callee-preserved; it must save and restore all the registers it uses. Since this initialization code is called
like a function, it must terminate with an

RTS instruction. The boot kernel will provide sufficient stack

space within the L1 scratchpad memory.
For an example of an initialization file, refer to Listing 2-1 in VisualDSP++ 3.5 Loader Manual for 16-bit

Processors [1].

Running from Flash via Bypass Mode

When the ADSP-BF533 Blackfin processor detects that it is being configured in bypass mode at reset, it
does not process a boot stream. Instead, it bypasses the boot ROM, jumps to the start address of flash
memory, and starts execution directly. This means that the application code is being executed from within
flash, rather than being copied to RAM and then being executed from there.

In this mode, any code or data that should be in the L1 Instruction, L1 Data A, or L1 Data B memories has
not yet been copied when control is passed to the application. Generally, the application will at least need
to initialize data items to their starting values before modifying them during the course of the application.

Data sections can be initialized in an automated fashion by using initialization qualifiers within the .
file and by enabling memory-initialization during linking. When this is done, the final

Running Programs from Flash on ADSP-BF533 Blackfin® Processors (EE-239) Page 3 of 14

.DXE file will

LDF

a

contain a data table similar to the boot stream produced by the loader utility for booting via the boot
ROM. The table is described in the Memory Initializer Boot Stream section.

Processing the Data Stream in Assembly Applications

The run-time libraries contain a routine for processing this table that the assembly programmer can call to
cause the initialization. The function is called

_mi_initialize (one leading underscore, from assembly). It

takes no parameters and returns an integer result. Zero means successful initialization, and a negative
value means that the table was invalid.

Alternatively, the assembly programmer could process the table directly. The table is pointed to by the
global variable
pointer (points to
linking, the

___inits (three leading underscores). This symbol is a pointer, and is normally a NULL

0x0000 0000). If the .DXE file has been processed for run-time initialization during

___inits symbol will be modified to point to the start of the table. See the Memory Initializer

Boot Stream section for details on the format of the table.

Processing the Data Stream in C/C++ Applications

The C/C++ developer does not need to call the run-time function mi_initialize (no leading underscores,
from C/C++) explicitly; the start-up code for the C/C++ run-time calls
before invoking

main.

mi_initialize automatically

Limitations of mi_initialize

At the time of this writing, the run-time initialization support has two limitations:

• It does not support writing to L1 Instruction memory. Therefore, it cannot be used to copy code from

flash into L1 Instruction memory.

• It does not provide any means of invoking initialization code for SDRAM. Therefore, it cannot be

used to copy code or data from flash into SDRAM, unless some other means is used to enable
SDRAM before the memory initialization process runs.

An assembly developer can avoid these limitations by processing the data table directly. A C/C++
developer can avoid these limitations by providing an alternative implementation of

mi_initialize.

The “Blink” application does not use SDRAM, so the second limitation does not pose a problem for the
examples in this document. To deal with the first limitation within the scope of this document, the “Blink”
application will be linked so that its code runs entirely from flash memory.

Creating a Flash-Based Application

Creating a flash-based application is a two-stage process. First, a customized .LDF file is needed to re-map
the application code and arrange for data initialization. Then the project must be configured to generate a
no-boot flash image.

Creating the Flash-Based .LDF File

The “Blink” application does not have an .LDF file of its own; it uses the default compiler .LDF files.
Therefore, begin by creating an .

Running Programs from Flash on ADSP-BF533 Blackfin® Processors (EE-239) Page 4 of 14

LDF file for the project, as follows:

1. Select Tools->Expert Linker->Create LDF… Click on Next.

a

2. Select the

C project type. Click Next.

3. This is a single-processor ADSP-BF533 session, so the defaults presented on the next dialog suffice.

Click

Next.

4. Click

Finish.

5. The Expert Linker will open its graphical editor. Close it.

6. Right-click the

Placing Code Sections in Flash

BF533 Flags C.ldf file in the Project window and select Open with Source Window.

The .LDF file has to be changed to reflect that code will be mapped into the flash areas. This requires the
following changes:

• Map section

• Map section

program_ram to MEM_ASYNC0 (instead of MEM_L1_CODE).
l1_code to MEM_ASYNC0 (instead of MEM_L1_CODE_CACHE).

Because the code is mapped to flash, it will be executable directly from the flash memory.

Placing Data in Flash or RAM

Constant Data

For constant data, there are two options: the data can be mapped directly to flash memory because it is
unchanging, or it can be mapped to RAM and initialized at run-time. The former saves space, but the latter
runs faster. This is an application-level decision.

In this example, we consider the

constdata input section to be constant data that nevertheless might be

frequently accessed by the application (e.g., FIR coefficients). Therefore, we will map these input sections
into RAM for initialization at runtime. But the compiler also generates a number of tables that are used for
C++ constructor and exception support, and those are unlikely to be referenced often, so we will map
them directly into flash memory.

This is a convenient decision for this example, because

constdata is a misnomer for the output section in

the default .LDF files: it also maps input sections L1_data_a, cplb_data, data1, and voldata, which are not
constant. If we were to resolve

constdata into flash memory, we would have to ensure that these other

input sections are separately mapped elsewhere in RAM.
We separate the

mapped into the former, in
.

frtl are mapped into the latter, in MEM_ASYNC0.

Furthermore, because the
with a

RUNTIME_INIT initialization qualifier. This is used during link-time, when the run-time initialization

constdata output section into constdata and cplustables; the constdata input section is

MEM_L1_DATA_A, and the sections ctor, ctorl, .gdt, .gdtl, .edt, .cht, .frt, and

constdata section needs to be processed at runtime to initialize it, we mark it

is configured, to indicate that the section has data that needs to be saved into ROM and copied into RAM
at run-time.

The two modified sections from the .

LDF file are shown in Listing 3.

Running Programs from Flash on ADSP-BF533 Blackfin® Processors (EE-239) Page 5 of 14