Debugging with Code Composer

Before starting to debug a Diamond application, ensure that Code Composer is installed and that you can connect to and debug the target C6000. Some DSP boards have on-board emulators that let you debug them directly, others need external hardware, such as TI’s XDS510.

Note that before Code Composer is started for the first time after each power-on, you may need to run a board-specific initialisation program. Refer to the board vendor’s documentation for details.

The following discussion covers building Diamond applications from the command line; refer to the IDE section for information on building for debugging in that environment.

Recompile all modules with debug information generation enabled. You do this by adding the option --symdebug:coff to the compilation command. For example:

» 3L C test.c --symdebug:coff

Link each task as usual using 3L T or its variants.

Configure the application with the -G option:

» 3L A test -G

This instructs the configurer to emit debugging information for your application in the form of symbol table files for each task and GEL files for each processor. The name of each symbol table file is the task name with .out appended. The configurer also generates debug files for system components, mainly the kernel; these are usually of little interest to most users. The following example creates a symbol table file called first.out:

TASK first FILE="second.tsk"

The symbol table files are created in the sub-folder debug of the current output folder.

Two sets of symbol tables are generated.

	debug\single\*.out	These symbol tables correspond directly to the compilation of the task. The names of the symbols in the program are not altered, so each define the symbol main, for example.
	debug\all\*.out	These files have had the names of relevant symbols modified by the addition of a prefix derived from the task name. For example, a function fn in a task test would be renamed test_fn. This is useful if you wish to debug having loaded the symbol tables for more than one task.

The configurer also generates a GEL file for each processor in your application; GEL files can be used in Code Composer to control and simplify debugging. The files are created in the same folder as your .app file and have names of the general form:

processor-name.gel

Start Code Composer and connect to the target board or boards. If no Diamond application has been run since the board was powered up, you may need to run a board-specific initialisation program first.

Open a processor you wish to debug. Go to the File menu and select Load GEL... Browse to the folder containing your .app file and select the .gel file for the processor in question.

Let the processor run by selecting Run Free from the Debug menu.

Repeat steps 5 and 6 for every processor you wish to debug in the current session.

Start the server WS3L if it is not already running.

Select debug mode by clicking View/Options, selecting the General tab, and ticking the Debug application box.

10.

Select your application and start it running. If you have more than one DSP board in your PC you may have to select the correct one before starting your application.

11.

Wait for the Paused pop-up message to appear. This means that the server has loaded your application into all the processors and they are now waiting for you to start debugging.

12.

For each processor of interest:

•	Click GEL in Code Composer's main menu. This brings up four options:

1.	Load symbols for all user tasks This makes all user tasks available for symbolic debugging. A breakpoint is set for each task on its main function (with a name suitably modified as described in point 3 above). Symbol tables are loaded from the debug\all folder.
2.	Load symbols for all tasks This is the same as option one above but system tasks and the kernel are included. Breakpoints are set only on user tasks. Symbol tables are loaded from the debug\all folder.
3.	Load individual task symbol table This can be used to load the symbol table for an individual task and set a breakpoint on its main function. The symbol table is loaded from the debug\single folder. You can repeat this during debugging to switch from one task to another; loading a symbol table causes any existing symbol table to be unloaded.
4.	Start processor. It will wait for OK from the server This sets your processor running (although you won't notice anything happening because all your processors are held waiting for the server).

13.

Return to the server window and click OK in the Paused window. Your application starts to execute and runs up to the first main with a breakpoint. Debugging can now continue with Code Composer.

Some TI processors are extremely sensitive to being reset while connected to Code Composer, so you should always disconnect every processor using Debug/Disconnect before leaving Code Composer. If you forget to do this, your board may not respond after being reset by the Diamond server when you next try to run an application. If this happens, go back into Code Composer and disconnect all the processors then reconnect them. If this fails to resolve the problem you will have to close Code Composer and restart it.