Analog Devices EE180 Application Notes

Engineer To Engineer Note EE-180

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

Using Code Overlays from ROM on the ADSP- 21161N EZ-KIT Lite

Contributed by C.Lam December 5, 2002

Introduction

Software overlays are very useful in systems that
have tight memory constraints. In the case where
internal memory is limited and adding external
RAM significantly increases cost, importing
overlays from the boot ROM provides a feasible
and relatively simple solution.

One of the main obstacles in accomplishing this
is to determine the residing location of the
overlay(s) in the ROM. Currently, the
VisualDSP++ 2.0 linker does not provide this
support. Therefore, the first of the three main
parts of this application runs through the boot
image in the ROM to decipher which sections of
code are part of an overlay. After all the overlay
sections are located, the second main routine
parses all the information collected by
previously. Finally, the third main routine, the
overlay manager, is responsible for importing the
correct overlay when called.

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

whether each section of code belong to an
overlay. Parsing of this collected information is
handled in the next section. There are two main
routines in this file:

• Read boot info from PROM.

• Check the boot info that was read.

The read_boot_info routine simply reads from
the PROM and places three pieces of information
into registers R0, R2, and R3. The tag info is
placed in R0, and it identifies what type of data
or code this section consists. The internal count
info, placed in R2, holds the number of words
this section takes up in internal memory. R3
holds the destination address info. This is the
address at which the overlay has been defined to
reside in (also known as live address). However,
since we are not having the overlays reside in
internal memory, the address generated by the
linker and held in R3 will only be a “dummy”
address.

Listing 1. Example memory definition of

“dummy address”

MEMORY

{

Locating Overlay Information

The code that locates the overlay information is

memsdram { TYPE(PM RAM) START(0x00600000)

END(0x006FFFFF) WIDTH(48) }

}

implemented in the file Ovl_Init.asm. Its
objective is to run through the PROM to check

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.

a

In the example shown in Listing 1 above, the
linker would generate an address in the range of
0x600000 to 0x6FFFFF for overlays defined in
the memsdram section.

Knowing that all of our overlays are placed in
this “dummy” location in the range of 0x600000
to 0x6FFFFF, we can check R3 each time after
we read the boot info for a value within this
range. When we find a section with a destination
address in this range, we then know that it
belongs to an overlay. This is done in the
check_routine portion of the Ovl_Init.asm file.

Whenever an overlay section is discovered, three
pieces of information are written into designated
buffers:

• the “real” live address that the overlay
resides in ROM,

• the section count size from R2, and

• the section data or code type from R0.

In addition to determining whether a section
belongs in an overlay, the check_routine code
also has to know how much to increment by to
read the next section’s information.

Figure 1. Illustration of info in PROM

0x4200E2E

0x4200E3A
0x4200E52

Tag = 0x15
Count = 0x4
Address = 0x60003C
...Code begins at 0x4200E3A…
Tag = 0x19
Count = 0x14

Figure 1 above shows an example illustration of
three sections’ info in the PROM. For this
example, after the first time the check_routine is
initiated, we will know 4 pieces of information:

• R0 = 0x15 (Section Type)

• R2 = 0xA (Section size)

• R3 = 0x60003C (Section live address)

• Current PROM address = 0x4200E2E

The current PROM address can be read from the
External Memory DMA Index register (EIEP0).
We see that the value in R3 corresponds to the
“dummy” live address that we’ve assigned to
overlays; therefore, we know that this particular
section belongs to an overlay. By checking the
type info in R0, we know that this section
contains code. Therefore, accounting for the
space that the tag, count, and address info takes
up in the PROM (0xC locations), we know that
code begins at 0x4200E3A (0x4200E2E + 0xC).
At this point, we record the type (R0) in the
total_sec_type buffer, size (R2) in the
total_sec_size buffer, and “real” live address
(0x4200E3A) into the total_live_addr buffer.

To read the next section’s info, the check_rout ine
increments the EIEP0 to 0x4200E52. It
calculates this address by using this formula:

(Addr. of code) + (size of code)(6)

Six 8-bit locations in the PROM make up one
internal 48-bit instruction. The size of the code
(read into R2) is the internal word size.
Therefore to find the section size in the PROM,
we multiply the internal word size by 6. Adding
this to the beginning address of the code, we get
the next section’s starting location in the PROM.

0x4200E5E

0x4200E6A

Using Code Overlays from ROM on the ADSP-21161N EZ-KIT Lite (EE-180) Page 2 of 9

Address = 0x600044
Tag = 0x15
Count = 0x8
Address = 0x60006C
...Code begins at 0x4200E6A…

Example 1. Locating the next section’s
address from a code type

Type = 0x15 (Code)
Code begins at 0x4200E3A

Internal size of code = 0xA

a

(0x4200E3A) + (0x4)(6) = 0x4200E52
To accurately locate the address of the next

section’s info, the section type must be correctly
interpreted. For the example shown in Figure 1,
the section tag beginning at address 0x4200E52
is 0x19 and the count is 0x14. This tag indicates
a zero type, and the count indicates an internal
word size of 0x14. This is an equivalent of 0x78
8-bit locations in the PROM. However, for zero
types, the loader does not generate all the zeros
and fill up the PROM with zeros. This would be
a waste of valuable space. Instead, only the tag,
count, and live address are provided. Later in the
discussion of the overlay manager, we will
discuss how to handle the zero type sections. For
the purpose of the check_routine now, we only
need to know that for zero type sections, we find
the next section’s address by simply adding 0xC
to the current PROM address (to account for the
space that the tag, count, and address info takes
up in the PROM).

• account for the overlay id
information that’s embedded in the
loader file

To check how many sections are in each overlay,
we compare the individual section sizes to the
entire overlay size. In the check_routine of the
previous file, we placed all the section sizes into
the total_sec_size buffer. At run time, the linker
also generates constants with each overlay’s total
run size. Therefore, by comparing the individual
section size to the entire overlay size, we can find
out how many sections are in each overlay. This
information is stored in the num_ovl_sec buffer.

When the loader file is created, th e overlay id is
embedded after the tag, count, and address info.
For overlays with multiple sections, the overlay
id is embedded only once, after the overlay’s first
set of tag, count, and address info. Figure 2
illustrates this.

Example 2. Locating the next section’s
address from a zero type

Type = 0x19 (Zero)

Section info begins at 0x4200E52

(0x4200E52) + (0xC) = 0x4200E5E

The Ovl_Init.asm file checks every sections’ info
until it reaches a tag of 0x0, which indicates that
there are no more sections.

Parsing Overlay Information

Now that all the overlay sections’ information
have been collected, the Ovl_Sec_Info.asm file
parses it to determine:

• the number of section types in each
overlay

Figure 2. Illustration of overlay id
embedded in section info in PROM

Ovl 1, Sec. 1 0x4200DDA

0x4200DE6

0x4200DEC

Ovl. 1, Sec. 2 0x4200E22

0x4200E2E
Ovl. 2, Sec. 1

Tag
Count
Address
Overlay ID 1
….. Code …..
Tag
Count
Address
….. Code …..
Tag
Count
Address
Overlay ID 2

Using Code Overlays from ROM on the ADSP-21161N EZ-KIT Lite (EE-180) Page 3 of 9