Site Index
   File Upload

Transfer Site
Main Site


The DSP/BIOS intro contains the following modules:

Topic Description

DSP/BIOS Overview

Project Component

DSP/BIOS Project Components

Managing CDB

DSP/BIOS Managing CDB Files and Projects

Program Flow

DSP/BIOS Program Flow

DSP/BIOS Overview

The BSL provides a C-language interface for configuring and controlling all on-board devices. The library consists of discrete modules that are built and archived into a library file. Each module represents an individual API and is referred to simply as an API module. The module granularity is structured so each device is implemented in an individual API module. The goal of the BSL is to provide a level of hardware abstraction and software standardization that improves development time and portability.

All of the examples that come with the EVM5502 use TIís DSP/BIOS. While the term DSP/BIOS refers to the operating system itself, the process of creating and maintaining a DSP/BIOS project actually involves a wide variety of different Code Composer Studio components which can also be used independently without the operating system. For example, DSP/BIOS manages device configuration through a graphical configuration manager but the resulting device initialization is implemented through the Chip Support Library (CSL).

This section is a brief introduction into the components that make up a DSP/BIOS project. It is only intended as an introduction and an organized way to point to Code Composer documentation that covers each feature in much more details. It must be noted that DSP development has a learning curve and cannot be mastered in just a few hours. If you are new to DSP development plan to spend plenty of time reading through the Code Composer documentation and experimenting on your own.

The following are good places to find more detailed information about DSP/BIOS:

  • DSP/BIOS Product DemoA narrated slideshow that walks you through the major DSP/BIOS components. You can view it by starting the Code Composer help, selecting Product Demos in the help pane on the right, then picking the DSP/BIOS demo.

  • DSP/BIOS Help FileA good starting point for DSP/BIOS users. Contains a tutorial and To view.

  • DSP/BIOS Userís Guide (SPRU423b)The best place to find details about DSP/BIOS, a several hundred page reference. It can be found on the TI web site or in the docs/pdf directory of your Code Composer install.

DSP/BIOS Project Component

The main components of any DSP/BIOS project are displayed below:

Click Image to Enlarge

The following describes each of the project components. It is assumed that the reader is already familiar with C programming. For best results, open the evm_app project now so you can experiment as you read along.

Basic Organization
A normal C program typically has a number of source(*.c, *.asm, *.s) and header files(*.h) that get compiled into binary object files and linked with a run-time library to form a program executable. A project file (*.pjt) describes how the source code components fit together and a linker command (*.cmd) file describes how the object and library files fit together to create the executable program in memory.

DSP/BIOS adds a new type of file called a DSP/BIOS configuration file (*.cdb). The configuration file contains settings for each of the DSP/BIOS modules. You can access the configuration file through a graphical interface (called gconf) by double-clicking on the .cdb file in the DSP/BIOS Config section of the project view. As you can see, the configuration file contains everything you need to set up a good working environment for your code memory management and layout (System -> MEM), interrupt vector table (Scheduling -> HWI) and on-chip peripheral setup (Chip Support Library). All DSP/BIOS programs use a configuration file.

When a .cdb file is compiled, a number of files are generated based on the settings it contains. The generated files are included with your project to perform DSP/BIOS initialization of each module shown in the graphical configuration tool. If you look closely at the files youíll see that they are simply human readable source files just like your own code. The auto-generated files are used to minimize the complexity users need to see when integrating so many modules with such different functions. Consistency checking between modules that might have conflicts is done in the graphical configuration tool while you are editing it.

DSP/BIOS Auto-Generated Files

File Name Description

evm_appcfg.h55 & evm_appcfg.s55

Module specific variables for internal DSP/BIOS usage.


CSL module configuration structures and calls. Contains one function called CSL_cfgInit() that contains calls to initialize each peripheral module with the appropriate constant or configuration structure. This file is particularly interesting when debugging because it allows you to see exactly how each peripheral is being configured. The auto-generated code replaces initialization code you would normally have to write yourself. There is nothing DSP/BIOS specific about this file other than the process by which is was generated. The same CSL code can work in non-BIOS programs.


Header file containing definitions and referencing and required CSL header files. This file must be included in your application code so your application interfaces correctly with the CSL.


A linker command file that includes all DSP/BIOS objects needed to run your program. Also includes your application source files based on your project settings and specifies where in memory each section should appear. A DSP/BIOS version of the C runtime library is automatically included, do not add the normal C runtime library rts55x.lib to your project. Unlike other generated files, the .cmd file must by manually included as part of your project using the Project -> Add to Files to Project menu option.

Managing CDB Files and Projects

By far, the easiest way to start your own projects is to copy one of the BSL example project directories to a new place and rename all of the files to match your new application. It is HIGHLY recommended that you follow this route because the example .cdb files are already configured to take advantage of features on the EVM5502.

If you choose to create your own CDB files there are two distinct paths, creating one from a seed file and creating one with tconf.

Creating CDB Files Manually
All user CDB files start as a CDB seed file. It is a CDB file with only the most basic settings for your particular hardware platform configured. To create a CDB file, select File -> New -> DSP/BIOS Configuration and you will be prompted to select a seed file to start with. The tool will open the CDB configuration tool and you can save the file under any name you choose.

Creating CDB files with Tconf
TextConf(Tconf for short) is a script-based language used to manage CDB files. Tconf scripts contain text based commands that modify the modules within a CDB file. When you run a tconf script, the CDB seed for the EVM5502 is used as a foundation, the script command are applied and the resulting CDB file is written in a form that can then be included in your project. Tconf details can be found in the DSP/BIOS TextConf User's Guide (SPRU007).

Each of the BSL examples contains tconf scripts (*.tcf) that apply the differences needed to re-create their CDB files from the base seed. Instructions on how to run tconf are included in each .tcf file

Adding CDB Files to a Project
Use the Project -> Add Files to Project to include your CDB file in your project. If you do not see the CDB file in the file browser, make sure the "Files of type" selector is set to .cdb files. When you add a CDB file to a project, Code Composer is smart enough to include most of the auto-generated files automatically in your project when the .cdb file is compiled. The only two files you usually need to worry about are appnamecfg.cmd which also needs to be manually added to your project (Project -> Add Files) and appnamecfg.h which needs to be included in your C source files with a line like:

#include "appnamecfg.h"

If you look in your project view you will see many include files. Most of them are not auto-generated files that you have to manage, they are simply headers for library modules that get referenced along the way and never change.

Program Flow

One of the critical pieces of information you need while debugging is knowledge of the state of the processor. A target like the EVM5502 is an independent entity that runs on its own, Code Composer is simply a tool that gives you insight into whatís going on. This is different that programming on a PC where the program environment is virtualized and every program starts with a clean slate when it is run.

Before a Program is Run
When the EVM5502 is first turned on, the DSP starts loading code based on the boot mode that has been selected. When shipped from the factory, a small demo is programmed into Flash and the jumpers are set to boot out of Flash. The demo keeps running until Code Composer is started.

When Code Composer is started, it halts the DSP through the JTAG interface and runs the StartUp() function in your .gel file. In this particular .gel file the DSP is reset, a memory map is set up to tell Code Composer which memory regions are valid for access and the EMIF is configured so all of the on-board devices can be seen. As you can tell, the state of the DSP when you first open Code Composer is significantly different than what you would expect just coming out of reset.

To view the true initial processor state you need to put the DSP in no boot mode and modify your .gel file so that the DSP is not reset and the EMIF is not initialized.

After You Start a Program Running
When a DSP/BIOS program is run, many things take place before the first line of main() is executed. The program starts running at the symbol c_int00, the beginning of the DSP/BIOS version of the C runtime library. This initializes things like the stack, constants and intial values of global variables. After the C runtime is complete, two paths may be taken based on whether the DSP/BIOS Task Manager is enabled or not. This setting is enabled in the Scheduling section of your .cdb file. Right click on TSK - Task Manager and view its properties. The Task Manager must be enabled to use DSP/BIOS Tasks. Threads can still be used in either case.

If the Task Manager is disabled, DSP/BIOS is started and the function CSL_cfgInit() in appnamecfg_c.c is called to set up the on-chip peripherals using the CSL. Control is then passed to main(). When main() exits, control is passed back to the DSP/BIOS scheduler which allows things like periodic threads to run.

If the Task Manager is enabled, the main() function is called before DSP/BIOS is fully initialized and the peripherals are set up. In this case, main() is used simply as a place to put user initialization code. When main() returns, DSP/BIOS will be fully initialized and the function CSL_cfgInit() in appnamecfg_c.c will be called to set up the on-chip peripherals. At the end of the process, the scheduler will be enabled.

It is important to note that the main() function is used primarily as a place to do initialization in a DSP/BIOS program. The real work is expected to be placed in tasks and threads.

©Copyright 2002-2011 Spectrum Digital, Inc. All Rights Reserved.