Skip to content Skip to navigation

Connexions

You are here: Home » Content » TI Code Composer Studio V2.x Primer

Navigation

Content Actions
  • Download module PDF
  • Add to ...
    Add the module to:
    • My Favorites
    • A lens
    • An external social bookmarking service
    • My Favorites (What is 'My Favorites'?)
      'My Favorites' is a special kind of lens which you can use to bookmark modules and collections directly in Connexions. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need a Connexions account to use 'My Favorites'.
    • A lens (What is a lens?)

      Definition of a lens

      Lenses

      A lens is a custom view of Connexions content. You can think of it as a fancy kind of list that will let you see Connexions through the eyes of organizations and people you trust.

      What is in a lens?

      Lens makers point to Connexions materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

      Who can create a lens?

      Any individual Connexions member, a community, or a respected organization.

    • External bookmarks
  • E-mail the author

Recently Viewed

This feature requires Javascript to be enabled.

TI Code Composer Studio V2.x Primer

Module by: Hyeokho Choi

Summary: This module is a primer for the hardware and software to write, debug, and run DSP programs on the TI C6211 DSP Starter Kit (DSK) board.

Introduction

This module introduces you to the hardware and software tools that you use to write, debug, and test real-time DSP programs on the TI C6211 DSP Starter Kit (DSK) board. You will compile, run, and debug a C program to try various functions of the development tool Code Composer Studio. In this module, we use a C program only for convenience. You can assemble and run assembly programs in the same way.

Lab Equipment

Each lab PC is equipped with a Texas Instrument TMS320C6211 DSK board. The DSK board is hooked to the parallel port of the PC running Windows 2000; the PC can control the DSK via the development environment called “Code Composer Studio” (CCS) developed by Texas Instrument. Currently we use CCS version 2.x. If you have your owlnet account, create the Samba password to log in to the machines.

For analog signal input and output, the DSK board has a PCM3003 codec daughtercard mounted on the board. This board provides 16 bit stereo analog input and output channels at maximum sampling rate of 48kHz. Currently, the jumpers on the board are configured to provide a fixed 48kHz sampling rate both for input and output. Do not change the jumper settings unless you know what you are doing. For variable sampling rates, the timers of the C6211 processor can be used to generate appropriate clock signal. You will learn how to use the CPU timers in (Reference).

Each lab station is equipped with a function generator to provide signal to be used to test your signal-processing algorithms and an oscilloscope to display the processed waveforms.

The source analog signal also can be generated using the soundcard of the PC and input to the DSK board for processing. There are two shareware softwares installed on each PC that enables you to use the sound card as a signal generator and a simple spectrum analyzer. In the lab experiments, you will be using the signal generator to generate white noise input to the DSK board and you can watch the spectrum of the DSK output using the soundcard spectrum analyzer.

Hardware Setup

The TI DSK board is connected to the parallel port of the PC. The board requires external power supply to be connected to it. A speaker and microphone can be connected to the board via the two 3.5mm jacks mounted on the daughtercard that are connected to the PCM3003 codec. The hardware reset button (white) is on the DSK board to enable hardware reset of the board. When reset the board goes through several steps of self testing and initialization. Please refer to the online help of the Code Composer Studio for detailed board operation. After each hardware reset, the DSK board tends to lose the connection with the host PC. Therefore, you should close the CCS before performing hardware reset. Be sure to save all the files before closing the CCS. After the DSK board finishes the reset, start the CCS again.

Be careful when you handle cables, tools, etc, not to short any circuits on the board.

Configuring CCS for C6211 DSK

Before the initial use of CCS, you must configure it so that it correctly connects to our C6211 DSK board. Once you configure it correctly, your configuration is saved as default and CCS will bring up the saved default configuration every time you start CCS.

Run the CCS configuration tool for configuration. You first need to choose C6211 DSK as the processor and then you can choose the type of serial port to which the DSK is connected. Make sure you do not run your code on a simulator. For any code that does not use the I/O on the board, the code would run exactly same way on the simulator as it would on the real DSK board.

DSK Self-Confidence Test

When the DSK board is connected to the host PC and the power is on, you can run a self test to check if everything works fine. Simply run C:\ti\c60OO\dsk6x11\conftest\dsk6xtst.exe from the command prompt. The test checks all the functions of the board and report errors, if any. When you are in doubt about the proper functioning of the DSK, it is a good idea to run the self-confidence test to make sure it passes without any error.

If the board fails the test, unplug the power plug to the DSK for several seconds and plug it again, then run the test again. The DSK board sometimes does not reset all the circuits properly when the power is turned on.

Development Environment

The DSK board is controlled by the host PC via the parallel port connection, using the application Code Composer Studio (CCS). The CCS allows the user to download and run the assembled/compiled code. The CCS also provides environment for C/assembly code development, compilation, and debugging. Begin by working through the steps below to familiarize yourself with the programming and debugging environment of real-time systems.

Compiling and executing Code

In this part of the lab, you will be using the Code Composer Studio to load example source files, build (compile and link) them, download the code to DSK board, and then execute it. Follow the step-by-step instructions, typing in the commands as they appear below.

  • Do This: First, log into your PC. Make your own working directory in your owlnet directory. Download the lab1 file lab1+ zip from the web page. The zip file contains the example codes you load and test in this lab.
  • Do This: Unzip the Lab1.zip file under your working directory.
  • Do This: Create the Lab1 project by doing the following:
    1. Open the Code Composer Studio.
    2. Create a new project called lab1.prj.
    3. Add the following files from your Lab1 to your project: labl.c, vectors.asm, and c6211dsk.cmd. Also, add the following Run-Time Support Library: C:\ti\c6000\cgtools\lib\rts62ol.lib
    The C code lab1.c computes the dot product of two length 10 vectors defined in data.h. The two vectors are defined in the include file data.h: 
    
1       #define A_ARRAY 1,2,3,4,5,6,7,8,9,10
2	#define X_ARRAY 256,255,254,253,252,251,250,249,248,247
  • Do This: Run the code generation tools (compile, assemble, link)
    1. Run the code generation tools from within the Code Composer to generate the compiled executable code that is easy to debug. You can configure the compiler options using PROJECT:OPTIONS menu. Many of the options are already set to default by the CCS before you change them manually. For the time being, the only options you might want to change are the Obj Directory under Compiler option to change the directory where the generated .obj files are stored and the Output Filename under Linker option to change the directory and filename of the output executable files (.out files). By default, the object and executable files are stored in a subdirectory named DEBUG under your working directory. For detailed explanation of the options, please refer to the online help of Code Composer.
    2. Build the executable file (Labl.out); PROJECT:REBUILD ALL (You can also use the REBUILD ALL toolbar icon.)
  • Do This: Load the code and execute it:
    1. Load the executable (lab1.out) by doing: FILE: LOAD PROGRAM… (if, for some reason, you have to quit the Code Composer before completing this lab, load the project (labl.prj) before loading the executable.)
    2. Once you load an executable program using FILE:LOAD PROGRAM…, the CCS remembers the file name that was loaded last time. To load the same executable again later, you can simply use: FILE:RELOAD PROGRAM This is easier than using FILE:LOAD PROGRAM… because you do not need to specify the file name.
    3. If needed, you can reset the CPU (by software) by the DEBUG:RESET CPU menu command. After the reset, you should reload your program code again.
    4. Execute the code by running the main function, using: DEBUG : RUN
    5. What is the result you obtain in the stdout window of the Code Composer?
    You may have noticed that there are several commands under the DEBUG menu that relates to program execution. Here’s a short explanation of each of them:
    • Run: starts execution of the program at the current program counter (PC). The PC has the address of the instruction that was to be executed before halting the CPU. To re-start your program from the beginning, you must set the PC to the start address (we call it entry point) and then you use the RUN command.
    • Restart: resets the PC to the program entry point. In C, the program entry point is always the start of the main() function. (more precisely, it is the initialization routine right before the main() function). In assembly, you can specify the entry point to be an address defined in your assembly program when you set the assembler options. Therefore, to restart your program from the beginning, you have to Restart and then Run.
    • Go Main: sets a breakpoint at the start of the main() function and runs the CPU. The execution will halt at the breakpoint. This could be a convenient way to set the PCI at the main() entry point of a C program. However, if the current PC is at a wrong place, the CPU may execute meaningless code, resulting in undesired result. For this reason, we do not recommend using Go Main in this course.

Debugging

Now it’s time to verify if it is logically correct. This section describes how you can watch the contents of variables or set breakpoints and step through the code.

Watching Variables- Do This

The CCS has the functionality to watch the contents of variables used in your code. Open the watch window by doing: VIEW:WATCH WINDOW The watch window can be docked to the bottom or side of the Code Composer window or it can float anywhere in the window. Right-click in the window to see the options. Place it however you prefer.

  1. You should see the Watch 1 tab under the watch window. Click the Watch 1 to select it. You can generate more tabs with different names by right clicking the watch window and doing Add Tab...
  2. Add y y to the watch window. You can click the Name column of the highlighted row in the watch window and then type the variable name ( y y) and press enter to add the variable.
  3. Add five more values to the watch window from the dot product subroutine: 
    i, m[i],  n[i],  product, sum
    Each variable will correspond to different rows in the watch window. To add each variable, click the Name column of the blank row.
  4. Do DEBUG:RESTART to set the PC at the beginning of the code.
  5. Execute the program and see how the variable contents are displayed.
Note that if you received an error “identifier not found” in the value column when adding some of the variables, it’s probably due to the scope of the variable. Local variables do not exist until their function is called. CCS will add them to the watch window, but will indicate they aren’t valid until the function is reached.

You can also change the display method of the variables. Click the Radix column of each variable to change to display method.

Note that the watch window does not update the variable values until the CPU finishes the execution and halts. Because i i is a local variable, it is not visible both at the start and the end of execution. Therefore, you will see “identifier not found” all the time. The values of local variables are updated when the CPU halts while inside the function the variables are defined.

Single Stepping and Break Points

DO THIS
  1. Do DEBUG:RESTART to set the PC at the beginning of the code.
  2. Try single-stepping code: DEBUG:StepInto or F8 or click the toolbar icon.
  3. Once you’ve had your fill of single-stepping, try running the processor: DEBUG:RUN or F5 or click the toolbar icon.
  4. After the processor reach the end of the program, it keeps running by going into an exit routine. You can check the status bar in the lower left corner to see if the processor is still running. You should see either DSP RUNNING or DSP HALTED.
  5. If the processor is running, halt it by doing: DEBUG:HALT or shift-F5 or click the toolbar icon.
DO THIS
  1. Do DEBUG:RESTART to set the PC at the beginning of the code.
  2. Set a break point at any line inside the dotp function by placing the cursor at the desired line and right-clicking and then choosing the toggle breakpoint in the menu.
  3. Run your code. The execution will stop at the breakpoint.
  4. Using the watch window, watch the value of the variable yy. Every time the execution stops, the watch variable values are updated.
  5. If you click the Watch Locals tab under the watch window, you can watch all the local variables. You do not need to add the local variables. All of them are displayed automatically.

Animating Code

Although you can see how the contents of variables change by single-stepping the code, it can take a long time to execute all the code. On the other hand, when running the code, you cannot watch the variables updated on the fly. The "animate” feature solves this problem.

The animate feature requires you to set a breakpoint. When it reaches this breakpoint, code execution stops long enough to update the display and then resumes execution automatically.

DO THIS
  1. Do DEBUG:RESTART to set the PC at the beginning of the code.
  2. Add a break point to any line of the code in the dotp subroutine: Open lab1.c and search scroll down to the dotp function. Click on the statement product=m[i]+n[i]; Right-click to TOGGLE BREAK PT on the line that contains the cursor (Rather than right-clicking, you can also use the toolbar icon.)
  3. Run with animation: DEBUG:ANIMATE or F12 or click the toolbar icon.
After the processor finishes running main() function, it goes into running the exit routine. Go ahead and HALT the processor.

Benchmarking/Profiling Code

Code Composer Studio has the capability of benchmarking your code, meaning that you can analyze how long your code takes to execute. In the following example, you will be analyzing how long it takes to execute each call of the dotp() function.

One way of benchmarking your code is to set two breakpoints. When you run the program, the breakpoints will tell the debugger to stop execution. A clock-cycle counter, built into the debugger, can be used to count the number of cycles between these breakpoints.

DO THIS
  • Do DEBUG:RESTART to set the PC at the beginning of the code.
  • Choose PROFILER:START NEW SESSION... with session name of your choice.
  • You can profile, count the number of clock cycles, a function by adding it to the profile session you created. To do this, left double click on the lab1.c file in the Project View to view the file. Place the cursor on any line inside the dotp() function and right click. Choose Profile Fimction -> in (session-name) Session, where (session—name) identifies the profiling session you created.
  • Execute the code by DEBUG:RUN.
  • After CPU halts, click on the Functions tab of the profiling window to see the result of the profiling of the dotp() function.
  • The numbers displayed are the statistics of the execution of the dotp() function gathered by CCS while executing the code.
  • For interpretations of these numbers, read the CCS help topic Profiler:Viewing Profile Data by choosing the Help:Contents menu on the CCS menu bar.
  • You can also add a particular line of the code to the profile session. Learn how to do this by reading the helps. There are lots of profiling capabilities that cannot be covered fully in this manual.
  • How many clock cycles (on average) does it take to execute the dotp() function?

Troubleshooting

The DSK board is sometimes temperamental. If there is no output, try the following (from less to more drastic):

  • Use the Debug menu to halt the DSP. Reset CPU by doing DEBUG:RESET CPU, reload the coder and restart the code.
  • Exit Code Composer Studio. Hit the white reset button on the DSK. Then start over from starting CCS and loading the project and the program.
  • Close the Code Composer Studio, unplug the power plug from the DSK board, then plug it back in. Restart the Code Composer Studio. Then, reset the DSP, reload code, and execute your code.

However, when you reset (software or hardware), the host PC tends to lose the connection to the DSK board. If this happens, you need to quit and restart the Code Composer Studio.

If you encounter problems that result in your code not loading correctly, or any software reset not working properly, close the Code Composer Studio and unplug the DSK. If problems persist after unplugging the DSP and plugging it back in, verify that the DSK board is functioning properly by executing known good code. If you try all of these steps and the DSK board is still not functioning, contact a TA to ask for assistance.

In my experience, these are some of the things you can do to screw up either the DSK, CCS, or the connection between the host PC and DSK:

  • Trying to load a program while the CPU is still running. This will almost surely end up with a disastrous condition so that you need to close the CCS and reset DSK and start from the beginning.
  • Using Run command without properly setting the program counter first. If the PC happened to be at an improper address, the CPU starts executing some garbage, eventually doing some weird things. It is always a good idea to issue Restart before issuing the Run command.

Using PC Soundcard

Using the signal generator and spectrum analyzer softwares installed on each PC, you can use the PC sound card as a signal generator/analyzer.

Signal Generation Using Sound Card

DO THIS

  • Run the signal generator(play.exe). Generate different signals at different frequencies. You will be able to hear the generated signal through the internal speaker of the PC.
  • Generate a sine wave at 1kHz and view the generated signal using an oscilloscope by connecting an audio cable to the speaker output jack on the back of the PC and connecting the oscilloscope probe at the other end of the audio cable.
  • Generate a white noise and view the signal. What does it look like?

Spectrum Analyzer

DO THIS

  • For proper functioning of the spectrum analyzer, you need to set up the PC volume control properly. Mute the microphone playback through the PC speaker. Then, set the microphone and line input volumes at the middle so that the signals are in the correct input range. Sometime you lose input to the microphone jack and need to click the volume control slide bar to activate it.
  • Generate a 1kHz sine wave using the soundcard tone generator and connect the output to the PC microphone input using a cable.
  • Run the spectrum analyzer (File -> Scan Input) and view the spectrum of the signal.
  • Try different plots of the frequency spectrum (scroll, line, bar). What do the display represent? Can you estimate the frequency of the generated sine wave from the displayed spectrum?
  • Try different setting of the parameters for the spectrum analyzer. Change FFT window size, Spectrum average, etc., and see how this affects the display. Refer to the help file for the spectrum analyzer program.
  • Generate white noise and view the spectrum. What does it look like?
  • If you would input the white noise to a low pass filter and watch the spectrum of the filter output, what would you see?

Using MATLAB To Generate Signals

You can use MATLAB to generate any arbitrary sound through the soundcard. The matlab function sound plays a MATLAB vector as sound using the sound card. It can also play stereo sound, too. For example, you can record a sound file in the .wav format using a windows utility through a microphone connected to the soundcard. Then, you can read in the .wav file into matlab using the matlab function wavread. Then, you can play the sound over and over again to use MATLAB as a very flexible sound source.

References

These references are available on your lab stations or on TI web page:

  • Code Composer Studio User’s Guide (SPRU328B)
  • TMS320C6000 Code Composer Studio Tutorial (SPRU301C)
  • TMS320C6000 Optimizing C Compiler User's Guide (SPRU187G)
  • TMS320C6000 Programmer’s Guide (SPRU198D)
  • TMS320C6x C Source Debugger User's Guide (SPRU188D)

Comments, questions, feedback, criticisms?

Send feedback