![1 Introduction to the Freescale DSP-Enviroment and the assembler
addition to the interface the debug conguration with Thread [0] (Suspended) and the
Editor view with the source code will highlight the rst line of the DSP program. The
object code is now ready to run either in the simulator or in the DSP via the debugger.
In both cases it is possible to monitor all core registers and the DSP memory in the
Registers and Memory views. The Register view shows by default the core registers
grouped by functionality. The Memory view is empty by default and the memory area
of interest must be added by clicking on the green plus button in the views toolbar.
In the so opened window the address must be entered with the prex 0x (indicating a
hexadecimal data type address) and the memory space P, X, Y or L must be chosen.
By clicking OK the window closes and the selected memory space is displayed in the
Memory view. The default Rendering of the chosen memory space is the hexadecimal
number format. By clicking on the green plus button in the upper right of the memory
view (Add Rendering(s)) a new Rendering for example in the fractional number format
can be generated.
There are two dierent ways to simulate or debug the object code: Either stepping line
by line through the source code lines by pressing F5 (or the Step into button, the most
left yellow arrow in the toolbar) or running the code by pressing F8 (or the Resume
button, the green and yellow play/pause button in the toolbar). The latter will run the
code until the end of the program or up to a breakpoint which can be set for example
by double-clicking left of a source code line in the Editor view. Note that both, the
Register and the Memory view, will only be updated when the program is halted.
1.2 Source code basics
The source code can be divided into two main parts, the preprocessor part and the actual
DSP program. The former is the place to dene so called symbols and constants.
1.2.1 Preprocessor
Symbols are basically names for dened values with the use of the equ instruction. For
example
sym1 equ $10
means the symbol sym1 equals (or represents) the hexadecimal value $10. These symbols
are not stored in the DSP but the assembler uses the information to ll the assigned
values in the program code wherever the symbol is used. Symbols (and labels which are
discussed later) in contrast to instructions must not have leading blanks in the source
code to be recognized as a symbol by the assembler.
Constants are values stored in the DSP memory by the assembler at the initializing
process. Such constants can be dened by the dc instruction and the place where to
store them is dened by the org instruction.
7](https://image.slidesharecdn.com/dsplabv1-160629024244/85/Dsplab-v1-7-320.jpg)
Dsplab v1
- 1. AG DIGITALE SIGNALVERARBEITUNG TECHNISCHE UNIVERSITÄT KAISERSLAUTERN DSP Laboratory Experiment 1 Freescale DSP Development Environment May 15, 2013
- 2. 1 Introduction to the Freescale DSP-Enviroment and the assembler DSP-Software is typically developed in several steps: An .asm File containing the source-code is written by the programmer which is translated into object-code (the .cld le) by the assembler. The object-code can be debugged, either directly on the DSP or in a simulator, whereby the latter emulates the DSP in software. The simulator (without the use of any further hardware) can be used to validate the code by stepping through the code step by step and the possibility to see the contents of all registers and all memories. The registers are part of the Arithmetic Logic Unit (ALU) or of the Address Generation Unit (AGU) of the DSP, which will be discussed in later experiments. The debugger can do exactly the same directly in the DSP with the use of an hardware interface. 1.1 Symphony Studio Freescale provides a freeware development software called Symphony Studio, which is based on the well known software development environment Eclipse. This Software com- bines an editor (with highlighting) and all the discussed tools to develop DSP-Software. 1.1.1 User interface Symphony Studio is organized in so called perspectives, each containing so called views. The default perspective is the C/C++ perspective which is shown in gure 1.1. This perspective contains, besides others, the C/C++ Projects view to browse the workspace (the navigator on the left side of the window), the editor view to edit the code (the editor at the center of the window) and the console view, which shows for example notications of the assembler (at the bottom of the window). The second important perspective is the Debug perspective (see gure 1.2), which is used to simulate or debug the object-code. Therefore the Debug view (in the upper left of the window) shows whether the on-chip debugger or the simulator is used, beneath that in the editor view the code is shown with the possibility to set breakpoints, and at the right of the window the views Registers and Memory show the registers and the memories of the DSP. Another important view is the Disassembly view, which shows the object code stored in the program memory of the DSP. To switch between these two perspectives there are two buttons in the upper right of the Symphony Studio window, one for each perspective. 2
- 3. 1 Introduction to the Freescale DSP-Enviroment and the assembler EDITOR NAVIGATOR CONSOLE Figure 1.1: user interface of Symphony Studio, the C/C++ perspective EDITOR DEBUG Figure 1.2: user interface of Symphony Studio, the Debug perspective 3
- 4. 1 Introduction to the Freescale DSP-Enviroment and the assembler 1.1.2 Workspace and projects The workspace can be seen as a default folder where all projects are stored. The following paragraph describes how a project is generated. All following actions should be performed in the C/C++ perspective. By clicking on File - New - Managed Make ASM Project a new project can be added to the workspace. A new window opens where the name of the project can be dened under Name:, the checkbox Use default location should be checked for storing the project in the workspace. Clicking Next leads to the selection of the project type, where 56K ASM COFF should be selected. All other default settings can be left unchanged and by clicking on Finish the project is generated and appears as an empty folder in the navigator. A source le can be added to the project by clicking File - New - Source File. In the following window the name of the source le with its extension, which is .asm for DSP source codes, is dened under Name:. By clicking Finish the source le is generated and appears in the navigator on the left in the project folder. If a project contains several source les some source les can be excluded from being assembled by right clicking on the source le, choosing Properties - C/C++ Build, and checking the checkbox Exclude from Build. This can be useful in case of several dierent functions in one project or if a source le will be included (including will be explained in one of the next experiments) in the main le. 1.1.3 Generating object code with the assembler To generate object code in Symphony Studio the process Build Project needs to be started. To do so there are two ways, either by clicking Project - Build Project or with the option Project - Build Automatically checked. The latter way rebuilds the project every time a source le is changed and saved. 1.1.4 External Tools The simulator and the debugger in Symphony Studio can be seen as software interfaces, which are called External Tools. So, whenever the object-code shall be run or simulated we need to start the correct External Tool rst. Figure 1.3 shows the structure. For generating an interface a new External Tool needs to be congured. This can be done by choosing Run - External Tools - External Tools.... A new window (see gure 1.4) opens and a new interface can be generated, according to the following paragraphs. Simulator The simulator interface is called SIMAPI GDB Server. A double click on SIMAPI GDB Server in the list in the left of the window generates the new conguration which can be renamed under Name: at the top. To access the conguration quickly, the checkbox External Tools under the tab common - Display in favorites menu should be 4
- 5. 1 Introduction to the Freescale DSP-Enviroment and the assembler Symphony Studio OpenOCD GDB ServerSIMAPI GDB Server Simulate Step (F5) Run (F8) External Tools (interfaces) Debug (action) Figure 1.3: debugging and simulation in Symphony Studio checked. By clicking Apply and Close the window closes and the new interface can be found under Run - External Tools. Debugger The debugger interface is called Open OCD GDB Server. Again a double click generates the new interface. As the debugger is used for on-chip debugging the used DSP has to be selected under OpenOCD Conguration File via the left of the two drop-down menus, which is in our case the DSP Family 56300. Beside that, the Dongle (the hardware interface between host PC and DSP Board) needs to be selected via the right of the two drop-down menus, in our case this is soundbite. To access the conguration quickly, the checkbox External Tools under the tab common - Display in favorites menu should be checked. By clicking Apply and Close the window closes and the new interface can also be found under Run - External Tools. 1.1.5 Debug conguration To simulate or debug a DSP-Software we need a debug conguration, which denes the among other things the used .cld le. By clicking Run - Debug... a new window opens where debug congurations can be generated or edited. To generate a new conguration the correct DSP family must be selected with a double click, in our 5
- 6. 1 Introduction to the Freescale DSP-Enviroment and the assembler Figure 1.4: External Tools conguration window case the Freescale 563xx. The new conguration will be listed under the chosen DSP family on the left side, the main frame of the window has changed and the conguration can be edited. Under Name: the conguration can be renamed, Project: should show the name of the current project and under C/C++ Application: the current .cld le must be chosen, which can be done easily by clicking on Search Project.... To access the conguration quickly the checkbox Debug under the tab common - Display in favorites menu should be checked. By clicking Apply and Close the window closes and the new debug conguration is saved. 1.1.6 Debugging, monitoring registers and setting breakpoints After The External Tools and the debug conguration are generated it is time to switch to the Debug perspective. As mentioned before the proper External Tool has to be started at rst by clicking Run - External Tools (alternatively clicking on the arrow next to the green play button in the toolbar) and choosing either the Simulator or the Debugger. In the Debug view the Server appears and the console shows the name of the interface. The second step to simulate or debug the object code is to start the debug conguration by clicking Run - Debug History (alternatively clicking on the arrow next to the little bug in the toolbar) and choosing the debug conguration. The Debug view will show in 6
- 7. 1 Introduction to the Freescale DSP-Enviroment and the assembler addition to the interface the debug conguration with Thread [0] (Suspended) and the Editor view with the source code will highlight the rst line of the DSP program. The object code is now ready to run either in the simulator or in the DSP via the debugger. In both cases it is possible to monitor all core registers and the DSP memory in the Registers and Memory views. The Register view shows by default the core registers grouped by functionality. The Memory view is empty by default and the memory area of interest must be added by clicking on the green plus button in the views toolbar. In the so opened window the address must be entered with the prex 0x (indicating a hexadecimal data type address) and the memory space P, X, Y or L must be chosen. By clicking OK the window closes and the selected memory space is displayed in the Memory view. The default Rendering of the chosen memory space is the hexadecimal number format. By clicking on the green plus button in the upper right of the memory view (Add Rendering(s)) a new Rendering for example in the fractional number format can be generated. There are two dierent ways to simulate or debug the object code: Either stepping line by line through the source code lines by pressing F5 (or the Step into button, the most left yellow arrow in the toolbar) or running the code by pressing F8 (or the Resume button, the green and yellow play/pause button in the toolbar). The latter will run the code until the end of the program or up to a breakpoint which can be set for example by double-clicking left of a source code line in the Editor view. Note that both, the Register and the Memory view, will only be updated when the program is halted. 1.2 Source code basics The source code can be divided into two main parts, the preprocessor part and the actual DSP program. The former is the place to dene so called symbols and constants. 1.2.1 Preprocessor Symbols are basically names for dened values with the use of the equ instruction. For example sym1 equ $10 means the symbol sym1 equals (or represents) the hexadecimal value $10. These symbols are not stored in the DSP but the assembler uses the information to ll the assigned values in the program code wherever the symbol is used. Symbols (and labels which are discussed later) in contrast to instructions must not have leading blanks in the source code to be recognized as a symbol by the assembler. Constants are values stored in the DSP memory by the assembler at the initializing process. Such constants can be dened by the dc instruction and the place where to store them is dened by the org instruction. 7
- 8. 1 Introduction to the Freescale DSP-Enviroment and the assembler For example org x:$0001 dc 0 dc 1 leads the assembler to write the value 0 in the X-memory at the address 1 and the value 1 in the x-memory at the address 2. This is because the org instruction denes the start address for the following lines and this address is incremented with every line of the source code. As org and dc are preprocessor instructions they need leading blanks (or at least one) to be recognized as an instruction by the assembler. The org instruction can be used for all types of memory space, namely the program memory P and the data memories X and Y. 1.2.2 Include les It is possible to include code snippets saved in a le with any le extension by using the include instruction. This is helpful to reuse for example symbols or constants in several projects without the need of copy and paste source code. This means that for example the instructions org x:$0001 include '..const1.tab' with const1.tab containing: dc 0 dc 1 causes exactly the same actions as the above example. 1.2.3 Labels and the jmp instruction Addresses in the program memory, or similar, lines in the source code (after the pre- processor portion) can be labeled with any name, starting with an alphabetic character. As the DSP executes the object code sequentially, this is useful in combination with the jmp instruction which causes a jump to a specic source code line. For example the code snippet org p:$0100 main nop jmp main with the nop instruction, which causes the DSP to do nothing for one cycle, produces a loop in which nothing is done. In detail it means, at p:$0100 a nop instruction is stored, this address is labeled main. After executing the nop instruction the DSP increments the program address and executes the instruction stored in p:$0101 which is a jmp 8
- 9. 1 Introduction to the Freescale DSP-Enviroment and the assembler instruction. So the DSP jumps to the label main, namely p:$0100 and executes the instruction stored there, increments the program address and so on. The actual DSP source code, after being assembled into the object code, is stored in the DSP in the so called program memory (P). The rst 256 P-memory spaces are reserved, so although the DSP sequentially performs the instructions from p:$0000 on, the source code must not start at p:$0000 but at p:$0100. This can be achieved by using the org instruction, a jmp instruction and a label and will be one of the exercises of this experiment. 1.2.4 The move instruction One of the most important instructions is the move instruction. It can be used to move memory contents to registers and vice versa, to move contents between registers or to move an 8-bit value in the form #value to a register with the so called Immediate Short Data Move. For example the instructions: move #%10101010,x1 move x1,x:$000001 move x:$000001,y0 move the binary value 10101010 to the ALU register x1, then move the content of x1 to the memory space x:$000001 and the last line causes a move of the content of the memory space x:$000001 to the ALU register y0. 1.2.5 Summarization of the source code syntax Source statement format A source statement always has the following form LABEL INSTRUCTION OPERAND X-MOVE Y-MOVE ;COMMENT where LABEL denes a label or a symbol name, INSTRUCTION can be any instruction like org, jmp or move, OPERAND is the value, or label the instruction is applied to, and X-MOVE and Y-MOVE are moves which can be performed parallel to some instructions between the X memory (or in case of the Y-MOVE the Y memory) and registers or vice versa. ;COMMENT is a comment which is ignored by the assembler. This is very useful to make the source code easier to understand. A comment is always introduced by a semicolon (;). Number formats The assembler can handle various types of number formats. To dier between them a prex must be used. These prexes are: 1. $ for hexadecimal numbers, 9
- 10. 1 Introduction to the Freescale DSP-Enviroment and the assembler 2. % for binary numbers, 3. and nothing for decimal or fractional numbers. 10
- 11. 2 Exercises 2.1 Create a project in Symphony Studio a) Open Symphony Studio. It will show the default perspective (C/C++). To open the debug perspective for the rst time you need to click Window - Open Perspective - Debug. After that both perspectives are shown in the upper right of the toolbar as described in section 1.1.1. Switch to the Debug perspective and open the view Memory by clicking Win- dow - Show View - Memory. Place the Memory view via drag and drop in the upper right of the window (in the frame with the Register view). Switch back to the C/C++ perspective. b) Generate a new managed ASM project named DSPLABV1. Add a source le named exp1.asm to the project with the following content: ;---------- preprocessor ---------- ;----- symbols ----- con1 equ 14600959 con2 equ %101111101110111111101101 con3 equ $000AB6 ;----- constants ----- org x:$0000 dc $0 dc $1 dc $2 dc con1 dc con2 dc %110111101111111011000111 ;---------- DSP program ---------- ;----- extension ----- ;----- main program ----- move x:$0,x1 ;comment this instruction move x:$5,x0 ;comment this instruction move x0,y:con3 ;comment this instruction move x1,y:$0000 ;comment this instruction 11
- 12. 2 Exercises move x:$3,x0 ;comment this instruction move x:$4,x1 ;comment this instruction move x0,y1 ;comment this instruction move x1,y0 ;comment this instruction move y0,x:$3 ;comment this instruction move y1,x:$4 ;comment this instruction ;-------------------- This source code can be found at C:DSP_labexp1source1.txt. As mentioned in section 1.2.3 the DSP program should start at p:$0100. Try to extend the source code (under ;extension) to full the restriction. Comment your extension. Hint: As the DSP starts executing the instructions at p:$0000, the rst line of the extension needs to be org p:$0000. 2.2 Compile and simulate source code a) Build the project and let the assembler generate the corresponding .cld le. b) Generate the External Tools to debug and to simulate the code. (The debug interface will be used in the following experiments) c) Generate a debug conguration for the project. d) Start the simulator interface and the debug conguration. Switch to the Debug perspective and control your extension made in exercise 2.1 by checking the Dis- assembly view. e) Watch the Disassembly, the Register, and the Memory (observe the memory spaces x:$000000 to x:$000005 and y:$000AB6) view. Step through the code and ll out table 2.1 for every object code address (in the Disassembly view the address is represented in the form 0x00000100) with the hexadecimal numbers stored in the registers and memory spaces listed in the table. Try to comment every instruction in the source code based on your observations. f) Import the le C:DSP_labexp1inc1.ext into your project and replace the part named main program in the source le exp1.asm by: ;----- main program ----- include '..inc1.ext' move x:$4,x0 include '..inc1.ext' move x0,x1 move x1,y0 12
- 13. 2 Exercises include '..inc1.ext' move x1,x:$0 ;-------------------- This source code snipped can be found at C:DSP_labexp1source1_1.txt. Rebuild the project. Note that the debug conguration needs to be suspended to change the .cld le. Restart the debug conguration and step through the program. Fill out table 2.2, with the object code address (address eld) for the corresponding instructions and the contents in the fractional representation of the listed memory spaces after the instruction is executed. Hint: The use of breakpoints in combination with Resume (F8) can be useful in this case. address X0 X1 Y0 Y1 x:$0003 x:$0004 p:$100 p:$101 p:$102 p:$103 p:$104 p:$105 p:$106 p:$107 p:$108 p:$109 p:$10a Table 2.1: Exercise 2.2 f) instruction address X0 X1 Y0 x:$0000 x:$0005 move x:$4,x0 move x0,x1 move x1,x:$0 Table 2.2: Exercise 2.2 g) 13