Suite56™ DSP Tools User’s Manual, Release 6.3 DSPS56TOOLSUM/D Document Rev. 1.
Suite56, OnCe, and MFAX are trademarks of Motorola, Inc. Motorola reserves the right to make changes without further notice to any products herein. Motorola makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does Motorola assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages.
Table of Contents About this Book Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3 Debugging C and Assembly Code 3.1 Initializing a Debugging Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.1.1 Choosing Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.1.2 Defining Paths and Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3.1.3 Logging Commands for Later Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3.1.
Chapter 4 Tips about Special Projects 4.1 Managing Projects with Multiple Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Connecting Multiple Devices to the Suite56 ADS Debugger . . . . . . . . . . . . 4.1.2 Simulating Multiple Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Simulating Communication between Multiple Devices . . . . . . . . . . . . . . . . 4.2 Developing Real-Time Applications . . . . . . . . . . . . . . . . . . . . . . . . . .
vi Suite56 DSP Tools User’s Manual Motorola
List of Figures 1-1 Simple Code Development Cycle: Compile, Link, Execute to Debug . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1-2 Compiling by Default or with the Option -c . . . . . . . . . . . . . . . . . 1-2 1-3 Input and Output of the Assembler . . . . . . . . . . . . . . . . . . . . . . . 1-4 1-4 Input and Output of the Linker. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 1-5 Typical Use of a Simulator in a Filtering Application . . . . . . . . . .
viii Suite56 DSP Tools User’s Manual Motorola
List of Examples 2-1 2-2 2 -3 Start the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Test Commands for the Command Converter . . . . . . . . . . . . . . . . . . . . . 2-4 Test Commands for the Target Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 2 -4 Setting Low Frequencies in Suite56 Tools . . . . . . . . . . . . . . . . . . . . . . . . 2-5 3 -1 Logging Commands to a File for Reuse . . . . . . . . . . . . . . . . . . . . . . . . .
x Suite56 DSP Tools User’s Manual Motorola
About this Book This manual is a guide to Motorola code-development tools, such as simulators of digital signal processors, hardware evaluation modules, debuggers, compilers, assemblers, and linkers. It does not replace the reference manuals and on-line help available with these tools. Rather, it serves as your introduction, orienting you and indicating how to get the most from these tools.
We also assume that you are fluent in the programming language—whether C or assembly language—for your project, and that if you have difficulties with it, you will consult your favorite language manual. If you are developing your application in C, then of course you need a C cross-compiler installed on your development system. (Section 1.1, “Compilers,” on page 1-2, offers more information about available C cross-compilers.
Conventions This manual uses the following notation conventions: • Courier monospaced type indicates commands, command parameters, code, expressions, data types, and directives. • Curly brackets {} are used in two ways. In the context of the syntax of commands (for example, in a reference manual), they enclose a list of command parameters from which you must choose one; the curly brackets are not part of the command; you do not need to enter the curly brackets.
GSM global system for mobile communication GUI graphic user interface IIR infinite impulse response (a type of filter) JTAG Joint Test Action Group (an industry-wide consortium) LTP long-term predictor (an algorithm used in digital signal processing) OnCE™ On-Chip Emulation (a protocol and circuitry comprising a debugging module) PROM programmable, read-only memory ROM read-only memory Bibliography The following documents are available from the Motorola Literature Distribution Center (LDC) o
Chapter 1 Selecting Tools This chapter explains which Motorola Suite56 tools will enable you to accomplish which tasks; it describes the tools briefly and provides illustrations showing how to make the tools work together as you generate and debug code for digital signal processors.
Compilers 1.1 Compilers Motorola recommends purchase of the Tasking C compiler for the DSP56300 and DSP56600 families of digital signal processors. Motorola markets the m568c C compiler for the DSP56800 family. Alternatively, Motorola distributes enhanced versions of the ANSI-compliant GNU C compiler. These compilers are specific to families of Motorola devices; that is, the g563c is an optimizing C compiler for the DSP56300 family of devices, and the g566c for the DSP56600 family.
Assemblers This option to link explicitly is obviously a good choice under several different conditions: • if your project consists of many, large C source files; if those files are compiled with option -c, then changes to one file will simply require recompilation of that file and relinking to the others; you can save the time required to recompile the unchanged files; • if your project consists of a mixture of C source and assembly code; • if your project needs to link to existing libraries or other
Linkers assembly code files (*.asm) assembly macro files (*.mac, *.h, *.asm) equate files assembler relocatable object file (*.cln) option -l listings (*.lst) executable object file COFF format (*.cld) option -mu linker memory use reports option -m executable object file COFF format (*.cld) map file (*.map) Figure 1-3. Input and Output of the Assembler 1.
Linkers You can control the Suite56 linker by means of command files. With the option -f, you can control the linker through a command-line file. With the option -r, you can use a memory-control file as in Figure 1-4. C source files make utility compiler command line file option -f memory control file option -r linker default executable object file COFF format (*.cld) option -i option -m relocatable file (*.cln) map file (*.map) no longer AA164 Figure 1-4.
Simulators 1.4 Simulators A Suite56 simulator is a software implementation of a hardware device, such as a digital signal processor. As such, a simulator is advantageous in a number of ways: • Whereas hardware for code development may be costly or limited in number, software simulators can serve any number of developers. • As software, a simulator may be more portable—in the sense of traveling from office to home, for example—than comparable hardware for code development.
Simulators 1.4.1 Data Streams and the Simulator A simulator is also a reasonable choice when you frequently have to download very large files that would be slow or cumbersome to download from a hardware debugger to a target board. In fact, Suite56 simulators implement several types of data streams expressly for such activity. The Motorola DSP Simulator Reference Manual documents these data streams in Chapter 3, “Device I/O and Peripheral Simulation,” and Section 4.2.
Simulators 1.4.2 User Interfaces to the Simulator The Suite56 simulator offers a graphic user interface with windows, menus, and online help, as in Figure 1-6 on page 1-8. There are several ways of starting the Suite56 simulator. For example, if you are working on an NT platform and want to run the simulator for the DSP56300 family, use one of the following alternatives: • Double-click its shortcut icon on your desktop.
Simulators The Motorola DSP Simulator Reference Manual documents options available for both interfaces of the simulator. In this manual, the answer to a frequently asked question offers guidelines for customizing your interface to a Suite56 simulator (Section 5.1, "How do I customize Suite56 tools for my tasks?," on page 5-1). 1.4.3 Debugging with the Simulator The Suite56 simulator is well adapted to debug application code aimed at a digital signal processor.
Hardware Debugger: ADS session window command line help line Figure 1-7. Text-Based Interface of the Simulator 1.5 Hardware Debugger: ADS Like a simulator, a Suite56 hardware debugger, often referred to as the ADS or application development system, allows you to evaluate a target digital signal processor comprehensively and to evaluate how your algorithms behave with respect to your target hardware. To manage input and output, a Suite56 debugger offers highly advantageous facilities.
Hardware Debugger: ADS 37-pin interface cable 14-pin ribbon cable host computer Motorola DSP host-bus interface card command converter application development module (ADM) Figure 1-8.
Hardware Debugger: ADS 1.5.1 User Interfaces to the Debugger The Suite56 debugger offers a graphic user interface with windows, menus, and online help for interactive debugging, as in Figure 1-9 on page 1-13. There are several ways of starting the Suite56 hardware debugger. For example, if you are working on an NT platform and want to run the hardware debugger for the DSP56300 family, you use one of the following alternatives: • Double-click its shortcut icon on your desktop.
Hardware Debugger: ADS Help menu Figure 1-9. Graphic User Interface of the Hardware Debugger In the text-based, command-line interface, when you type a command on the command line, then the syntax of that command appears automatically on the help line. If you type a question mark after a command on the command line, then more help, in addition to the command syntax, appears in the window.
Hardware Debugger: ADS 1-14 Suite56 DSP Tools User’s Manual Motorola
Chapter 2 Testing Your Hardware Installation The manual for each Motorola Suite56 tool (such as a compiler, an assembler, the linker, a simulator, a hardware debugger) includes a chapter explaining how to install that tool. The manuals for platform-dependent tools, such as the Suite56 ADS hardware debugger, also include an appendix of platform-specific details. This chapter assumes that you have followed the steps outlined in those installation guides and offers simple tests to check your installation.
37-pin interface cable 14-pin ribbon cable host computer Motorola DSP host-bus interface card command converter application development module (ADM) Figure 2-1.
Testing Your Installation of the Command Converter 2.
Testing Your Installation of the Command Converter 2.1.2 Testing through the Command-Line Interface If you prefer the command-line interface to your Suite56 tools, then test your installation of the command converter through the following steps: 1. Start the hardware debugger. For example, if you are using the debugger for the DSP56300 family, type the command in Example 2-1.
Testing a Low-Frequency Target Device 2.2 Testing Your Installation of a Target Board If you have successfully completed the test in Section 2.1, "Testing Your Installation of the Command Converter," and you have also connected a target device such as: • a Suite56 application development module (e.g., DSP563xx ADM), • a Suite56 evaluation module (e.g., DSP563xx EVM), or • your own target board, then we recommend that you complete your installation test by typing the commands in Example 2 -3.
Choosing a Connector for the EVM Power Supply 2.4 Choosing a Connector for the EVM Power Supply Most Suite56 evaluation modules have a 2.1 millimeter receptacle to connect the external power supply. Modules to support the DSP56800 family, however, are exceptional in this respect: they have a 2.5 mm receptacle. A 2.5 mm connector will connect all modules, but the recommended 2.1 mm connector for the 2.1 mm modules and a 2.5 mm connector for the 2.
Chapter 3 Debugging C and Assembly Code This chapter walks you through sample programs in both C and assembly language to highlight the debugging facilities in Suite56 tools, particularly the hardware debugger (such as ads56800 or gds56300) and the simulator (such as sim56600 or gui56300). The interfaces—both graphic and text-based—to the Suite56 simulator were deliberately designed to be as similar as possible to those of the Suite56 ADS debugger. You can use one very much as you use the other.
Initializing a Debugging Environment 3.1.2 Defining Paths and Working Directories A Suite56 tool, by default, looks for input files and places output files in the current working directory. It can also redirect its search for files and its output to other specified directories by means of a path. For every target device, the debugger can maintain a distinct path, so you can organize input and output files for each target device separately.
Initializing a Debugging Environment Anytime you want to repeat that sequence of logged commands, from the File menu, choose Macro. A dialogue box appears for you to indicate which file you want to execute. From the text-based, command-line interface, you can also save a sequence of commands in a log file. You type the log command with two parameters: the option “c” to indicate that you want to log only commands and the argument of a file name for the log file.
Initializing a Debugging Environment 3.1.5 Setting the Radix Whether you are using the graphic user interface or the text-based interface, you can set the radix for the display of the contents of registers before you display them. (The radix is the basis for computing the value of digits as numbers. For example, the digits 32 in decimal radix represent the value thirty-two and in hexadecimal radix, they represent fifty.
Source-Level Debugging in C 3.1.7 Displaying Memory To display blocks of memory in the graphic user interface, from the Windows menu, choose Memory. A dialogue box appears for you to indicate which parts of memory you want to display. (The parts available for display vary according to the target device.) The Suite56 tool will then open a window, labeled with the device and memory blocks you have chosen, and display the block names and values.
Source-Level Debugging in C 3.2.1 Compiling to Debug When you are preparing to debug a C program with Suite56 tools, you must compile the program in debug mode with debugging symbols to retain information useful for debugging in the executable code. The compiler option for debug mode is -g if you are using a Suite56 C compiler, such as g563c for the DSP56300 family of devices or g566c for the DSP56600 family.
Source-Level Debugging in C Example 3 -2. A Sample C Program: ltp.
Source-Level Debugging in C 3.2.2 About Software Breakpoints in a C Program This section discusses software breakpoints in debugging a C program. For details about hardware breakpoints, see the family reference manual (e.g., Motorola DSP56600 Family Manual) and the device manual (e.g., Motorola DSP56602 User’s Manual), particularly chapters about the OnCE module and programming practices, for your target device. Section 4.
Source-Level Debugging in C 3.2.3 Setting Software Breakpoints in a C Program The following procedure details the exact steps required to set a software breaktpoint. 1. From the Execute menu, choose Breakpoints, then select Set Software. The Set Breakpoints dialog box shown in Figure 3-1 appears. Figure 3-1. Setting a Software Breakpoint 2. Under Breakpoint Number select the number you want to assign to this breakpoint. The default number that is shown is the next available number.
Source-Level Debugging in C 3. Under Count secify how many times the Debugger should encounter the breakpoint before performing the action. For example, if you set the count to 3, the breakpoint will be triggered the third time that the breakpoint is encountered. Real time execution will be affected if you set the count to more than one. 4. If you have assigned an input file, you can mark EOF. The breakpoint will be acted upon when the input file reaches an end-of-file.
Source-Level Debugging in C Table 3-1. Software Breakpoint Actions Breakpoint Resulting Action Halt Stops program execution when the breakpoint is encountered. Note Displays the breakpoint expression in the Session window each time it is true. Program execution continues. The display in the Session window is not updated until program execution stops. Show Displays the enabled register/memory set. Program execution continues. Command Executes a Debugger command at the breakpoint.
Source-Level Debugging in C 3. Click OK. The breakpoints you selected are now deleted. Breakpoints will not be renumbered. For example, if you have set breakpoints #1, #2, and #3, and then clear breakpoint #2, the remaining breakpoints will be numbered #1 and #3. Notice that breakpoints are indicated in the Assembly window and the Source window (if applicable). Enabled breakpoints appear in blue. Disabled breakpoints appear in pink. 3.2.
Source-Level Debugging in C 3.2.6 To Set a Hardware Breakpoint 1. From the Execute menu, choose Breakpoints, then select Set Hardware. The dialog box in Figure 3-3 appears. Figure 3-3. Setting a Hardware Breakpoint 2. Under Type select the type of hardware breakpoint to set. Breakpoint types are device specific. See Table 3-2 for an explanation of each type of breakpoint. 3. Under Memory Space, select the memory space in which the breakpoint is to be set. 4.
Source-Level Debugging in C 5. Under Option, indicate whether a second condition should be considered. And indicates that both conditions must be met to trigger the breakpoint. Or indicates that either condition can be met. Then indicates that the First Condition must be satisfied followed by the Second Condition. Only indicates that only the first condition must be met to trigger the breakpoint. 6. Under Second Condition specify the conditions for the second condition.
Source-Level Debugging in C 3.2.7 To Clear a Hardware Breakpoint 1. From the Execute menu, choose Breakpoints, then select Clear. The Clear Breakpoints dialog box, shown in Figure 3-2 on page 3-11, displays a list of all the current breakpoints. 2. Select the breakpoint you want removed so that it is highlighted. If you are clearing consecutive breakpoints you can click and drag to highlight more than one breakpoint. Or hold down the CTRL key while clicking on breakpoints to select more than one. 3.
Source-Level Debugging in C In the text-based interface, to define a watch list, use the watch command, as in Example 3 -3. Example 3 -3. Defining a Watch List > > > > watch r0 watch x:0 watch {signal_lin[ind1]} watch ; adds the register to the watch list ; adds memory location to the watch list ; adds item of array to the watch list ; displays the current watch list To remove an item from a watch list, in the graphic user interface, from the Display menu, choose Watch, and then select Off.
Source-Level Debugging in C 3.2.10 Casting in a C Program Suite56 tools support these kinds of casts for both basic C types and user-defined types (i.e., those defined by typedef): • • • • • • (type) (type *) (enum enumeration_tag) (enum enumeration_tag *) (struct structure_tag *) (union union_tag *) 3.2.11 Tracing in a C Program Suite56 tools offer tracing so you can continuously see the values in any registers or memory locations that interest you as your program executes.
Source-Level Debugging in C These are the C-specific debugging commands: • down moves down the C function call stack. In the graphic user interface, from the Modify menu, choose Down. • frame designates the current frame in the C function call stack. (The current frame determines the scope for evaluation.) In the graphic user interface, from the Display menu, choose Call Stack. • redirect redirects standard input (stdin) and standard output (stdout and stderr).
Symbolic Debugging in Assembly Code again and choose Close. A dialogue box opens for you to indicate that you want to close the Profile log file. Closing that file will end that profile. In the text-based interface of the simulator, first load your executable program, both symbols and memory. Then use the log command with two arguments: the option p to indicate profile and a name for the profile log file.
Symbolic Debugging in Assembly Code Example 3 -5. A Finite Impulse Response Filter in Assembly Code: fir.asm opt cex,mex,cre,cc,mu page 132,66,0,10 section filter include define define define define "iodata.h" P_MEM "0" X_MEM "1" Y_MEM "2" L_MEM "3" data_points equ org data_in data_out y: ds ds set xdef 20 ;number of points to process 1 1 i 0 coefficients coefficients dupa coef,21.0/231.0,14.0/231.0,39.0/231.0,54.0/231.0,59.0/231.0,54.0/231.0,39.0 /231.0,14.0/231.0,-21.0/231.
Symbolic Debugging in Assembly Code rep move #data_points x0,x:(r6)+ ;clear data points .loop do #data_points,end_fir ;one loop for each tap IODATA move input_data,1,1,Y_MEM,data_in y:data_in,x0 jsr fir_filter move IODATA a,y:data_out output_data,1,1,Y_MEM,data_out ;output sample ;write data to ADS move a,x:(r6)+ ;save data a x0,x:(r1)+ y:(r5)+,y0 #num_taps-1 x0,y0,a x:(r1)+,x0 y:(r5)+,y0 x0,y0,a (r1)- ;save first state ;read data from ADS ;get sample end_fir .
Symbolic Debugging in Assembly Code 3.3.1 Setting Breakpoints in Assembly Code This section discusses software breakpoints in debugging an assembly program. The observations about software breakpoints in Section 3.2.2, "About Software Breakpoints in a C Program," on page 3-8, also apply to software breakpoints in assembly code. For details about hardware breakpoints, see the family reference manual (e.g., Motorola DSP56600 Family Manual) and the device manual (e.g.
Symbolic Debugging in Assembly Code To disable a breakpoint, in the graphic user interface, double-click on it in the Assembly window. Alternatively, from the Execute menu, choose Breakpoints, and then select Disable. In the text-based interface, use the break command followed by the number of the breakpoint and the option off. 3.3.2 Tracing Assembly Code Suite56 tools offer tracing so you can continuously see the contents of any registers or memory locations that interest you as your program executes.
Calling Assembly Code from C Code 3.4 Calling Assembly Code from C Code C compilers—whether distributed by Motorola or by another supplier of software tools—observe calling conventions (i.e., conventions about how information flows between a routine that calls a piece of code and the piece of code that is called) usually documented in the reference manual for that compiler.
Exploiting Memory Control Files Example 3 -8. An Assembly Routine Called by a C Program section norm_routine_in_asm global Fnorm_l Fnorm_l ; Receives parameter in a, returns normalized value in a clb a,b neg b move b,a rts endsec 3.5 Exploiting Memory Control Files This example, showing you how to use a memory control file to locate sections at specific addresses in X memory on a target device, is based on the Suite56 assembler for the DSP56300 family.
Exploiting Memory Control Files Example 3 -11. Assembling Two Relocatable Object Files > asm56300 -b section_a.asm > asm56300 -b section_b.asm The commands in Example 3 -11 create relocatable object files, section_a.cln and section_b.cln, that can then be linked. For the purpose of this example, we assume that we want the block of zeroes set up by section_a.asm to start at location x:$333 and the block of ones set up by section_b.asm to start at x:$555.
Exploiting Memory Control Files Example 3 -14. A Memory Map File: out.map Motorola DSP Linker Version 6.2.1 98-05-22 10:29:21 out.
Exploiting Memory Control Files 3-28 Suite56 DSP Tools User’s Manual Motorola
Chapter 4 Tips about Special Projects The tips about special projects in this chapter were collected from Motorola customers and application developers engaged in “real world” projects. 4.1 Managing Projects with Multiple Devices Both the Suite56 ADS debugger and the Suite56 simulator support your code generation and debugging for multiple digital signal processors of the same family. 4.1.
Managing Projects with Multiple Devices In contrast, if all the digital signal processors in your project have a JTAG interface, then you can connect up to 24 such devices through a single command converter for debugging through a Suite56 ADS debugger.
Managing Projects with Multiple Devices As long as a simulated device is configured ON, it is active during execution commands such as Go, Step, or Trace, and responds to them appropriately. To make a given device inactive (so that it no longer responds to execution commands), configure it as OFF.
Developing Real-Time Applications 4.1.3 Simulating Communication between Multiple Devices Use simulated input to simulate communication between multiple devices. In fact, you can simulate tying pins together and connecting to different memory locations. To tie pins together (so that the output from one pin becomes input to another pin), from the File menu, select Input, and then choose Pins. A dialogue box appears for you to indicate which pins to tie together.
Developing Real-Time Applications To apply a pin file, in the File menu, choose Input, and then select Open. A dialogue box appears for you to indicate in the From pane that the input comes from a file and in the To pane that it applies to a pin. In the File Name pane, you indicate the name of the input file. In the text-based interface, use the input command with the pin name and file name as parameters to apply a pin file to a pin. 4.2.
Developing Real-Time Applications 4.2.3 Generating Output with Time-Critical Information Simulated output can consist of pairs of items, where the first item of each pair is a cycle number and the second is the actual output datum. The cycle number indicates relative time, so in this way, a Suite56 simulator produces output with time-critical information. You can capture this timed output from peripherals, memory, ports, pins, or registers.
Finding Well Hidden Bugs 4. Tie the output of the second device to the SSI input pin of the first simulated device. In the File menu, choose Input, and then select Pins. A dialogue box appears for you to indicate that you want to tie the output of device 2 to the SSI input of device 1. 5. Execute your program. For example, click the Go button. 4.
Finding Well Hidden Bugs To set a breakpoint on an address in memory, follow these steps: 1. Set the default device. In the Modify menu, choose Device, and then select Set Default. 2. Load your program, both memory and symbols. In the File menu, choose Load, and then select Memory. A dialogue box appears for you to indicate Memory and Symbols as well as the name of the file to load. 3. Open the device window to display memory. In the Windows menu, choose Memory.
Finding Well Hidden Bugs Figure 4-3. Dialogue Box to Set a Breakpoint in Memory 4.3.2 Setting Breakpoints on Registers To set a breakpoint on a register, follow the steps in Section 4.3.1, "Setting Breakpoints on Memory," on page 4-7, choosing Register (rather than Memory) each time. In other words, you can set a breakpoint on a register either by clicking on the register contents in a device-register window, or by choosing Execute//Breakpoints//Set from the menu.
Finding Well Hidden Bugs 4-10 Suite56 DSP Tools User’s Manual Motorola
Chapter 5 Answers to Frequently Asked Questions The answers to frequently asked questions that appear in this chapter were collected from the Motorola DSP Helpdesk. You can also find updated FAQs at the Motorola website: http://www.mot.com/SPS/DSP/faq 5.1 How do I customize Suite56 tools for my tasks? There are a number of ways to customize your Suite56 tools. Customizations for each tool are documented in the manual for that tool (e.g.
I’m tired of initializing my development environment every time I start work. Is there any way to save my • Choose which windows open automatically when you start a session. In the graphic user interface, from the File menu, choose Preferences. A dialogue box opens for you to indicate which windows to open and whether to save window status when you exit the tool.
I’m having trouble debugging at low frequencies. You can create a startup.cmd file either by logging commands (as explained in Section 5.1 ) or by writing its contents yourself with an ordinary text editor. Use the same syntax as you use for commands on the command line of the tool, and use the same conventions for indicating paths, directories, file names, and so forth as appropriate for your operating system. If you work on more than one development project, you can define a separate startup.
How do I halt in mid-cycle in a Suite56 simulator? Example 5 -1. Setting Low Frequencies in Suite56 Tools > host clock ‘32 > host clock 32 ; sets the frequency to 32 kilo herz ; sets the frequency to 50 kilo herz 5.6 How do I halt in mid-cycle in a Suite56 simulator? Generally, execution does not halt in mid-cycle in the Suite56 simulators. However, control-C entered as a command interrupts on an instruction boundary. In certain very special cases, this command may meet your needs.
How do I plot memory use? 5.7 Can I link my customized libraries to a Suite56 simulator? Yes, you can link customized libraries to a Suite56 simulator. In the standard distribution of software that comprises the simulator, there is a make file for the components of the simulator on your development platform. Edit that make file to link your customized libraries before the standard Suite56 libraries of the simulator.
How do I get a listing with cycle counts? When you assemble your application, use the option -mu to report loadtime memory use, and use the option -g to include debugging information in the output of the assembler. Then load your assembled application into your Suite56 simulator. After loading the assembled application into the simulator, then from the File menu, choose Log, and select Profile.
What does this error message mean? 5.12 My program runs, but it is too big. Assemble your application with the option -mu to report loadtime memory use. Then profile your program as suggested in Section 5.9 . Analyze the loadtime memory-use report and the profile before you begin optimizing to be sure that you locate portions of your code that truly affect its memory use. As a last resort, consider designing code overlays for your application.
What does this error message mean? 5-8 Suite56 DSP Tools User’s Manual Motorola
Glossary absolute executable file is an object file in which the assembler and linker have filled in, for every symbol, its ultimate location on its target hardware (i.e., the final address in memory of that symbol). ADM application development module is a hardware component, a device-specific board, a part of an application development system.
overlaying is a strategy of repeatedly using the same location in memory for the execution of different pieces of code at different times during the execution in order to maximize limited memory. radix is the basis for computing the value of a group of digits. For example, the digits 32 represent the number thirty-two when the radix is decimal but the number fifty when the radix is hexadecimal; likewise, the digits 101 represent one-hundred one in decimal radix, but five in binary radix.
Index A abbreviations xiii absolute executable file 1-4, Glossary-1 acronyms xiii ADM application development module Glossary-1 setting up 2-1 testing 2-1 ADS application development system 1-10, Glossary-1 setting up 2-1 testing 2-1 assembler 1-3 , Glossary-1 calling conventions 3-24 to debug 3-6 to profile 3-18 convolution 3-5 creating command log file 5-2 map file 3-26 program profile 3-18 cross-assembler Glossary-1 cross-compiler Glossary-1 current working directory 3-2, Glossary-1 cycle counts 5-6 B
long-term predictor (LTP) 3-5 map file 3-26 memory control file 3-25 test command converter 2-4 test target device 2-5 exception in error message 5-7 executable file absolute 1-4 command file 5-3 relocatable 1-4 startup.
multiple devices 4-1 JTAG interface 4-2 no JTAG interface 4-1 separate directories for 5-1 simulating communication 4-4 N notation xiii casts 3-17 curly brackets {} xiii, 3-16 operator # 3-16 operator $ 3-16 square brackets [] xiii O object file linking incrementally 1-4 relocatable 1-4, Glossary-2 online help ADS debugger 1-12 simulator 1-9 optimizing 5-6, 5-7 output simulating 5-5 timed 5-5 overlay 1-3, 1-5, 5-7, Glossary-2 P page fault in error message 5-7 patch 1-9 path 3-2, 5-1 performance 5-6 perip
displaying source code 4-3 function calls 4-3 preferences 3-1, 5-2 session 4-3 simulated input 4-3 simulated output 4-3 watch list 4-3 Index-4 DSP Tools User’s Manual Motorola
