Analog Devices EE146 Application Notes

Engineer To Engineer Note EE-146

Technical Notes on using Analog Devices' DSP components and development tools

Contact our technical support by phone: (800) ANALOG-D or e-mail: [e-mail]

a

Implementing a Boot Manager for ADSP-218x Family DSPs

Contributed by Benno Kusstatscher September 5, 2002

Or visit our on-line resources http://www.analog.com/dsp and http://www.analog.com/dsp/EZAnswers

Introduction

Conventional system design calls for a single
program to boot at power-up. One may
implement a more sophisticated approach to
build an application comprised of separate
programs, each booted into the DSP as needed,
under the control of a boot manager. One benefit
of such an approach is that the total memory
consumption of the application may far exceed
the on-chip memory resources provided by the
chosen ADSP-218x family DSP.

A boot manager is a piece of control code that
determines which program is booted after system
reset (e.g. by sampling one of input flag pins). A
boot manager may also help to boot a second
program after the first one has terminated. The
underlying technique remains the same.

If booted by a host processor through the IDMA
interface, the ADSP-218x behaves like a slave
and the host device has full control to reset and
reboot the DSP with different programs any time.

role. The following explanations are based on
VisualDSP++

TM

version 3.0 although the basic

functionality was introduced with version 2.0.

General Bootstrap Procedure

It is not an absolute must that one has an in-depth
understanding of the BDMA boot process to get
the boot manager up and running. Nevertheless it
helps to adapt the procedure described below to
slightly different requirements.

This application note discusses the scenario
where the ADSP-218x boots from an 8-bit
EPROM using its BDMA capability. All
programs are stored in the same EPROM the
DSP boots from and need to be managed
properly. It is obvious that the
loader/splitter1 utility elfspl21.exe plays a crucial

1

In this context the utility elfspl21.exe functions as a loader

utility, only. The name “Splitter” has historical nature for
usage on former ADSP-21xx devices that did not feature
BDMA booting yet.

Copyright 2002, 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 the technical accuracy and topicality of the content provided in all Analog Devices’ Engineer-to-Engineer Notes.

W

Figure 1: VisualDSP++ project property page

In order to boot any of the ADSP-218x family
DSPs from an 8-bit parallel EPROM or Flash
device, the VisualDSP++ Loader/Splitter utility

a

In response to this command, the elfspl21.exe
generates a boot stream from the linker’s
executable file
ELF/DWARF-2 standard; the output file will be

project1.bnm, encoded in the Intel Hex format. Let

us discuss the BDMA boot feature of the ADSP­218x family first in order to understand the
structure of the boot stream.

With BDMA booting enabled, after reset the
ADSP-218x DSPs do not immediately start to
fetch and execute instructions. First, the core is
halted and the BDMA engine automatically loads
the first 96 bytes from the BDMA space and
copies them into the internal SRAM at PM
address 0x0000. Once the BDMA transfer has
finished the DSP core starts to execute the 32
instructions built by these 96 bytes.

project1.dxe that meets the

Figure 2: VisualDSP++ load property page

needs to be invoked as shown in Figure 1. The
default settings within the load property page
(Figure 2) force VisualDSP++ to invoke the
splitter utility with the following command line
switches:

elfspl21 project1.dxe project1

-218x -loader -i

/* standard preloader (32 instructions) address opcodes */
ax0 = 0x0060; dm(0x3fe2) = ax0; /* BEAD */ /* 0x0000: 400600 93FE20 */
ax0 = 0x0020; dm(0x3fe1) = ax0; /* BIAD */ /* 0x0002: 400200 93FE10 */
ax0 = 0x0000; dm(0x3fe3) = ax0; /* CTRL */ /* 0x0004: 400000 93FE30 */
ax0 = 0x0087; dm(0x3fe4) = ax0; /* BWCOUNT */ /* 0x0006: 400870 93FE40 */
ifc = 0x0008; nop; /* BDMA IRQ */ /* 0x0008: 3C008C 000000 */
imask = 0x0008; /* 0x000A: 3C0083 */
idle; /* 0x000B: 028000 */
jump 0x0020; nop; nop; nop; /* 0x000C: 18020F 000000 ... */
nop; nop; nop; nop; /* 0x0010: 000000 000000 ... */
nop; nop; nop; nop; /* 0x0014: 000000 000000 ... */
nop; nop; nop; nop; /* 0x0018: 000000 000000 ... */
rti; nop; nop; nop; /* 0x001C: 0A001F 000000 ... */

Of course, most applications are much larger
than 32 instructions. 32 instructions are not
sufficient to boot real applications, either.
Therefore, this first piece of program is used to
implement a bootstrap scenario only. We shall
refer to this as the “preloader”. Listing 1 shows
the preloader that is used by default.

Listing 1: Default preloader used by elfspl21.exe

Implementing a Boot Manager for ADSP-218x Family DSPs (EE-146) Page 2 of 8

a

Basically, the preloader just sets up another
BDMA sequence that loads additional loader
code from byte address 0x0060 to PM address
0x0020. An IDLE instruction stops the program
execution until the BDMA has finished. The
unmasked BDMA Interrupt brings the core out of
the idle state afterward. Please note the RTI
instruction at BDMA interrupt vector address
0x001C.

Once the BDMA transfer has finished, the code
execution continues at the address subsequent to
the IDLE instruction. The program jumps to
0x0020, where the recently loaded instructions
have been placed. This is the first PM location
after the BDMA interrupt vector.

This second part of the bootstrap loader is
conventionally called “page loader”. It boots the
final application data. The

elfspl21.exe tool

generates this page loader content dynamically.

0x000000

0x000060

0x0001F5

Figure 3: EPROM memory map example

Preloader

32 Instructions

Page Loader

135 Instructions

Application Data

Basically, the page loader consists of a set of
BDMA setup sequences, one for every hardware
page that needs to be booted. Such a setup
sequence takes nine instructions; the last one is
the IDLE instruction, required to halt program
execution. Please note that the RTI instruction at
address 0x001C is still required.

The final BDMA transfer loads the fixed PM
page (PM 0x0000 to 0x1FFF). It overwrites both,
preloader and page loader. Therefore the final
BDMA setup does not use the IDLE instruction,
but sets the BCR (BDMA Context Reset) bit of
the BDMA control register. This forces the DSP
to halt the program execution until the BDMA
transfer has finished and to jump to PM address
0x0000 afterward. Then, it immediately starts to
execute the booted application.

VisualDSP++TM 2.0 versus 3.0

Beside minor bug fixes the elfspl21.exe utility of
VisualDSP++ 3.0 is the same as the one of the

2.0 release – with one exception: VisualDSP++

3.0 supports booting of off-chip DM and PM
overlay pages, while VisualDSP++ 2.0 does not.
This new feature results in some impacts we
need to be aware of.

VisualDSP++ 2.0 fixes the number of page
loader instructions to 135, providing space for up
to 15 BDMA setup sequences. This is sufficient
to boot all on-chip overlay pages of ADSP-2188
devices. Unused page loader instructions are
simply filled with NOP instructions. The
preloader’s BWCOUNT value is always 135
(=87h) as shown in Listing 1 and Figure 3.

VisualDSP++ 3.0 can boot off-chip SRAM.
Since the hardware does not support BDMA
transfers directly to off-chip DM and PM
memories, additional instructions are required to
copy boot data from intermediate internal storage
to off-chip overlay memory. Therefore the page
loader of VisualDSP++ 3.0 may exceed these
135 instructions. The number of instructions may
vary and the default preloader’s BWCOUNT
value is calculated dynamically by
the

–uload switch is used to replace default

preloader, the user has no access to the real
length of the page loader. The BWCOUNT
register needs to be filled with a constant value
that mirrors the maximal possible page loader
length. This worst-case length depends on the
application. Actually, the maximal length

elfspl21.exe. If

Implementing a Boot Manager for ADSP-218x Family DSPs (EE-146) Page 3 of 8