Engineer-to-Engineer Note

EE-351

Technical 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.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM
Contributed by Andy Kettler

Rev 2 – March 16, 2011

relies on to provide run-time services for thecode that it generates (such as emulation of
floating-point arithmetic that is not supportedby the hardware instruction set).

Introduction
The ADSP-BF592 Blackfin® processor provides
fast, low latency on-chip memory that includes
64K bytes of L1 instruction ROM, 32K bytes of
L1 instruction SRAM, and 32K bytes of L1 data
SRAM. The processor has no L2 internal
memory, and it does not provide an external
memory interface (L3 memory). Therefore anapplication might be constrained by theavailability of L1 instruction SRAM. One way toaddress this would be to take advantage of the
on-chip Tools Utility ROM.
This EE-Note describes the Tools Utility ROM, it
explains how to use it, and the implications
involved. Also, this document assumes thatapplications are built using the VisualDSP++®
5.0 development tools (Update 9 or later
revisions).

For compatibility with the previous
release of the product, the VisualDSP++
development tools refer to the ADSPBF592 processor as the ADSP-BF592-A
processor.

Overview
The Tools Utility ROM is available with the
ADSP-BF592 processor (in all silicon revisions
except revision 0.0) and uses its 64K bytes of L1
instruction ROM to provide:Compiler support functions, which are hidden
routines that the compiler knows about andA set of C and DSP run-time library functions
including, for example, functions fromstring.h and math.h, matrix manipulation
functions, and filter and FFT functions.
Appendix A has a detailed description of thecontents of the ROM.

The core of the VisualDSP++ Kernel (VDK)
referred to here as TMK.

Benefits of Using the Tools Utility ROM
The basic memory layout of the ADSP-BF592
processor is:
L1 instruction SRAM 32K bytes
L1 instruction ROM 64K bytes
L1 data SRAM
32K bytes
L1 scratchpad SRAM 4K bytes
There is no support for external memory, and so
exploiting the Tools Utility ROM may overcome
shortages in L1 instruction SRAM (refer to thefollowing section which describes the ROM’s L1
data SRAM requirements). For example, thelinker knows that the Tools Utility ROM contains
a copy of the C library function strcmp. So if anapplication calls that function then all the linker
has to do is to redirect all appropriate references
to where the strcmp function is located in theROM. Should an application decide not to link

Copyright 2010-2011, 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 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.

against the contents of the Tools Utility ROM,
then the linker would have to map the librarydefined version of strcmp into L1 instruction
SRAM, thus increasing the memory footprint of
the application.
Clearly the extent to which an application may
benefit from using the ROM will depend on how
much of the code in the ROM it can exploit.
However, most C and C++ based applications
will rely on compiler suppo rt functions, and all
multi-threaded applications that use VDK will
require the VDK core.

Drawbacks of Using the Tools
Utility ROM
It is important to note that there is an L1 data
SRAM overhead that must be accepted if anapplication is linked against the contents of theTools Utility ROM. This overhead amounts to
3.6K bytes of L1 data SRAM that is
automatically reserved for the VDK core andlibrary functions in the ROM by the default .LDF
files and by any .LDF file that is generated by the
IDDE. The overhead can be avoided by not using
the Tools Utility ROM when linking anapplication – this is described in the section
Linking with the Tools Utility ROM.
The reserved L1 data memory is set aside forstatic data used by the VDK core and forconstant data for some of the run-time libraryfunctions. For revisions 0.1 and 0.2 of the ADSPBF592 processor, this data is mapped between
the memory addresses 0xFF800000 and
0xFF800E40.
The Tools Utility ROM was built withcomponents from VisualDSP++ 5.0 Update 8,
and so improvements made to the libraryfunctions in later VisualDSP++ versions (such as
to the performance and accuracy of the default
singleprecision
floating-pointemulationfunctions) will not be available if linking against
the Tools Utility ROM.

Contents of the Tools Utility ROM
This list summarizes the contents of the ADSPBF592 Tools Utility ROM (for silicon revisions
0.1 and 0.2); refer to Appendix A  Contents of
the ADSP-592 Tools Utility ROM for a more
complete reference:The VDK core that uses (approximately)
2.8K bytes of instruction memoryHigh-speed single and double precision
floating-point emulation library (-fast-fp)

Compiler support functions

Core DSP algorithms (FFTs, filters for types_Fract and fract16)



Other DSP algorithms (vector, matrix, andstatistical functions for the _Fract,
fract16, and floating-point data types)



Functions from math.h for the _Fract,
fract16, and floating-point data types



Functions to support the 16-bit based
fractional complex types, and the single
precision and double precision floating-pointcomplex types (complex.h)Selection of ETSI functions

C run-time functions declared in string.h except for strtok and string functions that
rely on the current locale

setjmp, longjmp (setjmp.h)clip, countones,(stdlib.h)

max,

min,

and div

The following is a summary of what is notincluded in the Tools Utility ROM:

I/O library (stdio.h)Fully IEEE-compliant single and double
precision floating point emulation suppo rt(enabled by the compiler switch -ieee-fp)

Window generators for the fractional datatypes (window.h)

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 2 of 11

Twiddle table generators for the fractional
data types (filter.h)Silicon
Revision

Link with theROM

Don’t Link with theROM

Support for date and time (time.h)

any

N/A

default

Wide character support

none

N/A

defaultHeap management functions (such as malloc,
free)

0.0

N/A

default

0.1-utility-rom

default

Locale control (locale.h)

0.2

default-no-utility-rom

qsort, bsearch

DSP algorithms for the long _Fract andfract32 data typesC++ libraries



Middleware

The functions in the Tools Utility ROM containall the workarounds for silicon anomalies that areavailable with VisualDSP++ 5.0 Update 9, withthe exception that the support for the VDK coredoes not have a workaround for silicon errata
05000494[3]: “EXCPT Instruction May Be Lost If
NMI Happens Simultaneously”. Note that thisanomaly applies to all current Blackfin parts andrevisions; check the most recent silicon Anomaly
List for your part:
http://www.analog.com/en/embeddedprocessing-dsp/blackfin/processors/icanomalies/resources/index.html

All the run-time library functions within the Tools
Utility ROM are re-entrant - that is, they areinterruptible and they may also be used in a multithreaded environment.

Table 1. Linking with the Tools Utility ROM

If no silicon revision is specified, then the
VisualDSP++ tools will assume a default siliconrevision based on the current processor, which
for VisualDSP++ 5.0 Update 9 and an ADSPBF592 processor is silicon revision 0.1 (todiscover the default silicon revision for yourversion of VisualDSP++, open up the file ADSPBF592-A-compiler.xml that is located under
your VisualDSP++ installation in the subdirectory System\ArchDef).
Table 1 shows that when using silicon revision
0.2, the default is to link against the Tools Utility
ROM and for all earlier revisions the default is toignore the ROM. The default action can beoverridden provided that the silicon revision is
not one of any or none or 0.0
The compiler driver ccblkfn supports two
switches that can be used to override (or confirm)
the default action. These switches are:

-utility-rom

-no-utility-rom

Linking with the Tools Utility
ROM

As expected, the switch -utility-rom specifies
that the linker should make use of the Tools
Utility ROM; and you can avoid linking against
the ROM by using the switch -no-utility-rom.

Unless specified otherwise, linking against theTools Utility ROM is controlled by the siliconrevision as shown in Table 1.

If an application is built via the IDDE's project
management system then you can control the useof the Tools Utility ROM via the project options.


Navigate to the page Project Options ->Link -> Processor (2)

The page contains a Tools Utility ROM
area with three alternative buttons:

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 3 of 11

Automatic
revision)

Enabled

Disabled(basedonsiliconinformation for the Enabled button says “Linkyour application against the Tools Utility ROM.
Equivalent to the compiler’s -utility-rom
command-line switch.”

If you click on each button and then use Help
(SHIFT+F1), you will get a brief explanation ofwhat the button does. For example, the Help

Figure 1 shows the Link -> Processor (2)page.

Figure 1. Screenshot of the Link -> Processor (2) Project Options page

Modifying a Customized LDF
This section describes the changes required to acustomized .LDF file if you want your application
to link against the contents of the Tools UtilityROM. The changes required are:

The customized LDF must define the default
memory section name MEM_L1_DATA to cover

the available L1 data SRAM. The name isrequired by the LDF fragment ADSP-BF592A-LDF.h, which the customized LDF will#include (see below). Listing 1 shows how
the default LDF defines the memory section
name; refer to the default VDK .LDF file for
VDK-based applications.

MEMORY{MEM_L1_SCRATCH{ START(0xFFB00000) END(0xFFB00FFF) TYPE(RAM) WIDTH(8) }MEM_L1_CODE{ START(0xFFA00000) END(0xFFA07FFF) TYPE(RAM) WIDTH(8) }#if defined(IDDE_ARGS)#define ARGV_START 0xFF807EB0
MEM_L1_DATA{ START(0xFF800000) END(0xFF807EAF) TYPE(RAM) WIDTH(8) }MEM_ARGV{ START(0xFF807EB0) END(0xFF807FFF) TYPE(RAM) WIDTH(8) }#else
MEM_L1_DATA{ START(0xFF800000) END(0xFF807FFF) TYPE(RAM) WIDTH(8) }#endif} /* MEMORY */Listing 1. Example of defining MEM_L1_DATA
Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 4 of 11#include the LDF fragment ADSP-BF592-ALDF.h, which defines the location of eachfunction in the Tools Utility ROM. As an
example, refer to Listing 2, which is an
extract based on the default .LDF file andshows where to include the fragment.


Add the file romdata-BF592-A.doj to thelist of object files to be included in theapplication; this object file defines the L1
SRAM data that is required by the Tools
Utility ROM. If the application is using VDK,then add the file romdata-BF592-A-TMK.doj
instead. Listing 3 is another extract based on
the default .LDF file and shows how the LDF
ensures that the file romdata-BF592-A.doj is
included in the application.

PROCESSOR p0{
OUTPUT( $COMMAND_LINE_OUTPUT_FILE )/* Following address must match the reset PC address */RESOLVE(start,0xFFA00000)#if defined(IDDE_ARGS)RESOLVE(___argv_string, ARGV_START)#endif
KEEP(start,_main)#include "ADSP-BF592-A-LDF.h"
Listing 2. Example of #including ADSP-BF592-A-LDF.h/*** define linked objects list*/
$OBJECTS =CRT,/* C startup object$COMMAND_LINE_OBJECTS ,/* defined by linker */#if defined(USE_PROFILER0)/* Profiling initialization funcs.
RT_OBJ_NAME(prfflg0_532),#elif defined(USE_PROFILER1)
RT_OBJ_NAME(prfflg1_532),#elif defined(USE_PROFILER2)
RT_OBJ_NAME(prfflg2_532),#endif__initsbsz532.doj,/* meminit support
romdata-BF592-A.doj,/* ROM-referenced data
#if defined(USER_CPLBTAB)
USER_CPLBTAB ,/* custom cplb configuration#else
cplbtab592-a.doj,/* default cplb configuration#endif
RT_OBJ_NAME(crtn532)/* CRT end object

*/
*/

*/
*/
*/
*/
*/

Listing 3. Example of how to include romdata-BF592-A.doj

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 5 of 11

Make sure that any definition of the
MEM_ARGV memory section does not conflictwith the L1 data SRAM for the ROM
functions (that for silicon revisions 0.1 and
0.2 is allocated between the memory
addresses 0xFF800000 and 0xFF800E40).



For VDK projects, replace the library TMKBF532.dlb with the TMK ROM definition
library TMK-BF532_ROM_DEF.dlb. Listing 4
is a snapshot of the default VDK .LDF fileand shows how it selects the alternative
library when it is linking against the contentsof the ROM.

$LIBRARIES =#if !defined (USE_UTILITY_ROM)#ifdef _ADI_SOV_DETECTION
TMK-BF532_sov.dlb,#else
TMK-BF532.dlb,#endif#else
TMK-BF532_ROM_DEF.dlb,#endif
VDK_LIB_NAME_(CORE),VDK_LIB_NAME_(VDK_IFLAG_),$BASE_LIBRARIES;
Listing 4. Example of selecting TMK-BF592_ROM_DEF.dlb

The

files

ADSP-BF592-A-LDF.h, romdataBF592-A-TMK.doj, and romdata-BF592-A.doj

are specific to a particular silicon revision of the
ADSP-BF592 processor, and are installed under
your VisualDSP++ installation in the libraryrevision folder:Blackfin/lib/bf592-a_rev_<revision-id>

where <revision-id> corresponds to a siliconrevision, such "0.1"
Note that an individual set of library files may
cover more than one specific silicon revision andso not every silicon revision has its own libraryrevision folder; for example, silicon revision 0.1
and 0.2 share the same libraries.
When you use either the IDDE or ccblkfn tobuild your application then the linker willautomatically know where to find the appropriate
version of the files ADSP-BF592-A-LDF.h,romdata-BF592-A-TMK.doj,
and romdataBF592-A.doj. (If possible, you should avoid
calling the linker directly).

One way of working out what changes
to make to a customized LDF is toinspect the default (or default VDK)LDF.

Excluding Specific Functions in theROM
One of the effects of using the Tools Utility ROM
to link an application is that the linker will always
choose the function in the ROM over a function
with the same name that is defined in theapplication, or is defined in a supplied object fileor library. There are occasions therefore when
you may want the linker to ignore specific entry
points in the ROM. This can be done by redefining the ROM entry point as a unique symbolthat is not otherwise used by the application.
For example, suppose that an application has its
own local version of the cosine function cosf.
The entry point for this function is __cosf. (Theentry point name associated with each libraryfunction in the Tools Utility ROM is documented

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 6 of 11

in the spreadsheet that is included in theassociated .ZIP file (see Appendix A  Contentsof the ADSP-592 Tools Utility ROM). If theapplication is being built under the IDDE, thennavigate to the page Project Options -> Link-> LDF Preprocessing, and add:__cosf=ignore_cosf_in_ROM

tothe box labeled Preprocessor macrodefinitions. The actual value that is assigned
to the macro __cosf is not important - what is
important is that the name is unique to theapplication being linked. Supply a corresponding
definition for each function in the ROM that thelinker should ignore.
Figure 2 is a screenshot of the Linker’s LDF
Project Options page andcontains an example that shows that the Tools
Utility ROM-based versions of the functions cosf
and sinf should not be referenced by the
executable that the linker will build.
If the application is being built without the IDDE,
then include the switch –flags-link-MD__cosf=ignore_cosf_in_ROM amongst theswitches used to build the application.



Do not attempt to use this method to
exclude a specific ROM-based TMKfunction – doing so may cause theapplication to fail. VDK requires that
TMK is linked entirely from the ROM or
entirely from the VDK run-time libraries.

Preprocessing

Figure 2. Screenshot of the Linker’s LDF Preprocessing Project Options page

Debugging Applications that use
the ROM
You can use the IDDE to develop, test and debug
your application on the ADSP-BF592 Blackfin
processor. If you want to monitor and control the
execution of your application in a simulated
ADSP-BF592 environment, then you can use thecycle accurate ADSP-BF5xx single processor
simulator and the IDDE will automatically display

the entry points and contents of the Tools Utility
ROM in its disassembly window. However the
IDDE only directly supports the Tools Utility
ROM of the default silicon revision of the ADSPBF592 processor. Refer to Appendix B  How
to Modify the Registry to Load a Different ROM
Image if you want the IDDE to simulate a
different version of the ROM.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 7 of 11

The Blackfin family compiled simulator
is not supported with the ADSP-BF592
processor.

If you are using an ADSP-BF592 EZ-KIT Liteevaluation board or a JTAG ICE emulator thenthe IDDE will display the contents of the L1
instruction ROM - but you should be aware thatyou can only set hardware breakpoints in the
ROM if the debug target is a JTAG emulator ordinary software breakpoints cannot be set in a
non-simulated ROM.

Constraints and Limitations
This section documents restrictions that you
should be aware of when using the ADSP-BF592
Tools Utility ROM.
Silicon revision any or silicon revision none
Potentially each revision of the ADSP-BF592
processor may have its own version of the Tools
Utility ROM, and so the linker must be told
which particular silicon revision to build an
application for. This information is provided
either via the IDDE's project options or via thecompiler switch -si-revision. However, thelinker will not know which version of the Tools
Utility ROM to use if the revision is specified aseither any or none.
Under these circumstances, the default ADSPBF592 .LDF files, and the .LDF files generated by
the IDDE, will cause the linker to ignore theTools Utility ROM and they will output thefollowing warning:
The Tools Utility ROM will not be used
to link this application because thesilicon revision does not specify a
specific revision number. This message
may be suppressed by defining the LDF
macro NO_UTILITY_ROM.

The above message will not appear if the LDF
macro NO_UTILITY_ROM has been defined.

Silicon revision 0.0
Processor silicon revision 0.0 does not have a
Tools Utility ROM and any attempt to use the
ROM will be silently ignored.
Silicon Revision 0.1
The production version of the ADSP-BF592
processor silicon revision 0.1 does not support
the Tools Utility ROM and so the default for thisrevision is to not use the ROM.
However, support for the ROM can be enabled
for engineering samples as explained in thesection Linking with the Tools Utility ROM
above. An additional change will be required toenable the support for the ROM if a VDK-based
application is using the default .LDF file from
VisualDSP++ 5.0 Update 9 development tools.
The change required is to make a copy of thedefault VDK .LDF file and delete the text "&&__SILICON_REVISION__ != 0x1" from thefollowing lines in the file which guards the settingof macro USE_UTILITY_ROM:#elif __SILICON_REVISION__ != 0 \&& __SILICON_REVISION__ != 0x1#define USE_UTILITY_ROM#endifVisualDSP++ simulator directly supports one
version of the Tools Utility ROM
When using the simulator to debug an applicationthat runs on an ADSP-BF592 processor, the
IDDE will ensure that a copy of the latest versionof the Tools Utility ROM is available to thesimulator so that it can display and monitor the
progress of the application whenever it executes afunction in the ROM. There is currently a
restriction in the VisualDSP++ tools in that it can
only suppo rt the latest version of the Tools Utility
ROM in this way.
If you want to use the simulator to single step anddebug functions in other versions of the ROM,
then you will have to manually edit the registry.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 8 of 11

Appendix B  How to Modify the Registry to
Load a Different ROM Image, describes how tomake the necessary changes to the registry.
The Tools Utility ROM reserves L1 data
SRAM
This has already been referred to in detail in thesection Drawbacks of Using the Tools Utility
ROM but is repeated here for completeness.
The linker uses L1 data SRAM of the ADSPBF592 processor to satisfy the data requirementsof the Tools Utility ROM. The data is used bysome run-time library functions to define constantdata, and by the VDK core to store non-constantstatic data. The total amount of L1 data SRAM
reserved is approximately 3.6K bytes.
Debugging using hardware
Ordinary breakpoints cannot be set on
instructions that are installed in ROM. The IDDE
does, however, support hardware breakpoints
provided that the debug target is a JTAG
emulator[2].
Blackfin family compiled simulator is notavailable
The Blackfin family compiled simulator does notsupport the Tools Utility ROM and so is notsupported for the ADSP-BF592 processor.

The ROM contains the -fast-fp emulation
routines
The Blackfin compiler provides two alternative
sets of functions for emulating IEEE floatingpoint arithmetic.
The default set is the high-speed emulation librarythat relaxes some of the IEEE floating-point
standard rules for checking inputs against Not-aNumber (NaN) and denormalized numbers to
improve performance; the alternative set is slower
and occupies more L1 instruction memory but
obeys all of the IEEE floating-point standard
rules. The first set is the default and corresponds
to the switch -fast-fp while the second set canbe selected by using the switch -ieee-fp. The
Tools Utility ROM can only contain one set ofthe floating-point emulation functions and the set
selected corresponds to the -fast-fp switch.
If an application is built with the -ieee-fp switch
then the corresponding emulation routines will be
added to the application and will have acorresponding effect on its L1 instruction SRAM
occupancy. Note however that any ROM-based
run-time library function that relies on floatingpoint emulation will continue to use the default
set of emulation routines that are installed in the
ROM irrespective of the setting of the -ieee-fp
switch.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 9 of 11

Appendix A  Contents of the ADSP-592 Tools Utility ROM
The section Contents of the Tools Utility ROM, in the main body of this document, provides a broad
overview of what is included in the Tools Utility ROM. The purpose of Appendix A is to describe thecontents of the ROM in more detail.
The Tools Utility ROM for silicon revision 0.1 and 0.2 of the ADSP-BF592 Blackfin processor contains:

66 compiler support routines

21 ETSI functions

257 C and DSP run-time library functions

and the VDK core, referred to in this document as TMK

Most of the Tools Utility ROM is composed of functions from the C and DSP run-time libraries, which aredescribed in the Blackfin Compiler and Library Manual for VisualDSP++ 5.0 [1]. The ROM also contains
a selection of ETSI functions, which are also described in the manual. A complete list of library functions
that are included in the ROM is available in the spreadsheet in the associated .ZIP file.
The spreadsheet contains the following information for each run-time library function included in the ROM:The prototype of the functionThe entry-point name of the function

Associated header fileOther relevant information

The spreadsheet does not include either the VDK core or the compiler support routines that are included in
the ROM because these are hidden interfaces that are not directly callable from user source code. The
compiler support routines provide several different services for compiler generated code; a large proportionof these functions provide support for floating-point arithmetic; others provide support for the integer
division and modulus operators, and there are also routines for converting between different C data types.
Most C and C++ applications will depend on a selection of compiler support routines. All VDK-based
applications will use TMK.

The Tools Utility ROM reserves 3.6K bytes of L1 data SRAM – refer to the main body of thisdocument for more details.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 10 of 11

Appendix B  How to Modify the Registry to Load a Different ROM
Image
When you are using the simulator to debug your application on an ADSP-BF592 processor, the simulator
assumes that you are using the Tools Utility ROM for the default silicon revision of the processor (which
for VisualDSP++ 5.0 Update 9 tools is revision 0.1). If this is not the version of the ROM that you intend
to use, then you shall have to update your system registry so that the simulator will select an image of the
ROM that corresponds to the version that you want to use.
These are the steps required:
1. Enter the system registry via the \start\run\regedit command.
2. Open the key HKEY_LOCAL_MACHINE\SOFTWARE\Analog Devices
3. If you have more than one instance of the VisualDSP++ tools installed, then find the key that
corresponds to the specific installation that you want to modify. You can do this by clicking each
VisualDSP++ key until you find the version whose Install Path matches that of the VisualDSP++
installation that you want to modify.
4. Once you have located the appropriate VisualDSP++ key, open the key Tool Manager\ADSP-BF592-A
and modify the value LoadPrerequisite.0 - the first four characters the data must be SIM, followedby the pathname to a .DXE file that corresponds to the image of the ROM that you want to simulate.
For example:
LoadPrerequisite.0 = SIM,C:\Image Of My ROM.dxe

5. Close the registry and reboot.

References[1] VisualDSP++ 5.0 C/C++ Compiler and Libraries Manual for Blackfin Processors. Rev 5.4, January 2011.
Analog Devices Inc.
[2] VisualDSP++ 5.0 User Guide. Rev 3.0, August 2007. Analog Devices Inc.
[3] ADSP-BF592 Blackfin Anomaly List for Revisions 0.0, 0.1. Rev A, September 2010. Analog Devices, Inc.

Document History
Revision

Description

Rev 2 – March 16, 2011by A. Kettler

Updated document to add support for VisualDSP++ 5.0 Update 9. Initial public
release.

Rev 1 – September 21, 2010
by A. Kettler

Initial draft release.

Using the ADSP-BF592 Blackfin® Processor Tools Utility ROM (EE-351)

Page 11 of 11