Trademarks

PC is a trademark of International Business Machines Corporation.

Samtec is a trademark of Samtec Incorporated.

Windows is a trademark of  Microsoft Corporation.

TI, XDS510 are trademarks of Texas Instruments Incorporated.

The Texas Instruments logo, Code Composer Studio, DSP/BIOS, eXpressDSP, Probe Point(s), TMS320, TMS320C6000, TMS320C5000, and TMS320C2000 are among the trademarks of Texas Instruments. See the Texas Instruments web site for a list of trademarks and registered trademarks belonging to Texas Instruments.

All other product, services names and registered trademarks are the property of their respective owners.


Disclaimer

Spectrum Digital Incorporated (SDI) reserve the right to make changes to their products or to discontinue any product or service without notice, and advise customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability.

SDI warrants performance of its products to the specifications applicable at the time of sale in accordance with SDI's standard warranty. Testing and other quality control techniques are utilized to the extent SDI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements.

Customers are responsible for their applications using SDI components.  In order to minimize risks associated with the customer's applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards.

SDI assumes no liability for applications assistance or customer product design. SDI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of SDI covering or relating to any combination, machine, or process in which such products or services might be or are used. SDI's publication of information regarding any third party's products or services does not constitute SDI's approval, license, warranty or endorsement thereof.

Reproduction of information in data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations and notices. Representation or reproduction of this information with alteration voids all warranties provided for an associated SDI product or service, is an unfair and deceptive business practice, and SDI is not responsible nor liable for any such use.

Resale of SDI's products or services with statements different from or beyond the parameters stated by SDI for that product or service voids all express and any implied warranties for the associated SDI product or service, is an unfair and deceptive business practice, and SDI is not responsible nor liable for any such use.

Mailing Address:

Spectrum Digital Incorporated
Post Office Box 1559
Sugar Land, Texas 77477-1559

Copyright © 2002, Spectrum Digital Incorporated


Acronyms

API	Application Programming Interface
BSL	Board Support Library
BOM	Bill of Materials
CCS	Code Composer Studio
CSL	Chip Support Library
CMOS	Complementary Metal Oxide Semiconductor
CODEC	Coder-Decoder
CPLD	Complex Programmable Logic Device
CPU	Central Processing Unit
DARAM	Dual Access Random Access Memory
DIP	Dual In-line Package
DMA	Direct Memory Access
DSP	Digital Signal Processor
EMIF	External Memory InterFace
HPI	Host Port Interface
IDE	Integrated Development Environment
IEEE	Institute of Electrical and Electronic Engineers
JTAG	Joint Test Action Group
LED	Light Emitting Diode
McBSP	Multi-Channel Buffered Serial Port
MHz	Megahertz
NMI	Non-Maskable Interrupt
OS	Operating System
PC	Personal Computer
POST	Power On Self Test
PLL	Phase Locked Loop
PQFP	Plastic Quad Flat Pack
ROM	Read-Only Memory
SDI	Spectrum Digital Incorporated
SARAM	Single Access Random Access Memory
SRAM	Static Random Access Memory
SDRAM	Synchronous Dynamic Randon Access Memory
TI	Texas Instruments
TTL	Transistor-Transistor Logic


Hardware Overview

The main features of the 6713 DSK board are listed below.  Click on an area of interest on the block diagram or see the feature list below for more details.  Look here for a complete board description.

Feature	Details
TMS320C6713 DSP	225 MHz, floating point, 256 Kb internal RAM/Cache
CPLD	Programmable "glue" logic
External SDRAM	16 Mbytes, 32-bit interface
External Flash	512Kbytes, 8-bit interface (256Kb usable)
AIC23 Codec	Stereo, 8KHz –96KHz sample rate, 16 to 32 bit samples, mic, line-in, line-out and speaker jacks
4 User LEDs	Writable through CPLD
4 User DIP Switches	Readable through CPLD
3 Configuration Switches	Selects power-on configuration and boot modes
Daughtercard Expansion Interface	Allows user to enhance functionality with add-on daughtercards
HPI Expansion Interface	Allows high speed communication with another DSP
Embedded JTAG Emulator	Provides high speed JTAG debug through widely accepted USB host interface


C6713 DSK Board Description

The 6713 DSK is a low-cost standalone development platform that enables customers to evaluate and develop applications for the TI C67XX DSP family.  The DSK also serves as a hardware reference design for the TMS320C6713 DSP.  Schematics, logic equations and application notes are available to ease hardware development and reduce time to market.

The DSK uses the 32-bit EMIF for the SDRAM (CE0) and daughtercard expansion interface (CE2 and CE3).  The Flash is attached to CE1 of the EMIF in 8-bit mode.

An on-board AIC23 codec allows the DSP to transmit and receive analog signals.  McBSP0 is used for the codec control interface and McBSP1 is used for data.  Analog audio I/O is done through four 3.5mm audio jacks that correspond to microphone input, line input, line output and headphone output.  The codec can select the microphone or the line input as the active input.  The analog output is driven to both the line out (fixed gain) and headphone (adjustable gain) connectors.  McBSP1 can be re-routed to  the expansion connectors in software.

A programmable logic device called a CPLD is used to implement glue logic that ties the board components together.  The CPLD has a register based user interface that lets the user configure the board by reading and writing to the CPLD registers.  The registers reside at the midpoint of CE1.

The DSK includes 4 LEDs and 4 DIP switches as a simple way to provide the user with interactive feedback.   Both are accessed by reading and writing to the CPLD registers.

An included 5V external power supply is used to power the board.  On-board voltage regulators provide the 1.26V DSP core voltage, 3.3V digital and 3.3V analog voltages.  A voltage supervisor monitors the internally generated voltage, and will hold the board in reset until the supplies are within operating specifications and the reset button is released.  If desired, JP1 and JP2 can be used as power test points for the core and I/O power supplies.

Code Composer communicates with the DSK through an embedded JTAG emulator with a USB host interface.  The DSK can also be used with an external emulator through the external JTAG connector.


Embedded USB Emulator

The DSK has a special JTAG emulator embedded on board that works specifically with the DSK hardware and the version of Code Composer that ships with it.  When designing your own hardware, you will need the full version of Code Composer and a full external JTAG emulator to talk to it.  The DSKs were developed to give a large number of users low-cost access to TI DSPs for evaluation and code development purposes in the same framework as the full strength tools so when you migrate to the full tools you will experience the same target behavior.

The embedded USB emulator communicates with your host PC through a USB 1.1 compatible interface.  The emulator is responsible handling JTAG debug traffic between the DSP and your PC.  The debug is transparent, the DSP on the DSK cannot see either the emulator or the USB port.

USB Port Pinout

Pin Name	Usage	Description
1	USB VDD	USB Output Voltage
2	D+	Differential Data Positive
3	D-	Differential Data Negative
4	USB VSS	Ground
5	Shield	Cable shield
6	Shield	Cable Shield


JTAG Emulation Overview

JTAG refers to a set of design rules that encompass testing, programming and debugging of chips.  The JTAG interface allows a user to examine signals and registers on a chip through an external interface that only uses five extra pins on the chip.  In a TI DSP development environment Code Composer uses the JTAG interface to debug programs non-intrusively through a hardware device called a JTAG emulator.  Benefits of JTAG based debug include:

•	Your target hardware can be debugged in just as if it were a finished product.  You don’t need a special version of your hardware with debug features such as chip test clips or test points to expose signals or EEPROM sockets to hold code while you try it out.

•	You don’t need any special software running on your target hardware.  Many systems use a ROM monitor to transfer debug information from the host to the target.  But since the monitor itself uses resources like memory, interrupt vectors and things like serial ports, your application must be written with the ROM monitor in mind so it doesn’t conflict with the monitor and kill your debug session.

•	It is much faster and more flexible.  You have full access to all of the internal chip state at the same time, not just what your debug output happens to monitor.  You can load code directly into memory as soon as you have your hardware and immediately take a look at the internal state.  It is much faster than the old "burn and learn technique" where you burn a program you think will work into an EEPROM, put the EEPROM into a socket on the board and see what the program does.  If it doesn’t work you stare at the code until you figure out what’s wrong and keep trying.

•	On TI DSP platforms you have a high degree of tool re-use across different DSPs and hardware targets.  TI DSPs use a standard 14 pin header across their C2000, C5400, C5500, C6400, C6200, C6400, C6700 and ARM chips so you can use the same JTAG emulator across processor families (provided you have the correct emulation drivers and Code Composer for that family).


External JTAG Header

While the DSK has an embedded USB emulator, a TI standard 14 pin external JTAG emulator header (J7) is also included so you can use the DSK with an external emulator.  When an external emulator is plugged into the header, on-board multiplexors will automatically disable the embedded emulator and pass through the external emulator signals.  The "USB in use" LED (D6, near the external JTAG header) is lit if the embedded USB emulator is enabled and off if an external emulator is detected.

External Emulator Header Pinout

Pin	Function
1	TMS
2	TRST
3	TDI
4	GND
5	VCC (+3.3V)
6	No connection
7	TDO
8	GND
9	TCK
10	GND
11	TCK
12	GND
13	EMU0
14	EMU1


TMS320C6713 DSP Overview

The DSK supports a TMS320C6713 DSP which can operate at a clock frequency of up to 225 MHz.  The DSP core is designed for high performance floating point operation .  Beyond the DSP core, the ‘6713 integrates a number of on-chip resources that improve functionality and minimize hardware development complexity.  Features of the processor include:

•	VLIW Core – VLIW is a processor architecture that allows many instructions to be issued (8 on the 6713 DSP) in a single clock while still allowing for very high clock rates.  VLIW architectures can achieve extremely high processing rates but put more burden on the compiler to schedule concurrently executed instructions.  The code generation tools that come with Code Composer are heavily optimized for this architecture to relieve as much of the optimization burden from the programmer as possible.

•	192Kbytes Internal Memory – high speed internal memory for maximum performance.

•	64Kbytes L2 Cache/RAM – four 16Kbyte blocks of internal RAM that can be configured as RAM or cache.

•	4Kb Program/Data Caches – separate caches for program code and data.

•	On-chip PLL – generates processor clock rate from slower external clock reference.

•	2 Timers – generates periodic timer events as a function of the processor clock.  Used by DSP/BIOS to create time slices for multitasking.

•	EDMA Controller  – Enhanced DMA controller allows high speed data transfers without intervention from the DSP.

•	2 McBSPs – Multichannel buffered serial ports.  Each McBSP can be used for high speed serial data transmission with external devices or reprogrammed as general purpose I/Os.  McBSP1 is used to transmit and receive audio data from the AIC23 stereo codec.  McBSP0 is used to control the codec through its serial control port.  The the MISC register in the CPLD is used to select whether McBSP0 and McBSP1 are routed to the the AIC23 or the expansion connectors.

•	2 McASPs – Multichannel audio serial ports.  Used for multi-channel and professional audio applications.  Not used on the DSK, but brought out to the expansion connectors.

•	2 I2C Interfaces – Inter-Integrated Circuit Bus.  An I2C bus is a serial bus format that can support serveral standard devices per bus.

•	EMIF – External Memory Interface.  A 32-bit bus on which external memories and other devices can be connected.  It included features like internal wait state generation and SDRAM control.  The EMIF can interface to both synchronous and asynchronous memories.

For more detailed information on the ‘6713, please see the TMS320C6713 Data Sheet.


PLL Settings

The DSP is designed to operate at 225MHz with a 50MHz external oscillator.  For normal operation on the 6713 DSK, the internal phased lock loop (PLL) is configured with a multiplier of 9 and a divisor of 2 to obtain the 225MHz clock from the 50MHz reference.

When the DSP comes out of reset, the PLL is inactive and the 6713 runs at 50MHz.  The PLL can be configured by user applications.  The 6713 DSK Board Support Library initializes the PLL with the call DSK6713_init().


Memory Overview

The C6x family of DSPs have a single large 32-bit address space.  The address space is split between on-chip memory, on-chip peripheral registers and external memory.   All memory is byte addressable and program code and data can be mixed freely.  The 6713 also has separate 4Kbyte program and data caches to improve performance when accessing external code and data.

6713 DSK Memory Map

The figure above is a memory map for the 6713 DSK showing how the address space is used.  The internal memory starts at the beginning of the address space with most of the space either reserved or used for peripheral registers.  The EMIF starts at address 0x80000000 and spans the next 1Gbyte of the address space.  It is divided into 4 equally sized regions each with a dedicated chip enable signal (CE0 – CE3).

The on-board memory, programmable CPLD registers and add-on daughtercards are all connected through EMIF interfaces.  Please see each section for device specific details.

Memory Models

The compiler supports two memory models when accessing code and data.  The near memory model is the most efficient but only supports 32Kbytes of data and 1Mbyte of code.  The far model has no limitations but requires additional instructions to be added when branching and doing address calculations.  You can choose your memory model in your program’s build options.

Endianness

Endianness is a term that refers to the byte ordering of multi-byte data types.  Specifically, a system is called big endian if byte 0 contains the most significant byte of the data or little endian if byte 0 contains the least significant byte.  The 6713 supports both modes and the processor endianness can be controlled at boot time through one of the configuration switches.  The DSK default is little endian mode and all of the DSK specific code examples are distributed in little endian format.

Memory Sections and Linker Command Files

Code Composer has several options for specifying where in memory the various parts of your programs should be placed.  Linker command (.cmd) files are text files that specify the location of each section of code or data.  DSP/BIOS configuration files include the same functionality in the System/Memory Section Manager section of each .cdb file.  Always check your settings to make sure your code is ending up in a reasonable part of memory.  If you are unsure of your memory settings, include a filename in the Map Filename section of the Build Options and recompile your program to see where the linker is trying to put your code.


External Memory Overview

The 6713 DSK  has two types of external memory (see Memory Overview for a memory map):

•	8Mbytes of synchronous DRAM (SDRAM)

•	512Kbytes of asynchronous Flash memory (256Kbytes usable)

All external memory accesses are done through an External Memory Interface (EMIF).  An EMIF generates external bus signals using a programmable controller to provide glueless interfaces to synchronous and asynchronous memories as well as SDRAMs.

Each EMIF has its address space divided into 4 equally sized regions with its own dedicated chip enable signal and configuration registers.  This allows different types of memories to be connected to the same interface.  On the 6713 DSK, the on-board SDRAM is connected to CE0 of the EMIF while the Flash memory and programmable CPLD registers share CE1.  The SDRAM uses the EMIF’s internal synchronous DRAM controller while the Flash and CPLD use simple asynchronous memory signals.  CE2 and CE3 are also used to access devices on any add-on daughtercards.

The EMIF clock rate is determined by the PLL configuration.  The PLL multiplier is set to 9 (50MHz x 9 = 450MHz) with a divisor of 2 to get a DSP clock of 225MHz.  The EMIF has an independent divisor which can be any integral number.  For normal DSK operation, the EMIF divisor should be 5 for a bus speed of 90MHz (450MHz / 5).

Do not attempt to load code into an external memory space until the EMIF is set up.  Also, the following settings are specific to the 6713 DSK as used by the included examples, your own code and hardware designs may have different requirements.  For detailed information about the EMIF, please see the TMS320C64x DSP Peripherals Reference Guide.


SDRAM

The DSK uses a 64 megabit Synchronous DRAM (SDRAM) on the 32-bit EMIF.  The SDRAM is mapped at the beginning of CE0 (address 0x80000000).  Total available memory is 16 megabytes.

 The integrated SDRAM controller is part of the EMIF and must be configured in software for proper operation.  Some some of the most important parameters are listed below:

Parameter	Value
CE0 Memory Type	32-bit wide SDRAM
Num. Banks	4
Num. Row Address Lines	12
Num. Column Address Lines	8
Refresh Period	1400
One of the key SDRAM parameters is the refresh period.  SDRAMs must be continuously refreshed or they will become unstable and lose their contents.  The DRAM used on the 6713 DSK must refresh one row every 15.6 microseconds.  The configuration shown above uses a value of 1400 (0x578 in hex notation) to specify a refresh period (1400 x 11.11ns, the clock period at 90MHz).

Datasheet

The data sheet for the SDRAM can be viewed in Adobe Acrobat Reader as a .pdf file by clicking on the link below:

SDRAM Datasheet


Flash Memory

Flash is a type of memory which does not lose its contents when the power is turned off.  When read it looks like a simple asynchronous read-only memory (ROM).  Flash can be erased in large blocks commonly referred to as sectors or pages.  Once a block  has been erased each word can be programmed once through a special command sequence.  After than the entire block must be erased again to change the contents.

The DSK uses a 512Kbyte external Flash as a boot option.  It is visible at the beginning of CE1 (address 0x90000000).  The Flash is wired as a 256K by 16 bit device to support the DSK's 16-bit boot option.  However, the software that ships with the DSK treats the Flash as an 8-bit device (ignoring the top 8 bits) to match the 6713's default 8-bit boot mode.  In this configuration, only 256Kbytes are readily usable without software changes.

The Flash requires 70ns for both reads and writes.  The general settings used with the DSK use 8 cycles for both read and write strobes (80ns) to leave a little extra margin.  The DSK default is to add two write hold cycles for all asynchronous memories to account for address propagation delay through the CPLD.

Datasheet

The data sheet for the Flash can be viewed in Adobe Acrobat Reader as a .pdf file by clicking on the link below:

FLASH Datasheet


CPLD Overview

The ’C6713 DSK uses an Altera EPM3128TC100-10 Complex Programmable Logic Device (CPLD) device to implement:

•	4 Memory-mapped control/status registers that allow software control of various board features.

•	Control of the daughtercard interface and signals.

•	Assorted "glue" logic that ties the board components together.

The CPLD logic is specific to the functionality on the DSK.  Your own hardware designs will likely implement a completely different set of functions or take advantage of the DSPs high level of integration for system design and avoid the use of external logic completely.

Memory-Mapped Registers

The 4 CPLD memory-mapped registers allows users to control CPLD functions in software.  On the 6713 DSK the registers are primarily used to access the LEDs and DIP switches and control the daughtercard interface.  The registers are mapped into the EMIF CE1 data space at byte address 0x90080000 with a data width of 8 bits.  The following table gives a high level overview of the CPLD registers and their bit fields:

Glue Logic

The CPLD implements simple random logic functions that eliminate the need for additional discrete devices.  In particular, the CPLD aggregates the various reset signals coming from the reset button and power supervisors and generates a global reset.  It is also used to divide the 24MHz reference clock in half to provide a 12MHz clock to the AIC23.

Device Specifics

The EPM3128TC100-10  is a 3.3V (5V tolerant), 100-pin QFP device that provides 128 macrocells and up to 80 I/O pins with a 10ns pin-to-pin delay.  The device is EEPROM-based and is in-system programmable via a dedicated JTAG interface (a 10-pin header on the DSK).  The CPLD source files are written in the industry-standard VHDL (Hardware Design Language) and are included with the DSK on the installation CD-ROM.


Audio Connectors
Audio Connector

Four industry-standard 3.5mm stereo jack connectors are used in the audio interface:

•	One jack  for connecting audio input from a microphone.

•	One jack  for connecting stereo audio line input.

•	One jack for outputting stereo audio line output (un-amplified).

•	One jack for connecting stereo audio output to a speaker (amplified).

The audio input is AC-coupled and includes:

•	A voltage bias to support the use of battery-powered and electret microphones

•	Passive filtering between the DSK’s audio jacks and the codec for increased performance

The microphone input is designed for electret microphones that require a bias voltage. A dynamic microphone can be used if capacitors are employed to block the bias voltage.


Expansion Interface Overview

The DSK provides three expansion connectors that can be used to accept a plug-in daughtercard.  The daughtercard allows users to build on their DSK platform to extend its capabilities and provide custom and application specific I/O.  The expansion connectors are for memory, peripherals and the Host Port Interface (HPI).  For more information on the expansion interface, please see the 6713 DSK Technical Reference.

Memory, Peripheral and Host Port Interfaces

The memory connector provides access to the DSP’s asynchronous EMIF to interface with memories and memory-mapped devices.  The peripheral connector brings out the DSP’s peripheral signals like McBSPs, timers and clocks.  Both connectors provide power and ground to the daughtercard.

The HPI is a high speed interface that can be used to allow multiple DSPs to communicate and cooperate on a given task.  The HPI signal are multiplexed with McASP1.

Most of the expansion connector signals are buffered so that the daughter-card cannot directly influence the operation of the DSK board.   The use of TI low-voltage, 5-V tolerant buffers and CBT interface devices allows the use of either +5V or +3.3V devices to be used on the daughter-card

Onboard Connector and Mating Connector

The three expansion connectors are all 80-pin 0.050 x 0.050 inches low-profile connectors from Samtec or AMP.  The Samtec SFM-series (surface-mount) connectors are designed for high-speed interconnections because they have low propagation delay, capacitance, and cross-talk. The connectors present a small footprint on the DSK.  Each connector includes multiple ground, +5V, and +3.3V power signals so that the daughter-card can obtain power directly from the DSK.  The peripheral expansion connector additionally provides both +12V and -12V to the daughter-card.  The recommended mating connector, whose part number is TFM-140-32-S-D-LC, is a surface-mount connector that provides a 0.465" mated height.


Expansion Memory Interface

The expansion memory interface provides the DSP’s memory interface signals to a daughter-card.  External asynchronous memories and memory-mapped devices can be added to the DSK, including non-volatile memory that can be used to boot the DSK upon reset.

The expansion memory interface includes:

•	External address signals - All of the DSP's external address signals are available on the expansion memory interface

•	External data signals - All of the DSP's 32 external data signals are available on the expansion memory interface.

•	Asynchronous memory control signals.  Asynchronous memory control signals sent from the DSP, or derived from DSP signals to provide C6x daughtercard compatibility, are available on the expansion memory interface.  ARDY can be used by the daughter-card to extend the timing for a memory transaction.

 •	Power Signals.  The expansion memory interface also provides ground, 5V, and 3.3V power signals to the daughter-card.

Memory Expansion Connector


Expansion Peripheral Interface

The expansion peripheral interface provides the DSP’s peripheral signals to a daughter-card. This peripheral expansion capability allows serial devices (such as other Codecs and communication devices) to be added to the DSK via a daughter-card.

The expansion peripheral interface includes:

•	Six signals for each of the serial ports - The DSP's six McBSP signals for McBSP0 and McBSP1 are available on the expansion peripheral interface.  These signals are buffered on the DSK to support both 5V and 3.3V serial devices.  Each McBSP has CLKX, FSX, DX, CLKR, FSR and DR signals.

•	Timer signals -  The DSP's two timer inputs and outputs are available on the expansion peripheral interface.  They can be accessed through the CPLD.

•	Interrupts and interrupt acknowledge -  Four  external DSP interrupts (INT0-, INT1-, INT2-, and INT3-), are available to daughter-card  interface. The DSP's interrupt acknowledge (IACK-) is also available on the expansion peripheral interface.

•	DSP general-purpose I/O signals -  The DSP's XF signals is available on the expansion peripheral connector.

•	Reset signal - The expansion peripheral interface also provides a reset signal that is active low when the board is in the reset state.  This allows the circuitry on the daughter-card to be set to a known state.  The reset signal is asserted for a minimum of 140 milliseconds upon power-up, via a manual reset push button or under software control.  A CPLD register bit (DC_RST) in DC_REG allows DSP software to directly control this reset signal when the DSP is not held in reset

•	CLKOUT signal for the synchronization clock - The DSP's CLKOUT is brought out to the expansion peripheral interface for synchronization needs on daughter-cards.

•	Daughtercard detect - Pin 75 on the expansion peripheral connector should be grounded on the daughter-card to indicate that the daughter-card is present. This pin enables the on-board LDO regulator that supplies the 3.3 Volts to the daughter-card.

•	Power signals - The expansion peripheral interface also provides ground, 12V, -12V, 5V, and 3.3V power signals to the daughter-card.

Peripheral Expansion Connector

NOTE: RESERVED PINS ARE NOT USED ON THIS DSK, OTHER DSK’S MAY USE THESE SO USE CAUTION WHEN DESIGNING DAUGHTERCARDS.


Expansion Host Port Interface

The HPI expansion interface provides the DSP’s HPI and McBSP2 peripheral signals to a daughter-card. The HPI expansion capability allow interface logic to directly interface into the 6713’s Host Port Interface. The peripheral expansion capability allows serial devices (such as other codecs and communication devices) to be added to the DSK via a daughter-card.

The expansion host post  interface includes:

•	HPI Data - The DSP's host port data bus is connected to the HPI expansion connector allowing easy  bidirectional data transfer between a host and the DSP.

 •	Asynchronous HPI control signals - Asynchronous control signals sent from the interface to the DSP allow a wide variety of processors to interface to the Host Port.

•	McASP1 serial port signals – The McASP signals are multiplexed with the HPI signals.   The multiplexing funciton is controlled by the configuration switches.

•	Power Signals - The expansion HPI Interface also provides ground, 5V, and 3.3V power signals to the daughter-card.

HPI Expansion Connector

NOTE: RESERVED PINS ARE NOT USED ON THIS DSK, OTHER DSK’S MAY USE THESE SO USE CAUTION WHEN DESIGNING DAUGHTERCARDS.


Power Supply Overview

The DSK operates from a single +5V external power supply connected to the main power input (J5).  Internally, the +5V input is converted into +1.26V and +3.3V using TPS54310PWP switching voltage regulators.  The 1.26V supply is used for the DSP core while the 3.3V supply is used for the DSP’s I/O buffers and all other chips on the board.  The power connector is a Switchcraft type RASM712 2.5mm barrel-type plug.

Pin	Function
Outer	Ground
Center	+5 VDC +/-5%.

Power Test Points

There are two power test points on the DSK at JP1 and JP2.  All 6713 I/O current passes through JP2 while all core current passes through JP1.  Normally these jumpers are both closed.  To measure the current passing through remove the jumpers and connect the pins with a current measuring device such as a multimeter or current probe.

Daughtercard Power

The 3.3V and 5V daughtercard signals are powered from the DSK’s main supplies.  It is also possible to provide the daughtercard with +12V and –12V when the external power connector is used.


External Power Connector

Warning:  The DSK can be powered by either the main power connector (J5) or the external power connector (J5), but not both at the same time.  Please make sure only one power supply is connected at a time.  J5 is shipped depopulated as a precaution.

The DSK can be optionally powered through the external power connector (J6) if +12V or –12V power is required on the daughtercard.  J6 is an industry-standard Molex 4-pin connector that is commonly used in PCs for disk drive power.  The four pins on the connector are used for +5V, -12V, GND and +12V.  It is possible to use a standard PC power supply to power the DSK but MAKE SURE the power supply pin definitions match the connector below.  PC power supplies typically have pin 2 connected as ground so they will only work unmodified if the daughtercard does not use –12V.

External Power Connector


LED Indicators

The DSK has eight  LEDs made up of  four status indicators and four user defined LEDs.  The user-defined indicators are the green LEDs next to the DIP switches.

User LEDs

The four user controllable LEDs allow for user feedback and display of simple status information.  They are controlled by writing to the CPLD USER_REG register.  They can also be set or cleared through the LED Module of the Board Support Library.

Status Indicators

The status indicators monitor the following functions. The PWR LED is hardwired on the +5V supply and will illuminate whenever the power is connected. The RESET LED illuminates when the a RESET event occurs. The USB_IN_USE LED is on when USB emulation is used and goes off when an external emulator is applied. The USB BUSY LED indicates that the a USB emulator transaction is in progress.


DIP Switches

The four DIP switches allow simple feedback from the user.  The DIP switches can be read through the CPLD USER_REG register.  They can also be read using the DIP Switch module of the Board Support Library.


Configuration Switches

The 6713 DSK has 4 configuration switches that allows users to control the operational state of the DSP when it is released from reset.  The configuration switch block is labeled SW3 on the DSK board, next to the reset switch.

Configuration switch 1 controls the endianness of the DSP while switches 2 and 3 configure the boot mode that will be used when the DSP starts executing.  Switch 4 determines whether the HPI or McASP signals come out on shared pins.

Configuration Switch Settings

Default Settings

The default configuration settings are to have all switches off.  This configures the DSK to boot from the on-board Flash in little endian mode.


CPLD DC_REG Register

DC_REG is used to monitor and control the daughtercard interface.  DC_DET detects the presence of  a daughtercard.  DC_STAT and DC_CNTL provide simple communications with the daughtercard through readable status lines and writable control lines.

The daughtercard is released from reset when the DSP is released from reset.  DC_RST can be used to put the card back in reset.

DC_REG Register Definition


CPLD MISC Register

The MISC register is used to provide software control for miscellaneous board functions.  On the 6713 DSK, the MISC register controls how  auxilliary signals are brought out to the daughtercard connectors.

MCBSP0SEL and MCBSP1SEL

McBSP0 and McBSP1 are usually used as the control and data ports of the on-board AIC23 codec.  The power-on state of these bits (both 0s) represents that situation.  Set the corresponding bit to 1 to use the McBSP with a daughtercard instead.

FLASH_PAGE

The Flash and CPLD share CE1 which means that the highest address bit (A21) is used to differentiate between the two.  The FLASH_PAGE bit is driven to the Flash as a replacement for that address line.  On a standard DSK, the on-board Flash is not large enough for this bit to be significant.  FLASH_PAGE is only useful if the board is re-polulated with a larger pin-compatible Flash chip.

Scratch Bits

The scratch bits are unused.  They can be set to any value.

MISC Register Definition


Connector Index

There are many DSK I/O connectors. You can read detailed information regarding each connector listed below:

•	2.5 mm barrel-type power connector for external +5 VDC input.

•	Optional Molex 4-pin external power connector (+5V/+12V/-12V/GND).

•	14-pin external JTAG header.

•	10-pin CPLD JTAG header.

•	USB connector for embedded JTAG emulator.

•	Four 3.5mm audio jacks for microphone/line-in/line-out/speaker.

•	One Low-Profile 80-pin (.050") memory expansion connector.

•	One Low-Profile 80-pin (.050") peripheral expansion connector.

•	One Low-Profile 80-pin (.050") HPI expansion connector.


Flash Utility Overview

FlashBurn is a utility included with Code Composer Studio that can be used to program code and data into the on-board Flash on the 6713 DSK.  One of the most common uses for FlashBurn is to take user code that has been debugged with Code Composer and program it into the Flash so that the board will boot it and run in standalone mode when it is powered up independently of the debug environment.

This section describes how to burn the POST into Flash using some pre-built example files, more detailed instructions on using FlashBurn can be found in the "FlashBurn Utility" section of the Code Composer Studio Online Help.  The POST example and related files are in  located in c:\CCStudio_v3.1\examples\dsk6713\bsl\post.

The following sequence outlines programming the POST into Flash:

•	Create a bootloader image of the executable file in ascii hex file format (post.hex).

•	Launch Code Composer Studio to allow access to the integrated tools.

•	Load the configuration document (post.cdd) that tells FlashBurn what to burn into Flash.

•	Erase the Flash with FlashBurn.

•	Program the Flash with FlashBurn.


Programming the POST with FlashBurn

To start the FlashBurn process, launch Code Composer Studio.  Now launch FlashBurn by clicking Tools · FlashBurn as shown in the figure below:

FlashBurn will now launch.  Use File · Open to open the sample FlashBurn configuration document c:\CCStudio_v3.1\examples\dsk6713\bsl\post\post.cdd.  You should see a window that looks like this:

The important fields are the "File To Burn" field at the top and the "FBTC Program File" at the bottom.  The "File To Burn" field specifies the .hex file to program into Flash, in this case the post.hex file in the post directory:

c:\CCStudio_v3.1\examples\dsk6713\bsl\post\post.hex

The "FBTC Program File" is a piece of code that FlashBurn executes on the 6713 DSK to manipulate the Flash.  It is supplied with the FlashBurn distribution in:

c:\CCStudio_v3.1\bin\utilities\FlashBurn\C6000\dsk6713\FBTC64.out

These settings are pre-configured in the post.cdd file and only need to be changed if the base install directory is not c:\CCStudio_v3.1.

Select Program · Erase Flash option under the Program menu to erase the Flash.  It should take about 10 seconds.  Now select Program ·  Program Flash option to start programming the Flash.  After about 3 seconds the procedure should be complete.  Exit out of FlashBurn and Code Composer, unplug power to the 6713 DSK then plug the power back in.  The POST will now start running automatically.


Diagnostic Utility Overview

This utility allows you to perform simple diagnostic tests on your 6713 DSK to verify that it is fully operational.  The tests are divided into two pages labeled General and Advanced.  The Advanced tab is further subdivided into tests that manipulate the codec, memory, DSP processor core and LEDs.

Basic Controls

All tests are initiated by selecting the test via tabs on the left side of the panel and clicking on the START button on the right side.  Tests can be aborted at any time by pressing the STOP button.  If a new test is selected while a current test in already in progress the first one will automatically be stopped.

The utility keeps a log of all test results which is shown in the "Diagnostic Results" panel at the bottom of the application.  The log can be saved as a text file by pressing the "SAVE AS" button to permit further analysis of any problems.

The DSK can be reset in two ways.  The RESET EMU button is used to put the USB emulator in a known state.  The RESET DSK button performs a board level reset.

The following links explain each of the tabs in more detail:

General	Complete tests for each of the board components
Advanced	More specific tests to test the operation of a single component
Codec	Codec test with internal and external loopback
Memory	Internal and external memory tests
DSP	Tests of the DSP core
LED/Switch	Display the LED and DIP switch values


General Diagnostic Tests

The General tab contains a series of tests designed to test the functionality of many of the 6713 DSK components.  Pressing the START button initiates the tests.  Each test displays information about its status in the Diagnostic Results panel at the bottom of the application.  If any tests fail, the application will display a "Fail" message. Otherwise the application will display a "Pass" message when all tests are complete.  Below is a short description of each of the tests:

USB Diagnostics	Checks that the on-board USB emulator can be detected and initialized
Emulation Diagnostics	Checks that the emulator can communicate with the DSP's JTAG interface
DSP Diagnostics	Runs internal tests on the DSP core and on-chip peripherals
External Memory	Runs pattern and addressing tests in the external SDRAM
Flash Diagnostics	Programs and verifies a pattern in external Flash
Codec Diagnostics	Generates a 1KHz tone on the speaker and line outputs
LED Diagnostics	Runs a flashing left to right pattern that a user can visually verify
Switch Diagnostics	Displays the value of the DIP switches and lights the corresponding LED


Advanced Diagnostic Tests

The Advanced tab contains tests that allow the user to check the operation of a particular device in more detail.  Select a test by clicking on the appropriate tab at the bottom of this panel.  The control buttons on the right of the application have the same functions as in the General tab, but each test is run individually rather than in series.  A timer displays the elapsed time of each diagnostic.


Codec Diagnostic

The Codec diagnostic is one of the most informative tests in the Advanced diagnostic suite.  It is designed to generate a 1KHz sine wave on the right channel (yellow) and a 2KHz sine wave on the left channel (blue).  The outputs are driven through both the line and speaker outputs.

The on-screen display shows the waveform visible at the line input.  When a stereo loopback cable (a standard 1/8" male to male stereo audio cable) is connected between the headphone out and line-in the display should look similar to the picture above.  Since each channel is at a different frequency it is possible to visually isolate problems with the channel as well as any interference or bleeding between the channels.

Additional controls add some flexibility in manipulating the signal.  The headphone output gain can be adjusted with the volume control.  Since the AIC23’s output gain affects the headphone out, line-out will remain at the same level regardless of the volume control setting.  The MUTE button enables the codec's mute function and the LOOPBACK button enables the internal loop-back path rather than driving external output through the codec.  The internal loopback does not go through the AIC23’s internal filters and appears time shifted relative to the real audio data.

It is normal to hear a short pause in the output tone roughly once every second as the application must halt the DSP to access the codec waveform.


Memory Diagnostic

The Memory diagnostic writes patterns to the external SDRAM.  The choice of pattern can be selected using the listbox designated "Patterns".  The pattern "0x0000, 0x5555, 0xAAAA, 0xFFFF" sequentially fills the entire SDRAM with each value and verifies the result to detect data failures.  The "Addr, Addr Inverted" tests fill each memory location with its address to detect address/data dependencies.

By default the memory test is only run once.  Continuous test mode can be selected using the "Continuous" checkbox.


DSP Diagnostic

The DSP diagnostic performs four tests on on-chip peripherals.  The timer test displays a Flashing LED moving from left to right and back.  Movement of the LED’s allows the user to verify that the timer is working.  The DMA uses the on-chip DMA to copy data from one buffer to the other, both buffers must match exactly for the test to pass.

The McBSP diagnostics pass a set of data through the serial ports 0 and 1 (McBSP is a Texas Instruments serial port) using the internal loop-back mechanism and sample rate generators.  Failure to pass these tests indicates a problem with the DSP itself.


LED/Switch Diagnostic

The LED/Switch diagnostic reads the state of the DIP switches and constantly updates the corresponding LED indicators on both the board and the on-screen display.  The LEDs have the same polarity as the switches, i.e. the LED is on if the switch is on and off if the switch is off.  The user must verify operation by toggling the switches and watching the appropriate indicator lights.


BSL 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.

The BSL contains 5 modules:

Module	Function
Board Setup	General board initialization
Codec	Access the AIC23 codec
DIP Switch	Read DIP switches
LED	Manipulate LEDs
Flash	Program and erase Flash
Libraries and Include Files

In its most basic form, using the BSL is just a matter of:

1)	Linking the BSL in with your code.

2)	Referencing the appropriate include files for each module (see the API descriptions for each function’s requirements).

3)	Calling the functions themselves, starting with DSK6713_init().

The libraries and include files reside in these directories:

TI_DIR\C6000\dsk6713\lib	Library Files
TI_DIR\C6000\dsk6713\include	Include Files

where TI_DIR is the directory Code Composer is installed in.

Using the BSL

The version of Code Composer that comes with the DSK automatically includes the lib and include paths above so you don’t need to manually include them in the search paths.  To include the dsk6713bsl.lib file for example, select Project · Build Options on the Linker tab type dsk6713bsl.lib in the "Include Libraries" field.

If you choose to specify your search paths, the library search path is specified on the same tab as the library file and the include search path is specified by selecting Project · Build Options, and setting the "Include Search Path" field in the preprocessor section of the compiler tab.

Customizing the BSL

The BSL source code is available in TI_DIR\C6000\dsk6713\lib\dsk6713bsl.zip.  You may extend or modify the source code and build your own version of the library.  You can also include the BSL source files directly into your application for greater control.  One useful technique while debugging is to use Code Composer’s ability to open multiple projects simultaneously to open both your application and the BSL at the same time.  The debugger will treat the BSL almost as if the source code for both projects were actually part of the same project.

Project Checklist

The following are things to check when creating your own project:

CDB File	The CDB file contains all of the DSP/BIOS settings.  The easiest thing to do is copy, rename and modify one of the BSL examples.
Linker Command File Included	Make sure the linker command file is included in your project.  It ends in .cmd and is auto-generated when your CDB file is compiled.
Endian Mode is Consistent	The endian mode must be consistent in each place it is set.  It is set in the project options by selecting Project · Build Options and viewing the Advanced tab.  It is also set in your CDB file under System · Global Settings in the DSP Endian Mode selector.
BSL Library Included	Make sure the correct BSL library is included.  The BSL library should be specified by selecting Project · Build Options on the Linker tab and typing dsk6713bsl.lib in the "Include Libraries" field.
Include Paths are Set	If you can’t see header (.h) files that your program uses, make sure you have the paths set correctly in Project · Build Options on the Preprocessor tab.  If you can’t see header files in the same directory as your project, add a . to your search path.  To include multiple paths, place a semicolon between paths, for example .;c:\CCStudio_v3.1\C6000\dsk6713\include includes both the project directory and the BSL include directory.
Processor Options are Set	The code gen tools need to be aware of the processor type and silicon revision to fully optimize your code.  The processor type is set under Project · Build Options by selecting C671x  in the Target Version field of the Basic tab.  It is also used in your CDB file to select the matching version of the Chip Support Library.  Look under System · Global Settings in the CSL selector box.  If your program does not use DSP/BIOS you must manually define the value CHIP_6713 under Project · Build Options on the Define Symbols field of the Preprocessor tab.  Use a semicolon to separate multiple values if something else is already defined.


BSL API Index

DSK6713_init()	Initialize the 6713 DSK
DSK6713_rget()	Read an 8-bit value from a CPLD register
DSK6713_rset()	Write an 8-bit value to a CPLD register
DSK6713_version()	Get the DSK version
DSK6713_wait()	Spin in a software delay loop
DSK6713_waitusec()	Spin in a software delay loop (microseconds)
DSK6713_AIC23_openCodec()	Allocate an identifying handle for an instance of a codec
DSK6713_AIC23_closeCodec()	Release a codec handle
DSK6713_AIC23_config()	Set parameters on codec registers
DSK6713_AIC23_read()	Read 32 bits from the codec data stream
DSK6713_AIC23_write()	Write 32 bit value to the codec data stream
DSK6713_AIC23_rset()	Set the value of a codec control register
DSK6713_AIC23_rget()	Return the value of a codec register
DSK6713_AIC23_outGain()	Set the codec output gain
DSK6713_AIC23_loopback()	Enable/disable the codec loopback mode
DSK6713_AIC23_mute()	Enable/disable the codec mute mode
DSK6713_AIC23_powerDown()	Enable/disable the codec powerdown modes
DSK6713_AIC23_setFreq()	Set the codec sample rate
DSK6713_DIP_init()	Initialize the DIP switches
DSK6713_DIP_get()	Read the DIP switches
DSK6713_LED_init()	Initialize the LED’s
DSK6713_LED_off()	Turn specified LED off
DSK6713_LED_on()	Turn specified LED on
DSK6713_LED_toggle()	Toggle the specified LED
DSK6713_FLASH_checksum()	Calculate checksum for a range of memory
DSK6713_FLASH_erase()	Erase a range of Flash memory
DSK6713_FLASH_read()	Read from a range of Flash memory
DSK6713_FLASH_write()	Write to a range of Flash memory


Board Setup API Summary

Return to BSL API Index

The Board Setup API provides general functions used for board initialization.  The DSK6713_init() call must be made before any other BSL functions as it is responsible for all BSL initialization.  The DSK6713_rget() and DSK6713_rset() functions are used to access on on-board CPLD register.

The following list summarizes the Board Setup API in terms of its function calls:

DSK6713_init()	Initialize the 6713 DSK
DSK6713_rget()	Read a 16-bit value from a CPLD register
DSK6713_rset()	Write a 16-bit value to a CPLD register
DSK6713_version()	Get the DSK version
DSK6713_wait()	Spin in a software delay loop
DSK6713_waitusec()	Spin in a software delay loop (microseconds)

All programs that use the BSL should include the dsk6713.h header file.  In addition to other things, it contains several useful constants:

Name	Typical Value	Description
DSK6713_CPLD_BASE	0x60000000	Address of CPLD in data space.
DSK6713_USER_REG	0	Index of USER_REG CPLD register
DSK6713_DC_REG	1	Index of DC_REG CPLD register
DSK6713_VERSION	4	Index of VERSION CPLD register
DSK6713_MISC	6	Index of MISC CPLD register


DSK6713_init()

Return to Board Setup API Summary

Description	Sets all CPLD registers to their power-on states and initializes internal BSL data structures.  Must be called before any other BSL functions.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_init()
Parameters	None
Return Value	None
Example	// Initialize the board support library DSK6713_init();


DSK6713_rset()

Return to Board Setup API Summary

Description	Write an 8-bit value to a CPLD register.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_rset(Int16 regnum, Uint16 regval)
Parameters	regnum – Index of CPLD register. regval – Value to set the register to.  Only the lower 8 bits are used.
Return Value	None
Example	// Turn all 4 LEDs on DSK6713_rset(DSK6713_USER_REG, 0xf);


DSK6713_version()

Return to Board Setup API Summary

Description	Return the DSK version.  Used to make software tolerant of board differences.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	Int16 DSK6713_version()
Parameters	None
Return Value	DSK version, 1 for 8Mb SDRAM, 2 for 16 Mb SDRAM
Example	Int16 version; // Check DSK version version = DSK_version();


DSK6713_wait()

Return to Board Setup API Summary

Description	Spin in a loop.  Used for short timing loops.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_wait(Uint32 delay)
Parameters	delay – number of loop iterations to spin
Return Value	None
Example	// Spin for 100 loop iterations DSK6713_wait(100);


DSK6713_waitusec()

Return to Board Setup API Summary

Description	Spin in a loop for a number of microseconds.  Used for short timing loops.   Roughly calibrated to wall clock time when code is executed out of internal memory.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_waitusec(Uint32 delay)
Parameters	delay – number of microseconds to delay
Return Value	None
Example	// Spin for 100 microseconds DSK6713_waitusec(100);


DSK6713_rget()

Return to Board Setup API Summary

Description	Read an 8-bit value from a CPLD register.
Required Headers	dsk6713.h
Required Libraries	dsk6713bsl.lib
Prototype	Uint16 DSK6713_rget(Int16 regnum)
Parameters	regnum – Index of CPLD register.
Return Value	Value of CPLD register.
Example	// Read the value of DIP switch #0 if (DSK6713_rget(DSK6713_USER_REG) & 0x10) {     /* Switch #0 is on */ } else {     /* Switch #0 is off */ }


Codec API Summary

Return to BSL API Index

The codec module include file dsk6713_aic23.h contains constant definitions for the handles and AIC23 register offsets.  Please view it to see what is available.

The following list summarizes the AIC23 Codec API in terms of its function calls:

DSK6713_AIC23_openCodec()	Allocate an identifying handle for an instance of a codec
DSK6713_AIC23_closeCodec()	Release a codec handle
DSK6713_AIC23_config()	Set parameters on codec registers
DSK6713_AIC23_read()	Read 32 bits from the codec data stream
DSK6713_AIC23_write()	Write 32 bit value to the codec data stream
DSK6713_AIC23_rset()	Set the value of a codec control register
DSK6713_AIC23_rget()	Return the value of a codec register
DSK6713_AIC23_outGain()	Set the codec output gain
DSK6713_AIC23_loopback()	Enable/disable the codec loop-back mode
DSK6713_AIC23_mute()	Enable/disable the codec mute mode
DSK6713_AIC23_powerDown()	Enable/disable the codec powerdown modes
DSK6713_AIC23_setFreq()	Set the codec sample rate


DSK6713_AIC23_rset()

Return to Codec API Summary

Description	Set the value of a codec control register.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_rset(DSK6713_AIC23_CodecHandle hCodec, Uint16 regnum, Uint16 regval);
Parameters	hCodec – Codec handle. regnum – Which codec register to set. regval – Value to set the register to.
Return Value	None
Example	// Set codec left and right gain to 0x79 DSK6713_AIC23_rset(hCodec, 2, 0x79); DSK6713_AIC23_rset(hCodec, 3, 0x79);


DSK6713_AIC23_rget()

Return to Codec API Summary

Description	Return the value of a codec register.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	Uint16 DSK6713_AIC23_rget(DSK6713_AIC23_CodecHandle hCodec, Uint16 regnum);
Parameters	hCodec – Codec handle. regnum – Which codec register to read.
Return Value	Value of codec register.
Example	Uint16 value; // Read codec register 1 value = DSK6713_AIC23_rget(hCodec, 1);


DSK6713_AIC23_outGain()

Return to Codec API Summary

Description	Set the codec output gain.  The gain is a 7 bit value that corresponds directly to the 7-bit gain field in the codec registers 2 and 3.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_outGain(DSK6713_AIC23_CodecHandle hCodec, Uint16 outGain);
Parameters	hCodec – Codec handle. outGain – Codec gain, 0 = lowest output, 0x7f = highest output
Return Value	None
Example	// Set output gain to 0x79 DSK6713_AIC23_outGain(hCodec, 0x79);


DSK6713_AIC23_loopback()

Return to Codec API Summary

Description	Enable/disable the codec loopback mode.  Loopback mode forces the codec to copy its input directly to its output.  It is the opposite of a loopback cable that would copy the output back the input.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_loopback(DSK6713_AIC23_CodecHandle hCodec, Int16 mode);
Parameters	hCodec – Codec handle. mode – Loopback mode enable (TRUE) or disable (FALSE);
Return Value	None
Example	// Enable codec loopback mode DSK6713_AIC23_loopback(hCodec, TRUE);


DSK6713_AIC23_mute()

Return to Codec API Summary

Description	Enable/disable the codec mute mode.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713sbsl.lib
Prototype	void DSK6713_AIC23_mute(DSK6713_AIC23_CodecHandle hCodec, Int16 mode);
Parameters	hCodec – Codec handle. mode – Codec mute enable (TRUE) or disable (FALSE);
Return Value	None
Example	// Disable codec mute mode. DSK6713_AIC23_mute(hCodec, FALSE);


DSK6713_AIC23_powerDown()

Return to Codec API Summary

Description	Enable/disable the codec powerdown modes.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_powerDown(DSK6713_AIC23_CodecHandle hCodec, Uint16 sect);
Parameters	hCodec – Codec handle. sect – Bitmap of which sections to enable powerdown mode.  Matches bits in the AIC23 Power Down Control register.  Powerdown modes for a particular codec section are enabled if its corresponding bit is 1.  Writing 0 as sect turns disables all powerdown modes (all sections are on).
Return Value	None
Example	// Enable the ADC powerdown mode. DSK6713_AIC23_powerDown(hCodec, 0x04);


DSK6713_AIC23_setFreq()

Return to Codec API Summary

Description	Set the codec sample rate.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_setFreq(DSK6713_AIC23_CodecHandle hCodec, Uint32 freq);
Parameters	hCodec – Codec handle. freq – Sample rate of the codec clock.  Can be one of the following, default is 48KHz: If an invalid frequency is entered no change will be made.
Return Value	None
Example	// Set codec frequency to 48KHz DSK6713_AIC23_setFreq(hCodec, DSK6713_FREQ_48KHZ);


DSK6713_AIC23_openCodec()

Return to Codec API Summary

Description	Initialize the AIC23 codec module and perform codec setup.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	DSK6713_AIC23_CodecHandle DSK6713_AIC23_openCodec(int id, DSK6713_AIC23_Config *Config)
Parameters	id – Specifies which codec to use, on the DSK6713, id = 0. Config – Pointer to structure containing codec register values.  The function will initialize the codec registers with the values in the structure.
Return Value	Handle for the codec, used by the other codec module functions.
Example	/* Codec configuration settings */ DSK6713_AIC23_Config config = { \     0x0017,  /* 0 DSK6713_AIC23_LEFTINVOL  Left line input channel volume */ \     0x0017,  /* 1 DSK6713_AIC23_RIGHTINVOL Right line input channel volume */\     0x01f9,  /* 2 DSK6713_AIC23_LEFTHPVOL  Left channel headphone volume */  \     0x01f9,  /* 3 DSK6713_AIC23_RIGHTHPVOL Right channel headphone volume */ \     0x0011,  /* 4 DSK6713_AIC23_ANAPATH    Analog audio path control */      \     0x0000,  /* 5 DSK6713_AIC23_DIGPATH    Digital audio path control */     \     0x0000,  /* 6 DSK6713_AIC23_POWERDOWN  Power down control */             \     0x0043,  /* 7 DSK6713_AIC23_DIGIF      Digital audio interface format */ \     0x0081,  /* 8 DSK6713_AIC23_SAMPLERATE Sample rate control */            \     0x0001   /* 9 DSK6713_AIC23_DIGACT     Digital interface activation */   \ }; // Open codec with default settings DSK6713_AIC23_CodecHandle hCodec; hCodec = DSK6713_AIC23_openCodec(0, &config);


DSK6713_AIC23_closeCodec()

Return to Codec API Summary

Description	Close codec module.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_closeCodec(DSK6713_AIC23_CodecHandle hCodec)
Parameters	hCodec – Codec handle.
Return Value	None
Example	DSK6713_AIC23_closeCodec(hCodec);


DSK6713_AIC23_config()

Return to Codec API Summary

Description	Change the codec configuration.  Use to set volume, enable mute, etc.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_AIC23_config(DSK6713_AIC23_CodecHandle hCodec, DSK6713_AIC23_Config *Config)
Parameters	hCodec – Codec handle. Config – Pointer to structure containing codec register values.  The function will initialize the codec registers with the values in the structure.
Return Value	None
Example	/* Codec configuration settings */ DSK6713_AIC23_Config config = { \     0x0017,  /* 0 DSK6713_AIC23_LEFTINVOL  Left line input channel volume */ \     0x0017,  /* 1 DSK6713_AIC23_RIGHTINVOL Right line input channel volume */\     0x01f9,  /* 2 DSK6713_AIC23_LEFTHPVOL  Left channel headphone volume */  \     0x01f9,  /* 3 DSK6713_AIC23_RIGHTHPVOL Right channel headphone volume */ \     0x0011,  /* 4 DSK6713_AIC23_ANAPATH    Analog audio path control */      \     0x0004,  /* 5 DSK6713_AIC23_DIGPATH    Digital audio path control */     \     0x0000,  /* 6 DSK6713_AIC23_POWERDOWN  Power down control */             \     0x0043,  /* 7 DSK6713_AIC23_DIGIF      Digital audio interface format */ \     0x0081,  /* 8 DSK6713_AIC23_SAMPLERATE Sample rate control */            \     0x0001   /* 9 DSK6713_AIC23_DIGACT     Digital interface activation */   \ }; // Configure codec with defaults except mute bit set (bit 3 of reg 5) DSK6713_AIC23_config(hCodec, &config);


DSK6713_AIC23_read()

Return to Codec API Summary

Description	Read a 32 bit signed value from the codec data port.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	Int16 DSK6713_AIC23_read(DSK6713_AIC23_CodecHandle hCodec, Int32 *val);
Parameters	hCodec – Codec handle. val – Address of  16 bit signed variable to receive codec data.
Return Value	TRUE – Data written successfully. FALSE – Data port is busy.
Example	Uint32 data; // Read 32 bits of codec data, loop to retry if data port is busy while(!DSK6713_AIC23_read(hCodec, &data));


DSK6713_AIC23_write()

Return to Codec API Summary

Description	Write a 32 bit signed value to the codec data port.
Required Headers	dsk6713.h dsk6713_aic23.h
Required Libraries	dsk6713bsl.lib
Prototype	Int16 DSK6713_AIC23_write(DSK6713_AIC23_CodecHandle hCodec, Int32 val);
Parameters	hCodec – Codec handle. val – 32 bit value signed to write to codec
Return Value	TRUE – Data written successfully. FALSE – Data port is busy.
Example	Uint32 data; data = 0x12345678; // Write 0x12345678 to the codec, loop to retry if data port is busy while(!DSK6713_AIC23_write(hCodec, data));


DIP Switch API Summary

Return to BSL API Index

The following list summarizes the DIP Switch API in terms of its function calls:

DSK6713_DIP_init()	Initialize the DIP switches
DSK6713_DIP_get()	Read the DIP switches


DSK6713_DIP_init()

Return to DIP Switch API Summary

Description	Initialize the DIP switch module, must be called before any DIP switch functions.
Required Headers	dsk6713.h dsk6713_dip.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_DIP_init()
Parameters	None
Return Value	None
Example	// Initialize the DIP switch module DSK6713_DIP_init();


DSK6713_DIP_get()

Return to DIP Switch API Summary

Description	Read the value of a DIP switch.
Required Headers	dsk6713.h dsk6713_dip.h
Required Libraries	dsk6713bsl.lib
Prototype	Uint32 DSK6713_DIP_get(Uint32 dipNum)
Parameters	dipNum – Index of the switch to read.  dipNum ranges from 0 to 3.
Return Value	0 – Specified switch is off (switch is in up position). 1 – Specified switch is on (switch is depressed).
Example	// Check the value of DIP switch 2 if (DSK6713_DIP_get(2) == 1) {     // DIP switch 2 is on } else {     // DIP switch 2 is off }


LED API Summary

Return to BSL API Index

The following list summarizes the LED API in terms of its function calls:

DSK6713_LED_init()	Initialize the LED’s
DSK6713_LED_off()	Turn specified LED off
DSK6713_LED_on()	Turn specified LED on
DSK6713_LED_toggle()	Toggle specified LED


DSK6713_LED_init()

Return to LED API Summary

Description	Initialize the LED module.  Must be called before any LED functions.
Required Headers	dsk6713.h dsk6713_led.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_LED_init()
Parameters	None
Return Value	None
Example	// Initialize the LED module DSK6713_LED_init();


DSK6713_LED_on()

Return to LED API Summary

Description	Turn one of the LEDs on.
Required Headers	dsk6713.h dsk6713_led.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_LED_on(Uint32 ledNum)
Parameters	ledNum – indicates which led to turn on.  ledNum ranges from 0 to 3.
Return Value	None
Example	// Turn LED #1 on DSK6713_LED_on(1);


DSK6713_LED_off()

Return to LED API Summary

Description	Turn one of the LEDs off.
Required Headers	dsk6713.h dsk6713_led.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_LED_off(Uint32 ledNum)
Parameters	ledNum – indicates which led to turn off.  ledNum ranges from 0 to 3.
Return Value	None
Example	// Turn LED #3 off DSK6713_LED_off(3);


DSK6713_LED_toggle()

Return to LED API Summary

Description	Toggle one of the LEDs.
Required Headers	dsk6713.h dsk6713_led.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_LED_toggle(Uint32 ledNum)
Parameters	ledNum – indicates which led to turn on.  ledNum ranges from 0 to 3.
Return Value	None
Example	// Turn LED #2 on DSK6713_LED_on(2);


FLASH API Summary

Return to BSL API Index

The FLASH API provides functions to erase as well as read and write from the on-board Flash memory.  Programming errors can be detected through use of a checksum function.

The following list summarizes the LED API in terms of its function calls:

DSK6713_FLASH_checksum()	Calculate checksum for a memory range
DSK6713_FLASH_erase()	Erase a range of Flash memory
DSK6713_FLASH_read()	Read data from a range in Flash
DSK6713_FLASH_write()	Write data to a range in Flash

Programs that use the FLASH API should include both the dsk6713.h and the dsk6713_flash.h BSL header files.  dsk6713_flash.h defines several constants that may be useful while programming:

Name	Typical Value	Description
DSK6713_FLASH_BASE	0x90000000	Address of start of Flash memory
DSK6713_FLASH_PAGESIZE	0x8000	Size of a normal Flash page
DSK6713_FLASH_PAGES	8	Number of DSK_FLASH_PAGESIZE pages
DSK6713_FLASH_SIZE	0x40000	Total size of Flash
DSK6713_FLASH_SUPPORT	1	1 if Flash is supported on this target, 0 if not


DSK6713_FLASH_erase()

Return to FLASH API Summary

Description	Erase a range of Flash memory.
Required Headers	dsk6713.h dsk6713_flash.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_FLASH_erase(Uint32 start, Uint32 length)
Parameters	start – Beginning of region to erase.  Given as an integral number of 8-bit bytes. length – Length of region to erase.  Given as an integral number of 8-bit bytes.
Return Value	None
Example	// Erase the first 2 sectors of the Flash DSK6713_FLASH_erase(DSK6713_FLASH_BASE, (Uint32)(DSK6713_FLASH_PAGESIZE * 2)); // Erase the entire Flash DSK6713_FLASH_erase(DSK6713_FLASH_BASE, DSK6713_FLASH_SIZE);


DSK6713_FLASH_read()

Return to FLASH API Summary

Description	Read data from a range in Flash.
Required Headers	dsk6713.h dsk6713_flash.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_FLASH_read(Uint32 src, Uint32 dst, Uint32 length)
Parameters	src – Address of Flash to read from.  Given as an integral number of 8-bit bytes. dst – Address to memory to read to.  Given as an integral number of 8-bit bytes.
Return Value	None
Example	Uint16 buf[256]; // Copy 256 16-bit words from the beginning of the Flash to buf DSK6713_FLASH_read(DSK6713_FLASH_BASE, (Uint32)buf, 256);


DSK6713_FLASH_write()

Return to FLASH API Summary

Description	Write data to a data range in Flash.  The Flash must be erased first.
Required Headers	dsk6713.h dsk6713_flash.h
Required Libraries	dsk6713bsl.lib
Prototype	void DSK6713_FLASH_write(Uint32 src, Uint32 dst, Uint32 length)
Parameters	src – Address of memory to read from.  Given as an integral number of 8-bit bytes. dst – Address to Flash to write to.  Given as an integral number of 8-bit bytes.
Return Value	None
Example	Uint16 buf[256]; // Copy 256 16-bit words from buf to the beginning of Flash DSK6713_FLASH_write((Uint32)buf, DSK6713_FLASH_BASE, 256);


DSK6713_FLASH_checksum()

Return to FLASH API Summary

Description	Calculate the checksum of a data range in Flash.  The checksum is the unsigned sum of all 16-bit words in the range.  If the sum is exceeds 0xFFFFFFFF it wraps around at 32-bits.  The sum is returned as a single 32-bit value.
Required Headers	dsk6713.h dsk6713_flash.h
Required Libraries	dsk6713bsl.lib
Prototype	Uint32 DSK6713_FLASH_checksum(Uint32 start, Uint32 length)
Parameters	start – Beginning of region to erase.  Given as an integral number of 8-bit bytes. length – Length of region to erase.  Given as an integral number of 8-bit bytes.
Return Value	None
Example	Uint32 checksum; // Calculate checksum for first page of Flash checksum = DSK6713_FLASH_checksum(DSK6713_FLASH_BASE,     DSK6713_FLASH_PASESIZE);


Examples Overview

The DSK highlights five examples that are designed specifically to work with components on the DSK board.  The LED example demonstrates the simplest use of the BSL, a function that blinks a LED and sets another LED based on the value of a DIP switch.  The LEDPRD example shows how to do the same thing using a DSP/BIOS periodic thread and add a second thread to blink a different LED at a different rate.

The tone, DSK_App and BIOS audio examples all illustrate use of the codec.  The tone example uses the BSL’s codec functions to generate a sine wave on the DSK’s audio outputs using polled I/O.  The DSK_App example is a much more advanced example that uses the DMA to transfer audio data and several choices of how the DSP processes the data.  It is good example of how codecs and DMA controllers are used in real products and gets into details of the DSP architecture and peripherals.  This example is recommended for when you are familiar with the DSK and are ready to advance to the next level.

The device driver demos encapsulate the codec data transfer using TI’s device driver model.  They perform audio-pass through using different BIOS primitives.  Device drivers hide details of the data transfer so DSP algorithm users and developers can focus more on the algorithm than getting the data transfer to work.  Once you understand the DSK_App example, the device driver demos are a good way to evaluate the differences between rolling your own code or using TI’s software infrastructure.

The examples are designed to be read in order, which each example increasing in complexity and scope.  They are designed to illustrate specific points as well as provide working base projects on top of which you can build your own code.

Follow these links to the examples:

LED Example

LEDPRD Example

Tone Example

DSK_App Example

BIOS Device Driver Demo


LED Example

The LED example is a simple example that demonstrates the most basic usage of the BSL.  When run it will:

•	Continuously blink LED #0 about 2.5 times per second.

•	Continuously read the value of DIP switch #3 and display it on LED #3.

To run the program, perform the following steps:

1)	Open the led.pjt Code Composer project using Project · Open and selecting led.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\led.

The default install directory for Code Composer is c:\CCStudio_v3.1.  All of the DSK specific documentation refers to file paths as if they were installed in the default location.  If you install Code Composer in a different location, please remember to mentally remap the files to their location on you computer while you are reading the documentation.  For example, if you install Code Composer in c:\CCStudio_v3.1dsk6713 the led example would be located at c:\CCStudio_v3.1dsk6713\examples\dsk6713\bsl\led.

2)	Load the led.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the led.out file in the led\Debug directory in the file browser and hit "Open" to load the executable file.  You must reload the compiled executable every time you make changes to the program.

3)	Select the Debug · Run option under the Debug menu.  LED #0 will start blinking slowly.

4)	Move DIP switch #3 up and down, you will see LED #3 change with it.

5)	When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

To examine the program code, expand the Projects tree at the left of the workspace, then expand the led.pjt and Source subitems.  Double click on led.c to see its contents.  You should something like this:

LED Example Description

Program execution starts at the beginning of main().  The first call is to DSK6713_init() which initializes the Board Support Library (BSL).  The BSL is a library designed specifically to make it easier to use the components on the DSK board.  DSK6713_init() should be called before any other BSL functions.  You can recognize BSL calls easily because they all start with the prefix DSK6713.  The BSL programming interface is described fully in the BSL section of this help file.  The BSL functions are included as a library called dsk6713bsl.lib.

The LED example demonstrates use of the LED and DIP switch BSL modules.  Each has its own initialization function that must be called before other functions in the module.  The DSK6713_LED_toggle() call toggles the state of LED #0.  A software delay loop call:

/* Spin in a software delay loop for about 200ms */

DSK6713_waitusec(200000);

introduces a roughly 200 millisecond display before toggling the LED again.  This delay loop is responsible for controlling the speed of the blinking LED,.

The DSK6713_DIP_get() function reads the state of LED #3.  If the switch is pressed down, the call will return 0, prompting the call to DSK6713_LED_on() to turn LED #3 on.  If the switch is up, the opposite will occur and DSK6713_LED_off() will be called to turn the LED off.  Since all of this code is in a while loop with no termination condition, the program will run forever unless you halt it with Code Composer.

Making Simple Changes

In order to become familiar with Code Composer, this example will take a quick walk through the steps involved in making simple changes to the example.  One of the easiest changes to make is to make the LED blink at a higher rate.

The DSK6713_waitusec() call inserts a polled delay between each LED toggle.  Change the statement:

/* Spin in a software delay loop for about 200ms */

DSK6713_waitusec(200000);

to:

/* Spin in a software delay loop for about 100ms */

DSK6713_waitusec(100000);

This will cut the delay in half and increase the blink rate by a factor of 2.

To try out your new changes:

1)	Save the program code that was just modified.  Select File · Save.

2)	Re-compile your program.  Every time you make changes to your code you must re-compile the source code to generate a new executable file.  Select Project · Build.  Wait for the build to complete before going continuing.

3)	Load the new led.out executable file.  Select File · Load Program then select led.out in the led\Debug directory in the file browser.

4)	Select the Debug · Run.  LED #0 will start blinking twice as quickly as the original version.

5)	When you are satisfied that the changes you’ve made have actually made the LED blink faster, stop the program by selecting Debug · Halt.


Software Overview

The DSK comes with supplemental software that can be divided into the following categories.  Before you start writing your own programs, please read the section entitled Intro to DSP/BIOS on the DSK.

Board Support Library

The Board Support Library is a software library that allows easy access to on-board peripheral devices.  It is divided into separate modules for the LEDs, DIP switches and codec.  The BSL comes with two examples that demonstrate its use, one manipulates the LEDs and DIP switches, the other generates a sine wave through the codec.

Examples

Five DSK specific examples demonstrate usage of the BSL and DSP/BIOS configuration.  They start with simple LED blinkers and progress into advanced audio codec examples using DMA and IOM drivers for data transfer.

Power On Self Test (POST)

The POST is a small diagnostic program programmed into the Flash memory of the 6713 DSK that performs basic tests every time the DSK is powered up.  It is initially programmed before it is delivered to the customer but documentation is included that demonstrates how to program the POST into Flash as an example of developing programs that can be run in standalone mode.  The programming process involves two other Code Composer tools, FlashBurn and the Hex Conversion Utility.

Utilities

The DSK ships with a diagnostic utility that is used to perform detailed tests on the various board subsystems such as the DSP core, codec, memory and on-board emulation.  It can run in standalone mode or from within Code Composer.


Datasheets and DSK Documentation

The following datasheets can be viewed in Adobe Acrobat Reader as a .pdf file by clicking on the links below.  You can find more technical information about Code Composer and the C64x family here.  All of these documents exist in .pdf format in the docs\pdf directory of your Code Composer installation.

Additional DSK specific design content such as gerber files in raw format are available for a nominal fee from Spectrum Digital.  For contact info, visit the Spectrum Digital web site (www.spectrumdigital.com).

Datasheets

Part	Description
TMS320C6713	TMS320C6713 datasheet.  Check for most recent errata on the TI web site.
SPRU190D	TMS320C6000 Peripherals Reference Guide
TLV320AIC23	AIC23 Codec
AM29LV400	Flash
MT48LC2M32B2	SDRAM
TPS54310PWP	Voltage regulator
6713 DSK Specific Documentation

Filename	Description
6713_dsk_schem.pdf	Schematics
6713_dsk_techref.pdf	Technical Reference
6713_dsk_quickstartguide.pdf	Quick Start Install Guide
6713_dsk_bom.pdf	Bill of Materials
6713_dsk_gerber.pdf	Gerber Files for Board
6713_dsk_mechanical.pdf	Mechanical Information
6713_dsk_netlist.pdf	Netlist
6713_dsk_vhdl.pdf	VHDL for 6713DSK CPLD


Schematics

The schematics for the DSK can be viewed in Adobe Acrobat Reader as a .pdf file by clicking on the link below.

Schematics


Package Contents and Installation

Installation

Click to view the Quick Start Installation Guide in .pdf format.


POST Overview

The Power On Self Test (POST) is a small program in FLASH ROM which the 6713 DSK runs when it is turned on. The POST checks basic functionality and integrity of the board.  The POST uses the four user LED’s to indicate the progress of the test and indicate any failures.

The POST runs nine tests in series while displaying the index number of each test (in binary) on the LED’s as they are running.  If an error is detected while running a test the LED’s will go from a steady state and start blinking with the number of the test that failed.  If all tests complete successfully, all four LED’s will blink three times then stop will all LED’s turned on.

The POST performs simple tests that can be completed quickly without any user input.  More exhaustive interactive tests can be run with the 6713 DSK Diagnostic Utility.  It is important to remember that the POST is simply a program in the Flash memory.  If you erase or alter the Flash, the POST will be overwritten.  You can use FlashBurn to put the POST back in Flash.

The POST source code is included in the dsk6713 examples directory.


POST Test Descriptions

The table below describes each test performed by the POST.  The index of the test in progress is displayed on the user LEDs.  If the test fails the index of the test that fails will blink continuously.


Tone Example

The tone example (in c:\CCStudio_v3.1\examples\dsk6713\bsl\tone) is a slightly more complicated program that directs the AIC23 codec to generate a 1KHz sine wave on the line and headphone outputs.  Follow these instructions to load and run the tone example.

1)	Close and projects you were working with previously by selecting Project · Close.  You should also close any open files you have open in your workspace avoid confusion.  Click on the X in the upper right hand corner of their windows to close them.

2)	Plug a pair of headphones or speakers into the DSK’s headphone jack.

3)	Open the tone.pjt Code Composer project using Project · Open and selecting tone.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\tone.

4)	Load the tone.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the tone.out file in the tone\Debug directory in the file browser and hit "Open" to load the executable file.

5)	Select the Debug · Run option under the Debug menu.  You will hear a 1KHz tone.

6)	After 5 seconds the sound will stop.

When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

The array sinetable contains a pre-generated sine wave using signed 16-bit data that matches the AIC23.  The data covers exactly one period and the amplitude matches the full range of the codec.

#define SINE_TABLE_SIZE   48

/* Pre-generated sine wave data, 16-bit signed samples */

Int16 sinetable[SINE_TABLE_SIZE] = {

    0x0000, 0x10b4, 0x2120, 0x30fb, 0x3fff, 0x4dea, 0x5a81, 0x658b,

    0x6ed8, 0x763f, 0x7ba1, 0x7ee5, 0x7ffd, 0x7ee5, 0x7ba1, 0x76ef,

    0x6ed8, 0x658b, 0x5a81, 0x4dea, 0x3fff, 0x30fb, 0x2120, 0x10b4,

    0x0000, 0xef4c, 0xdee0, 0xcf06, 0xc002, 0xb216, 0xa57f, 0x9a75,

    0x9128, 0x89c1, 0x845f, 0x811b, 0x8002, 0x811b, 0x845f, 0x89c1,

    0x9128, 0x9a76, 0xa57f, 0xb216, 0xc002, 0xcf06, 0xdee0, 0xef4c

};

The main loop of the code writes each data point in the sine wave table out to the codec using the AIC23 codec package of the BSL.  Each write function sends a single 16 bit sample to the codec.  In this case the same data is sent out twice, once to the left channel and once to the right channel.  The codec is configured to accept data at a rate of 48,000 stereo samples per second.  Since the sine table is 48 entries long, the resulting output wave will be a 1KHz sine wave with the same output on both the left and right channels.

// Generate a 1KHz sine wave for 5 seconds

for (msec = 0; msec < 5000; msec++)

{

    for (sample = 0; sample < SINE_TABLE_SIZE; sample++)

    {

        while (!DSK6713_AIC23_write(hCodec, sinetable[sample]));

        while (!DSK6713_AIC23_write(hCodec, sinetable[sample]));

    }

}

The serial port McBSP1 is used to transmit data to the codec at a much slower rate than the DSP can process data.  It accepts data 16 bits at a time and shifts them out slowly one at a time.  The write function returns a 1 if the write is completed successfully or a 0 if the serial channel is busy.  The while() loop around the writes waits while the serial port is busy so program can be synchronized to the data rate of the codec.

The following two commands are used to initialize and shut down the codec and are found at the beginning and end of all programs that use BSL codec module.  The DSK6713_openCodec() command returns a handle that is passed each of the other codec functions.

// Start the codec

hCodec = DSK6713_AIC23_openCodec(0, &config);

// Close the codec

DSK6713_AIC23_closeCodec(hCodec);


One of the most important pieces of the codec code is the setup structure defined at the top of the code:

/* Codec configuration settings */

DSK6713_AIC23_Config config = { \

    0x0017,  /* 0 DSK6713_AIC23_LEFTINVOL  Left line input channel volume */ \

    0x0017,  /* 1 DSK6713_AIC23_RIGHTINVOL Right line input channel volume */\

    0x01f9,  /* 2 DSK6713_AIC23_LEFTHPVOL  Left channel headphone volume */  \

    0x01f9,  /* 3 DSK6713_AIC23_RIGHTHPVOL Right channel headphone volume */ \

    0x0010,  /* 4 DSK6713_AIC23_ANAPATH    Analog audio path control */      \

    0x0000,  /* 5 DSK6713_AIC23_DIGPATH    Digital audio path control */     \

    0x0000,  /* 6 DSK6713_AIC23_POWERDOWN  Power down control */             \

    0x0043,  /* 7 DSK6713_AIC23_DIGIF      Digital audio interface format */ \

    0x0081,  /* 8 DSK6713_AIC23_SAMPLERATE Sample rate control */            \

    0x0001   /* 9 DSK6713_AIC23_DIGACT     Digital interface activation */   \

};

The ten values correspond to the ten internal configuration registers on the AIC23.  Changing the values allows the codec to be set up in different modes or enable and disable certain functions.  Parameters can be set statically with the DSK6713_openCodec() function or dynamically with the DSK6713_config() function.  Please see the help section on the AIC23 for full definitions of the registers.


DSK_App Example

The DSK_App example digitally processes audio data from the line input on the AIC23 codec and plays the result on the headphone and line output.  It uses the McBSP and EDMA to efficiently handle the data transfer without intervention from the DSP.  The example resides in c:\CCStudio_v3.1\examples\dsk6713\bsl\dsk_app.

The EDMA driven audio implemented by the audio example is highly optimized and representative of what might be used in production code.  It is a good base to use for your own audio code.

If no DIP switches are pressed, the example simply passes the audio from the line-in to the audio outputs.  LEDs #2 and #3 toggle as the data is being transferred.  If the DIP switches are depressed, the following things occur:

Dip Switch #	Function
0	Blink LED #0 once per second.
1	Add a dummy load that takes 20-25% of the processor time.

The functions are independently controlled so you can, for example, blink LED #0 and add the dummy load at the same time


Running the DSK_App Example

Follow these instructions to load and run the DSK_App example.

1)	Close and projects you were working with previously by selecting Project · Close.  You should also close any open files you have open in your workspace avoid confusion.  Click on the X in the upper right hand corner of their windows to close them.

2)	Plug a pair of headphones or speakers into the DSK’s headphone jack.  Also connect an audio source like a CD player to the line input of the DSK using a standard 1/8" male to male audio cable.

3)	Make sure all your DIP switches are in the up position.

4)	Open the DSK_App.pjt Code Composer project using Project · Open and selecting DSK_App.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\DSK_App.

5)	Enable RTDX by selecting Tools · RTDX · Configuration Control and checking the Enable RTDX checkbox.  RDTX is a communication protocol that allows your program to communicate with Code Composer through the embedded USB emulator.  The settings should be set for non-continuous mode with a buffer size of 1024.  You can close this window by right clicking on the gray window area and selecting close.  For more information about RTDX please see the RTDX section in the main Code Composer help.

6)	Enable the CPU load plugin by selecting DSP/BIOS · CPU Load Graph.  The load graph will appear at the bottom of your Code Composer window.  You can make it a movable window by right-clicking on it and selecting Float In Main Window.

7)	Load the DSK_App.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the DSK_App.out file in the DSK_App\Debug directory in the file browser and hit "Open" to load the executable file.

8)	Select the Debug · Run option under the Debug menu.  You will hear your audio source playing through the DSK on the headphone output.  Adjust the volume of your audio source until you get to a comfortable listening level.

You will see LEDs #2 and #3 blinking.  They toggle every time a ping or pong buffer is received.  You will also see a display on the CPU load graph indicating what percentage of the total cycles are spent doing real work.  It should be well under 10%.

9)	Press DIP switch #0.  This will instruct the periodic thread blinkLED() to blink LED #0.

10)	Press DIP switch #1.  This will enable a 20-25% dummy CPU load that represents other computation the DSP may be doing.  You will see the CPU load go up by a substantial amount.

When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.


DSK_App Data Transfer

Audio data is transferred back and forth from the codec through McBSP1, a bidirectional serial port.  The EDMA is configured to take every 16-bit signed audio sample arriving on McBSP1 and store it in a buffer in memory until it can be processed.  Once it has been processed, it is sent back out through McBSP2 to the codec for output.  One EDMA channel is used to transmit data to the codec while another is used to receive data from the codec.  A full description of the codec interface can be found in the CODEC Overview.

The example uses EDMA to relieve the DSP from the duty of data transfer.  The EDMA controller takes incoming audio data directly from McBSP1 and places it in a memory buffer.  It also takes data from a memory buffer and sends it to McBSP1 to generate the audio output.  Separate EDMA channels are used to transmit and receive audio data.

Two special features to implement an especially robust and efficient data transfer infrastructure:

1)  Ping-pong buffering

3)  Linked EDMA transfers

Data Transfer Overview

The following figure illustrates the flow of audio data through the program:

Digital audio data is received from the codec on McBSP2.  The audio data is a series of 16-bit signed integers representing the amplitude of the input waveform at a particular point in time.  Since the AIC23 is a stereo codec, the audio input consists of both left and right audio channels.  Data is received in a frame consisting of two elements, one 16-bit sample from the left channel followed by one 16-bit sample from the right channel.  Frames are received at a rate of 48KHz, the DSK’s default sample rate.

Ping-Pong Transfers

At the highest level, the DMA controller reads audio data from the McBSP and places it in a buffer in memory.  On the data receive side there are two logical buffers, receive PING and receive PONG.  When the first data comes in it is placed in the PING buffer.  When it is full, new data is redirected to the PONG buffer and the DSP is free to process the PING data without fear of it being overwritten.  When the PONG buffer fills up, the configuration is reversed.  The ping-ponging data transfer continues indefinitely with one buffer always hosting the active transfer and one remaining stable for the DSP to operate on.  If only one buffer is used, the DSP must process all of the data between the instant the buffer fills up and the next audio sample arrives.  When ping-pong buffers are used, the DSP can take as long as the time it takes to fill an entire buffer to process the data, making it much easier to meet a real-time schedule.

Separate input and output buffers are used to decouple the receive side from the transmit side while data is being processed.  The output buffers are also of the ping-pong variety so there are a total of four logical buffers, receive PING, receive PONG, transmit PING and transmit PONG.

Int16 gBufferRcvPing[BUFFSIZE];  // Transmit PING buffer

Int16 gBufferRcvPing[BUFFSIZE];  // Transmit PONG buffer

Int16 gBufferRcvPong[BUFFSIZE];  // Receive PING buffer

Int16 gBufferRcvPong[BUFFSIZE];  // Receive PONG buffer

EDMA Linked Transfers

The final special data transfer feature is called linked transfers.  When the EDMA finishes with the PING side and needs to switch to the PONG side, the source and destination pointers need to be changed to point at the new buffer.  When linked transfers are used, the new address can stored in a link configuration structure and automatically by loaded by the EDMA controller when the current transfer is complete.  The reconfiguration can also be handled by the DSP in software interrupt service routine but using linked transfers removes the scheduling requirement that the software finish before the next sample is received to get uninterrupted audio.


DSK_App EDMA Settings

This section describes the DMA settings the example uses to implement its optimized data transfer.  These settings can be found in the DMA settings in the DSP/BIOS configuration manager under Chip Support Library · DMA · DMA Configuration Manager.  Only the receive settings are shown, reasoning behind the settings is essentially identical for the transmit side.

The example uses 1024 word buffers (#defined as BUFFSIZE at the top of the program) to store audio data.  Channel 1 of the DMA controller is configured to group 512 two element frames into a logical unit called a block, just enough to fill a complete buffer.  Each frame represents one stereo sample, a pair of 16-bit words of audio data consisting of a left sample followed by a right sample.

The DMA is set to read data directly from McBSP2 data register which resides at 0x3001 in I/O space (byte address 0x6002).  When an element is read (triggered by an event fom the McBSP when a full serial word has been received) the DMA controller increments the source address by some amount based on the addressing mode.  Since the McBSP2 data register is in a fixed location, the addressing mode is set to constant so the source will not change.

The destination of the DMA is the first data buffer which starts at gBufferRcvPingL.  This is only the initial address.  The destination address is updated by the code whenever it switches between PING and PONG transfer mode.

The DMA receives channel-interleaved audio data from its McBSP source.  The destination addressing mode is configured for double-indexing to perform the channel sorting.  In double-index mode, the value of the CEI (Channel Element Index) register is added to the destination address when each element is received.  The value of the CFI (Channel Frame Index) is added to the destination address when each frame is complete.  Since the example only uses 2 elements per frame, the net result is that the destination address is modifed by the CEI register after the left element is received and CFI when the right element is received.

The flexibility of these registers allows channel sorting.  Both registers are not set in the DSP/BIOS configuration so they are set manually in initDma().  For a 1024 word buffer, the CEI is set to jump forward by 512 words so the right data gets placed in the top half of the buffer.  The CFI is set to jump back by 511 words (just under  half a buffer length) so the next left element gets placed right after the previous one.  Be careful when reading through initDma().  The registers require byte quantities so BUFFSIZE/2 words becomes BUFFSIZE bytes.  Also, the amount moved is the value + 1 byte so the value needs to be offset by 1.

// Set indices and lengths for receive channel sorting.

DMA_RSETH(hDmaRcv, DMACEI, BUFFSIZE - 1);

DMA_RSETH(hDmaRcv, DMACFI, -(BUFFSIZE - 1));

The DMA control settings show how auto-initialization is enabled.  In addition to the auto-init enable field, the REPEAT and END PROG fields must be set so the configuration registers are always loaded at the end of the transfer.  In this example, it is safe to assume that the registers will be programmed before the data transfer is complete

The final setting is the interrupt enable bit that triggers the interrupt service routine dmaHwi().  End of block interrupts are enabled so the ISR will be called after all frames are transferred.


DSK_App Program Flow

When the program is run, the individual DSP/BIOS modules are initialized as configured in DSK_App.cdb with the DSP/BIOS configuration tool.  The main() function is then called as the main user thread.  In this example main() performs application initialization and starts the EDMA data transfers.  When main exits, control passes back entirely to DSP/BIOS which services any interrupts or threads on an as-needed basis.  When there is no work to be done and idle thread is run.  EDMA interrupts will pre-empt the idle thread.

The edmaHwi() interrupt service routine is called when a buffer has been filled.  It contains a state variable named pingOrPong that indicates whether the buffer is a PING or PONG buffer.  dmaHwi() switches the buffer state to the opposite buffer and calls the SWI thread processBuffer() to process the audio data.  processBuffer() is responsible for manually transferring receive data to the transmit buffers.  It can be replaced with code that processes the data rather than copying it.

Two periodic threads (blinkLED() and load()) run asynchronously with the audio processing as a demonstration of DSP/BIOS multitasking.  blinkLED() runs every 500ms and checks DIP switch #0.  If it is depressed, the thread will toggle the LED.  load() runs every 10ms and starts by checking DIP switch #1.  If it is depressed, load() will run for a small amount of time simulating a workload occupying 20-25% of the processor time.


Web Links

Additional technical information can be found on the following web pages:

Spectrum Digital Web:

SDI Home Page

http://www.spectrumdigital.com

TI Web:

TI SC Home Page

http://www.ti.com/

TI SC Distributors

http://focus.ti.com/docs/general/distributor.jhtml

TI Support and Product Centers

http://www.ti.com/corp/technical_support.htm

DSP Solutions

http://dspvillage.ti.com/

TI Training

http://www.ti.com/sc/docs/training/training.htm


CODEC Overview

The DSK uses a Texas Instruments AIC23 (part #TLV320AIC23) stereo codec for input and output of audio signals.  The codec samples analog signals on the microphone or line inputs and converts them into digital data that can be processed by the DSP.  When the DSP is finished with the data it uses the codec to convert the samples back into analog signals on the line and headphone outputs so the user can hear the output.

The codec communicates using two serial channels, one to control the codec’s internal configuration registers and one to send and receive digital audio samples.  The AIC23 supports a variety of configurations that affect the data formats of the control and data channels, the following summarizes the preferred setup for the 6713 DSK, more detailed descriptions are given below.

Preferred AIC23 Setup

Control Channel	McBSP0, SPI mode with internal clocks and frame syncs.
Data Channel	McBSP1, AIC23 in master mode with 12MHz system clock.  Data in codec’s DSP format with each sample consisting of one frame with two 16-bit elements corresponding to left and right.  Clocks and frame syncs generated by the AIC23 external to the DSP.

For more information please see the AIC23 datasheet.


Control Channel

The codec control channel is used to set the AIC23’s internal registers and is uni-directional.  The AIC23 takes in 16-bit data words in SPI format on the control channel.  The top 7 bits specify the register number to set and the lower 9 bits specify the register data.  The register definitions are listed here.  The BSL functions DSK6713_AIC23_rset() and DSK6713_AIC23_rget() are provided to access the codec registers.

The 6713 DSK uses McBSP0 as the codec control channel.  SPI mode is one of the simplest data transmit formats and is used by many devices for basic communication.  In SPI mode the data is simply clocked in with a chip select signal that frames the data word.

SPI Mode Timing

The McBSP is connected to the codec as follows:

McBSP0	AIC23
FSX – Transmit Frame Sync	LRCIN – Left-Right Clock input
CLKX – Data Clock	BCLK – Data Clock
DX – Transmit Data	DIN – Receive Data
To configure McBSP0 as the control channel, the DX, FSX and CLKX pins must be enabled as serial port pins (not GPIO) and the McBSP put in SPI mode.  Since the data frame starts when CS drops low and data transmission starts immediately and the the data should be sent out on the falling clock edge so it can be clocked in by the AIC23 on the rising edge, the specific SPI mode is "Falling Edge w/o Delay".

The McBSP drives all the signals so it is in "Master" mode.  The "Frame-Sync" polarity is active low so CS is driven low to start the frame.  No special delays need to be added.  The only other significant setting is the "Transmit Frame-Sync Source".  This is the trigger for the data transmission.  Selecting "DSX · XSR Copy" indicates that the data transmission should start when something is written into the transmit register.

The final setting to be made is the transmit length.  It is a single 16-bit word.


Data Channel

The codec data channel is used to transmit and receive audio samples to the AIC23.  The data format is selectable by programming the FOR bits in the Digital Audio Interface Format register on the codec.  The preferred mode is the DSP mode which was designed to interface seamlessly with a Texas Instruments McBSP.  The BSL functions DSK6713_AIC23_read() and DSK6713_AIC23_write() are provided to read and write audio sample data to the McBSP once it has been configured.

The 6713 DSK uses McBSP1 as the codec data channel.  DSP mode is a relatively simple mode where a high to low transition of LRCIN (for audio output) or LRCOUT (for audio input) starts the data flow.  The data consists of 32 data bits, 16 for the right audio channel sample and 16 for the left audio sample.  The data clocks and LRCIN/OUT are generated automatically by the codec when it is in master mode (the MS bit, also in the Digital Audio Interface Format codec register).  Sample rates and widths are also selectable through codec registers with the default settings being 16-bits at 48KHz.

DSP Mode Timing

The McBSP is connected to the AIC23 as follows:

McBSP1	AIC23
FSX – Transmit Frame Sync	LRCIN – Left-Right Clock input
FSR – Receive Frame Sync	LRCOUT – Left-Right Clock output
CLKX – Data Clock	BCLK – Data Clock
DX – Transmit Data	DIN – Receive Data
DR – Receive Data	DOUT – Transmit data

To configure McBSP1 as the control channel, both the transmit and receive pins must be enabled as serial port pins (not GPIO) and the McBSP should not be in SPI mode.

Since data should be clocked out on the falling clock edge so the AIC23 can clock it in on the rising edge, the "Clock Polarity" should be set to "Falling Edge".  Both the clock and frame sync must be set to read from the external sources generated by the AIC23.  The "Frame-Sync Polarity" is set to "Active High" even though the LRCIN/OUT signals are active low because external frame sync signals are inverted before they are sampled.

The transmit length is 16-bits with 2 words per frame.  That specifies that the samples should be read as 2 separate 16-bit words instead of one 32-bit word.

The receive settings are copies of the transmit settings but with the clock polarity set to "Rising Edge" instead of  "Falling Edge".  This is because the AIC23 is transmitting on the falling edge when sending data to the 6713 so it can be clocked in on the rising edge.


CODEC Registers

The AIC23 has 10 registers that control functions such as volume, data formats, sample rates and power down modes.  The registers are written to through the control channel on McBSP0.  Register definitions are taken from the AIC23 datasheet for quick reference.

AIC23 Codec Register Definitions

0 - Left Input Volume (DSK6713_AIC23_LEFTINVOL)

1 - Right Input Volume (DSK6713_AIC23_RIGHTINVOL)

2 - Left Headphone Volume (DSK6713_AIC23_LEFTHPVOL)

3 - Right Headphone Volume (DSK6713_AIC23_RIGHTHPVOL)

4 - Analog Audio Path Control (DSK6713_AIC23_ANAPATH)

5 - Digital Audio Path Control (DSK6713_AIC23_DIGPATH)

6 - Power Down Control (DSK6713_AIC23_POWERDOWN)

7 - Digital Audio Interface Format (DSK6713_AIC23_DIGIF)

8 - Sample Rate Control (DSK6713_AIC23_SAMPLERATE)

9 - Digital Interface Activation (DSK6713_AIC23_DIGACT)

15 - Reset Register (DSK6713_AIC23_RESET)


CPLD VERSION Register (I/O Address 0x0004)

The VERSION register contains two fields that indicate the DSK board and CPLD versions.  This register will allow your software to differentiate between production releases of the DSK and account for any variances.  This register is not expected to change often, if at all.

VERSION Register Definition


CPLD USER_REG Register

USER_REG is used to read the state of the 4 DIP switches and turn the 4 LEDs on or off to allow the user to interact with the DSK.  The DIP switches are read by reading the top 4 bits of the register and the LEDs are set by writing to the low 4 bits.

USER_REG Register Definition


C6713 DSK Tutorial

Overview

The 6713 DSP Starter Kit (DSK) is a low-cost platform which lets customers evaluate and develop applications for the Texas Instruments C67X DSP family.  The primary features of the DSK are:

•	225 MHz TMS320C6713 Floating Point DSP

•	AIC23 Stereo Codec

•	Four Position User DIP Switch and Four User LEDs

•	On-board Flash and SDRAM

TI’s Code Composer Studio development tools are bundled with the 6713 DSK providing the user with an industrial-strength integrated development environment for C and assembly programming.  Code Composer Studio communicates with the DSP using an on-board JTAG emulator through a USB interface.

Board Tour

The figure below illustrates the main sections of the board:

The TMS320C6713 DSP is the heart of the system.  It is a core member of  Texas Instruments’ C64X line of fixed point DSPs whose distinguishing features are an extremely high performance 225MHz VLIW DSP core and 256Kbytes of internal memory.  On-chip peripherals include a 32-bit external memory interface (EMIF) with integrated SDRAM controller, 2 multi-channel buffered serial ports (McBSPs), two on-board timers and an enhanced DMA controller (EDMA).  The 6713 represents the high end of TI’s C6700 floating point DSP line both in terms of computational performance and on-chip resources.

The 6713 has a significant amount of internal memory so many applications will have all code and data on-chip.  External accesses are done through the EMIF which can connect to both synchronous and asynchronous memories.  The EMIF signals are also brought out to standard TI expansion bus connectors so additional functionality can be added on daughtercard modules.

DSPs are frequently used in audio processing applications so the DSK includes an on-board codec called the AIC23.  Codec stands for coder/decoder, the job of the AIC23 is to code analog input samples into a digital format for the DSP to process, then decode data coming out of the DSP to generate the processed analog output.  Digitial data is sent to and from the codec on McBSP1.

The DSK has 4 light emitting diodes (LEDs) and 4 DIP switches that allow users to interact with programs through simple LED displays and user input on the switches.  Many of the included examples make use of these user interface options.

The DSK implements the logic necessary to tie board components together in a programmable logic device called a CPLD.  In addition to random glue logic, the CPLD implements a set of 4 software programmable registers that can be used to access the on-board LEDs and DIP switches as well as control the daughtercard interface.

Development Environment

Code Composer Studio is TI’s flagship development tool.  It consists of an assembler, a C compiler, an integrated development environment (IDE, the graphical interface to the tools) and numerous support utilities like a hex format conversion tool.  The DSK includes a special version of Code Composer specially tailored to features on the 6713 DSK board.  Other versions of Code Composer are available that fully support each of TI’s processor families on a wide variety of hardware targets.

The Code Composer IDE is the piece you see when you run Code Composer.  It consists of an editor for creating source code, a project manager to identify the source files and options necessary for your programs and an integrated source level debugger that lets you examine the behavior of your program while it is running.  The IDE is responsible for calling other components such as the compiler and assembler so developers don’t have to deal with the hassle of running each tool manually.

The 6713 DSK includes a special device called a JTAG emulator on-board that can directly access the register and memory state of the 6713 chip through a standardized JTAG interface port.  When a user wants to monitor the progress of his program, Code Composer sends commands to the emulator through its USB host interface to check on any data the user is interested in.

This debugging method is extremely powerful because programs can be debugged unobtrusively on real hardware targets without making any special provisions for debug like external probes, software monitors or simulated hardware.  When designing your own hardware around the 6713 you can debug your application with the same rich functionality of the DSK simply by using Code Composer with an external emulator and including a header for the JTAG interface signals.

You should always be aware that the DSK as a different system than your PC, when you recompile a program in Code Composer on your PC you must specifically load it onto the 6713 on the DSK.  Other things to be aware of are:

•	When you tell Code Composer to run, it simply starts executing at the current program counter.  If you want to restart the program, you must reset the program counter by using Debug · Restart or re-loading the program which sets the program counter implicitly.

•	After you start a program running it continues running on the DSP indefinitely.  To stop it you need to halt it with Debug · Halt.

Loading and Running a Program

The best way to get started with Code Composer is to run some of the simple examples included with the DSK.  The LED example is the easiest example to get started with to become familiar with the DSK and make sure your development tools are configured correctly.  When run, it will:

•	Continuously blink LED #0 about 2.5 times per second.

•	Continuously read the value of DIP switch #3 and display it on LED #3.

To run the program, perform the following steps:

6)	Open the led.pjt Code Composer project using Project · Open and selecting led.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\led.

The default install directory for Code Composer is c:\CCStudio_v3.1.  All of the DSK specific documentation refers to file paths as if they were installed in the default location.  If you install Code Composer in a different location, please remember to mentally remap the files to their location on you computer while you are reading the documentation.  For example, if you install Code Composer in c:\CCStudio_v3.1dsk6713 the led example would be located at c:\CCStudio_v3.1\dsk6713\examples\dsk6713\bsl\led.

7)	Load the led.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the led.out file in the led\Debug directory in the file browser and hit "Open" to load the executable file.  You must reload the compiled executable every time you make changes to the program.

8)	Select the Debug · Run option under the Debug menu.  LED #0 will start blinking slowly.

9)	Move DIP switch #3 up and down, you will see LED #3 change with it.

10)	When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

To examine the program code, expand the Projects tree at the left of the workspace, then expand the led.pjt and Source subitems.  Double click on led.c to see its contents.  You should something like this:

LED Example Description

Program execution starts at the beginning of main().  The first call is to DSK6713_init() which initializes the Board Support Library (BSL).  The BSL is a library designed specifically to make it easier to use the components on the DSK board.  DSK6713_init() should be called before any other BSL functions.  You can recognize BSL calls easily because they all start with the prefix DSK6713.  The BSL programming interface is described fully in the BSL section of this help file.  The BSL functions are included as a library called dsk6713bsl.lib.

The LED example demonstrates use of the LED and DIP switch BSL modules.  Each has its own initialization function that must be called before other functions in the module.  The DSK6713_LED_toggle() call toggles the state of LED #0.  A software delay loop:

/* Spin in a software delay loop for about 200ms */

DSK6713_waitusec(200000);

introduces a roughly 200 millisecond display before toggling the LED again.  This delay loop is responsible for controlling the speed of the blinking LED.

The DSK6713_DIP_get() function reads the state of LED #3.  If the switch is pressed down, the call will return 0, prompting the call to DSK6713_LED_on() to turn LED #3 on.  If the switch is up, the opposite will occur and DSK6713_LED_off() will be called to turn the LED off.  Since all of this code is in a while loop with no termination condition, the program will run forever unless you halt it with Code Composer.

Making Simple Changes

In order to become familiar with Code Composer, this example will take a quick walk through the steps involved in making simple changes to the example.  One of the easiest changes to make is to make the LED blink at a higher rate.

The DSK6713_waitusec() call inserts a polled delay between each LED toggle.  Change the statement:

/* Spin in a software delay loop for about 200ms */

DSK6713_waitusec(200000);

to:

/* Spin in a software delay loop for about 100ms */

DSK6713_waitusec(100000);

This will cut the delay in half and increase the blink rate by a factor of 2.

To try out your new changes:

1)	Save the program code that was just modified.  Select File · Save.

2)	Re-compile your program.  Every time you make changes to your code you must re-compile the source code to generate a new executable file.  Select Project · Build.  Wait for the build to complete before continuing.

3)	Load the new led.out executable file.  Select File · Load Program then select led.out in the led\Debug directory in the file browser.

4)	Select the Debug · Run.  LED #0 will start blinking twice as quickly as the original version.

5)	When you are satisfied that the changes you’ve made have actually made the LED blink faster, stop the program by selecting Debug · Halt.

Introduction to DSP/BIOS

Even though the LED example may seem simple, it is built on top of TI’s DSP/BIOS, a real-time multitasking kernel.  One of the features of the Code Composer development environment is its close integration with DSP/BIOS which allows users to easily add functionality to their code that typically requires a considerable amount of effort with other tools.  All of the DSK specific examples use DSP/BIOS.

DSP/BIOS programs are organized such that logically independent parts of a program are executed as independent tasks and threads.  In the context of an application like a mobile phone, one task could be assigned to listening for wireless communication transfers, another assigned to wait for user input, another to periodically check the battery level and so on rather than have a single task try to do all of these things at once.  In addition to basic task scheduling, DSP/BIOS also includes components that allow communication and synchronization between tasks and devices.

Using the BIOS Configuration Tool

The ledprd example is a separate example that is performs the exact same function as the led example using the DSP/BIOS scheduler to run a periodic thread every 200ms instead of using the software delay loop.  Follow these instructions to load and run the ledprd example.

1)	Close the LED project you were working with previously by selecting Project · Close.  You should also close any open files you have open in your workspace such as led.c and led.cdb to avoid confusion.  Click on the X in the upper right hand corner of their windows to close them.

2)	Open the ledprd.pjt Code Composer project using Project · Open and selecting ledprd.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\ledprd.

3)	Load the led.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the led.out file in the ledprd\Debug directory in the file browser and hit "Open" to load the executable file.

4)	Select the Debug · Run option under the Debug menu.  LED #0 will start blinking slowly.

5)	Move DIP switch #3 up and down, you will see LED #3 change with it.

6)	When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

To examine the program code, expand the Projects tree at the left of the workspace, then expand the ledprd.pjt and Source subitems.  Double click on ledprd.c to see its contents.

You can see that only initialization is done in the main() function.  When main() is finished, it returns back to the DSP/BIOS scheduler which takes over responsibility of finding more work to be done.  In this case, blinkLED0() is defined as a periodic thread that is scheduled to run every 200ms.  Advantages of this method are:

•	No time is wasted spinning in loops.  Work is done when it is scheduled or a resource that work depends on becomes available.

•	Independent work can be separated into logical threads that are managed by DSP/BIOS, simplifying your code.

  To view the scheduler settings:

1)	Expand the "DSP/BIOS Config" entry in the project view.  Double-click on the ledprd.cdb file to open it with the BIOS configuration tool.

2)	Expand the "Scheduling" entry in the configuration tool view.  This exposes groups of configurable parameters related to scheduling.

3)	Expand the PRD - Periodic Function Manager section to see a list of currently scheduled periodic threads.  There will be one scheduled entry called PRD_blinkLED0.  Right click on it and select Properties.

You should see something like this:

The function is the name of the thread containing the code to be run, in this case _blinkLED0.  The leading underscore is required because blinkLED0() is a C function.  Functions written in assembly do not need the underscore.  The period is the period blinkLED0() should be called with in ticks.  Each tick is equivalent to 1ms, so it will be run every 200ms.  Hit cancel to exit out of the properties view.

Adding a Second Thread

A second thread is included in the ledprd.c source file called blinkLED1().  It simply toggles LED #1.  This section shows how to add it as a second thread that blinks LED #1 at a different rate than LED #0.

1)	Expand the Scheduling entry in the DSP/BIOS Configuration Tool and right clock on PRD - Periodic Function Manager.  Select the Insert PRD menu option.  It will create a new scheduling entry called PRD0.

2)	Right click on PRD0 and select Properties.  Change the period field to 100 and the function field to _blinkLED1.  It will look like this when you are done:

3)	Hit OK to confirm the settings.  Single click on PRD0 and the Configuration Tool will let you change the name.  Change it to PRD_blinkLED1.

4)	Save the new DSP/BIOS configuration file.  Select File · Save.

5)	Re-compile your program.  Select Project · Build.

6)	Load the new led.out executable file.  Select File · Load Program then select ledprd.out in the ledprd\Debug directory in the file browser.

7)	Select the Debug · Run.  LED #0 will be blinking as before but LED #1 will also be blinking at twice the rate.

8)	When you are satisfied that both tasks are running, stop the program by selecting Debug · Halt.

What Next?

The 6713 DSK has many components so it’s best to take some time to understand the system before doing serious development.  A good way to start is to read the hardware overview  to get a better picture of the platform then browse through the general Code Composer help to become more familiar with the development environment.  The best all-around place to start looking for information about your DSK is the key features list.

While Code Composer has the comfortable feel of development environments for a PC application, debugging an embedded system like the 6713 DSK is more complicated because you’re in total control of the system.  It won’t do anything unless you tell it to.  In this environment, the best way to have success with the 6713 DSK is to become intimately familiar with the TMS320C6713 DSP itself.

The DSK comes with a Board Support Library and several examples (see the Software Overview) that can jumpstart your development experience.  The BSL contains functions that make using the on-board peripherals easier and the examples demonstrate the most important features of the DSP.

After you’ve started developing, please check the 6713 DSK product page on the Spectrum Digital Web Site (www.spectrumdigital.com) for product updates, FAQs and more example code.

Navigating the Help File

Remember these tips while navigating the help file:

1)	Use the BACK button on the help browser to go back to the previous topic you were looking at.

2)	Use the << and >> buttons to go back and forward to the next logical topic, like going to the next page in a book.


Key Features

These links provide quick access to key features of the DSK.  Click to get more detailed information:

C6713 DSK Tutorial	Quick overview of the DSK and its contents, getting started with Code Composer.
Hardware	Detailed descriptions of the C6713 DSK hardware components.
Board Support Library	Functions that provide an easy interface to DSK hardware.
Examples	Example code that runs on the DSK.
Diagnostic Utility	Host based diagnostics.
Schematics	Schematics for the DSK.
Datasheets	Datasheets related to the DSK.
Troubleshooting/Support	Solutions for problems you might encounter.


DSK Specific Files

The version of Code Composer Studio that comes with the DSK is tailored specifically for use with the DSK in that:

1)	It only works with the DSK board itself.  Full versions of CCS are not board specific in that they can be used with any hardware (including hardware you develop yourself).

2)	DSK specific software and documentation has been added to make using the DSK easier.  Features include the Board Support Library, diagnostic utility, FlashBurn port, help file, technical documentation like schematics and DSK specific .gel file.

Existing Code Composer users may find it useful to see where the DSK specific components fit within the Code Composer file tree.  The following tree lists the main DSK specific components.  Note that the default Code Composer install directory is c:\CCStudio_v3.1.  If you installed Code Composer in a different directory, these files will appear as subdirectories of your new install directory.

CCStudio_v3.1

   bin

      utilities

         flashburn

            C6000

               dsk6713        · DSK port of FlashBurn programmer (FBTC)

   C6000

      dsk6713

         include

            dsk6713.h         · BSL include files

            dsk6713_aic23.h

            .

            .

         lib

            dsk6713bsl.lib    · BSL for large memory model

            dsk6713bsl.zip    · BSL source code

   cc

      gel

         dsk6713.gel          · DSK specific .gel file

   docs

      hlp

         c6713dsk.hlp         · DSK help file

      pdf

         6713_dsk_schem.pdf   · DSK schematics

         6713_dsk_techref.pdf · DSK technical reference

         .

         .

   drivers

      6713DSKDiag.exe         · DSK diagnostic utility

      sdgo6713dsk.dvr         · DSK driver (only works with DSK)

   examples

      dsk6713

         bios

            audio             · Sample applications using BIOS device drivers

         bsl

            dsk_app           · DSK_App example

            led               · LED example

            ledprd            · LEDPRD example

            post              · POST source code

            tone              · Tone example


Where to Go for Support

The 6713 DSK is distributed as an integrated product but in reality it is a joint effort between Spectrum Digital and Texas Instruments.  When you need support it is important to know which company can best handle your needs.

Texas Instruments (support@ti.com, www.ti.com)

Texas Instruments is the company that makes the ‘6713 DSP and the Code Composer Studio development tools.  Contact TI if you are having problems in these areas:

•	Silicon issues with the ‘6713 processor itself.

•	DSP/BIOS, RTDX and the IOM device driver interface.

•	Use of the CCS development environment.

•	Documentation errors within Code Composer except for the ‘6713 DSK specific help.

•	Contacting the TI sales force for pricing and delivery of TI chips.

Spectrum Digital (support@spectrumdigital.com, www.spectrumdigital.com)

Spectrum Digital is a maker of JTAG emulation products and hardware targets for TI DSPs.  Spectrum is responsible for the board level design, on-board JTAG emulation, DSK software and in-kit documentation.  Contact Spectrum Digital if you are having problems with:

•	Installing or using the on-board JTAG emulation.

•	Faulty DSK boards or power supplies.

•	Purchasing external JTAG emulators.

•	Documentation errors in the technical reference, help file or install guide.

•	The Diagnostic Utility or the Board Support Library.

•	BSL Examples and 6713 DSK Tutorial

As the DSK is rolled out, Spectrum Digital will be providing additional help on the DSK product pages of its web site including FAQs related to board specific and emulation issues and snippets of code that may help you use your DSK.


Product Registration

Code Composer Registration

Remember to register your product within 30 days of purchase. Texas Instruments may make available DSK specific patches, utilities or promotions to registered DSK users. You must register your DSK through the online web registration form to enable access through the new Internet enabled Update Advisor.  You can register online during installation if you are connected to the Internet. To register online after installation or to register via fax or by e-mail you can access the registration forms from within Code Composer Studio TM IDE. From the menu bar select Help · CCS on the Web · Register On-line, select the appropriate registration link for your product and follow the instructions on the form.

You will need your Service Code to register the product.  The Service Code is a 16 digit number starting with the letters CCS attached to the CD case.  Note: paid annual software subscription service is not available for DSK products.

DSK Hardware Registration

The DSK hardware can be registered using the on-line registration process at www.spectrumdigital.com.  Spectrum Digital, Inc. warrants the products it produces for 90 days after the date of purchase.  For a product to be considered "in warranty", Spectrum Digital must be notified of the defect within 90 days after being purchased from Spectrum Digital or one of its authorized resellers.  Spectrum Digital is not responsible for accidents, improper installation of connections, misuse, neglect or unauthorized modifications.  If the product qualifies for warranty repair Spectrum Digital may repair or replace the product at its discretion.


Troubleshooting and Support

Code Composer and Examples

Problem	Solution
CCS does not support target error recovery for RTDX/BIOS applications.	To re-enable RTDX/BIOS following target error recovery you must exit CCS and restart CCS.  Otherwise RTDX/BIOS data transmission to/from the host is disabled.  RTDX/BIOS will be target error recovery compliant in a later version of CCS.
Can’t load program right after building it.	When you build your project you must wait until the build process is complete before attempting to load the code into the target.  There is no internal safety check for this.  in addition, any time your want to re-run a program you cannot simply hit run again.  Select the restart option or re-load the program to start again from the beginning.
Nothing happens when you click on a help file link to the schematics or datasheets.	Documents like the schematics and datasheets are stored in Adobe PDF format.  For the link to work you must have Adobe’s acrobat reader installed.
When you halt a program Code Composer will sometimes display a dialog box saying that it cannot find a source code or library file.	When you halt a program Code Composer attempts to display the source code associated with the current program counter.  If the program stops in a system library like the runtime library, DSP/BIOS or the board support library it will not be able to find the source code for debug.  You can either find the source code if you want to debug it or click on the checkbox to ignore messages like this.
Adding printf() calls to my program causes it to crash or become unstable.	The printf() function is not supported for use with DSP/BIOS programs.  Please use the message log functions instead.
I can’t find file xxxx even though the documentation says it should be there.  I did not install Code Composer in c:\CCStudio_v3.1.	The default installation directory is c:\CCStudio_v3.1.  Many of the examples are documented to assume that the install always takes place in c:\CCStudio_v3.1 or a name like TI_DIR or TI_ROOT.  Simply replace the directory name with the location of your install. A similar problem exists where documentation is written to apply to a variety of targets each with a similar directory structure.  If you see a pathname like c:\CCStudio_v3.1\C6000\TARGET_DIR\lib, replace TARGET_DIR with the name of your target (DSK6713).
The LEDs used to blink when I turned the DSK on but they don’t anymore.	The LEDs blink as part of the Power On Self Test.  The POST is burned into the Flash when it leaves the factory but if you alter or erase the Flash the POST will be lost.  You can put the POST back in with FlashBurn.
Code Composer issues warning messages like "system headers out of date" or prompts to automatically upgrade .cdb files to the current version.	This is normal.  Code Composer consists of many parts and the IDE does sanity checks to make sure everything will work together.  Components from projects compiled under older versions of Code Composer need to be updated to insure proper operation.
Programs don’t run stably.  A given program may only run the first time or only after another program has run.	The initialization state of each program is critical in ensuring proper operation.  Please make sure your EMIF, PLL and other peripheral settings are configured properly.
Installation and Startup

Problem	Solution
When you connect your DSK through USB for the first time on a Windows XP PC the new hardware found wizard may not find the driver for about 15 minutes.	The drivers are on the CD but Windows XP does some network accesses before it even checks the CD.  Some firewall configurations can cause the network accesses to fail and Windows will wait for a timeout period before it checks the CD.  If you wait long enough the process will complete normally.  To avoid the wait temporarily unplug the network cable for this part of the install process.
I can’t verify that the driver install was successful.	Go into your device manager and look for the "SD USB Based Debug Tools" hardware class.  There should be one Spectrum Digital TMS320C6713 DSK installed in the class.
Code Composer won’t launch if I power cycle the DSK and try to start CCS really quickly.	Windows needs time to recognize a USB device and get it initializaed.  The Busy LED above the USB connector illuminates when the DSK is powered on during this period.  Do not launch Code Composer until the led turns off.
Both Code Composer and the Diagnostic Utility run fine in Administrator mode but not in user mode.	The solution is to relax the user mode privilege restrictions.  Please see the section at the bottom of this page entitled "Relaxing Administrator Mode Restrictions".

Laptop and Audio Problems

Problem	Solution
If you plug in or unplug your laptop power supply while CCS is running you may get a target error recovery message.	1. Do not plug  or unplug your laptop power supply while CCS is active.  This can cause excessive noise or low voltage levels on the USB signals momentarily.  This may result in a communication failure or data loss, and target error recovery will be invoked. 2. If you must plug or unplug your laptop power supply with CCS active then do a "run free" first.  In this case CCS is not communicating with the target and reduces the likely hood of communication failure or data loss.
When running the audio application with the DSK connected to my PC the volume control is not working.	A Windows PC has several different volume control sources as well as mute buttons.  First test your music/sound using the PC speakers or external headphones connected to the PC.  Then test with the DSK.
When running the audio example on my laptop I hear a lot of background noise.	Exit CCS and remove the laptop power supply input.  Restart CCS and retest.  If the background noise goes away then the problem is coupling from the laptop power supply.  Some laptops exhibit this problem while most do not.  There is not much you can do to overcome this issue. If you are using the speaker output then you may try switching to the line out. If the noise still exists when the PC power is disconnected check your audio cables, and PC settings.  You may be overdriving one of the volume controls and distorting the signal.
Audio gets passed from input to output even if the DSP isn’t running or the DSK is not powered.	Make sure your audio cables are plugged all the way into the jacks on the DSK.

Relaxing Administrator Mode Privileges

On Windows NT, 2000 and XP there is a large distinction between the privileges of programs running in administrator mode vs. user mode.  The 6713 DSK must be installed in Administrator mode but most users will run the program in user mode.  The exact problem depends on your system configuration but stems from two general problems:

1.	The program cannot modify certain pieces of the registry because were marked as read-only in Administrator mode during the install.

2.	The program cannot write to or execute a file because it was created in Administrator mode and User mode programs usually have read-only access to files created by the Administrator.  If you build a project in Administrator mode you will not be able to rebuild it in user mode because CCS will not be able to overwrite the temporary files.

the exact access restriction depends on your system configuration and the operations performed so no one thing will fix all problems.  The following is a list of things you can do to relax the Administrator mode privileges so the user program can get full access to Code Composer related resources:

1.	Allow user mode access to Code Composer’s registry settings.

a)	Log in as an Administrator.

b)	Choose Start · Run from the Windows 2000 Start menu.

c)	Type regedt32 (not regedit) to bring up the Registry Editor.

d)	From the Window menu, select HKEY_LOCAL_MACHINE on the Local Machine.

e)	Expand the SOFTWARE key.

f)	Locate and select the sub-key GODSP.

g)	With GODSP selected, choose Security Permissions... from the menu.

h)	In the upper half of the Permissions for GODSP window there will be a list of all the users and groups that access the key.

i)	Select the Users group.

j)	In the Permissions box, locate the item Full Control and check the corresponding box under Allow.

k)	Repeat steps e through i for HKLM\Software\Texas Instruments.

2.	On Windows 2000 and XP allow users that will be using the Code Composer Studio product access via a "Power User" account.  Power users are automatically granted more privileges than a normal user.

3.	Give users full access to all files in the Code Composer program tree.

a)	Log in as Administrator.

b)	Open Windows Explorer and find the location of your install (usually c:\CCStudio_v3.1).

c)	Right click on the directory name in the Folders pane on the left.  Select the Properties menu option.

d)	You will see a set of tabs that contain settings for that folder.  Select the Security tab to see the privileges associated with the folder.

e)	Click on the Users group (or any other group you would like to change privileges for) to see the group specific privileges.

f)	Click on the Full Control box and hit Apply.  The new settings will be applied to all files and subdirectories of the Code Composer install directory.


Troubleshooting Error Messages
Error Messages

Error Message	Problem
Failed: Requires Win98, WinME, Win2k or WinXP.	Your Windows operating system does not support USB.
Failed: USB device is NOT enumerated or plugged in.	Windows cannot find the C6713 DSK in the list of  enumerated USB devices.  DSK may not be powered or the USB cable may not be plugged in.
Failed: Load Usb Application	Loader could not download the C6713 DSK emulation app to the DSK.  The on-chip emulation controller may be in a bad state.  Cycle power on the DSK.
Failed: USB channel in use by another app.	Another application is using the C6713 DSK USB communication channel.  Only one application is allowed to talk to the C6713 DSK over the USB channel.  You may have to check for active applications using Windows task manager if nothing seems apparent.
Waiting for USB Enumeration.	This is a status message which indicates that the C6713 DSK emulation application has been loaded.  The loader will maintain the message until the C6713 DSK re-enumerates. On Windows 2000/XP the "Waiting for USB Enumeration" will generally be active for less then 10 seconds.  On Windows 98/ME the enumeration process may take as long as 40 seconds.  Do NOT select the "OK" button unless you have let the specified time expire.  If you select the "OK" button while waiting enumeration the application will terminate and return control back to CCS which will probably fail and give the normal target error dialog.


LEDPRD Example

The ledprd example is a separate example that is performs the exact same function as the led example using the DSP/BIOS scheduler to run a periodic thread every 200ms instead of using the software delay loop.  Follow these instructions to load and run the ledprd example.

1)	Close any projects you were working with previously by selecting Project · Close.  You should also close any open files you have open in your workspace such to avoid confusion.  Click on the X in the upper right hand corner of their windows to close them.

2)	Open the ledprd.pjt Code Composer project using Project · Open and selecting ledprd.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bsl\ledprd.

3)	Load the ledprd.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the led.out file in the ledprd\Debug directory in the file browser and hit "Open" to load the executable file.

4)	Select the Debug · Run option under the Debug menu.  LED #0 will start blinking slowly.

5)	Move DIP switch #3 up and down, you will see LED #3 change with it.

6)	When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

To examine the program code, expand the Projects tree at the left of the workspace, then expand the ledprd.pjt and Source subitems.  Double click on ledprd.c to see its contents.

You can see that only initialization is done in the main() function.  When main() is finished, it returns back to the DSP/BIOS scheduler which takes over responsibility of finding more work to be done.  In this case, blinkLED0() is defined as a periodic thread that is scheduled to run every 200ms.  Advantages of this method are:

•	No time is wasted spinning in loops.  Work is done when it is scheduled or a resource that work depends on becomes available.

•	Independent work can be separated into logical threads that are managed by DSP/BIOS, simplifying your code.

  To view the scheduler settings:

1)	Expand the "DSP/BIOS Config" entry in the project view.  Double-click on the ledprd.cdb file to open it with the BIOS configuration tool.

2)	Expand the "Scheduling" entry in the configuration tool view.  This exposes groups of configurable parameters related to scheduling.

3)	Expand the PRD - Periodic Function Manager section to see a list of currently scheduled periodic threads.  There will be one scheduled entry called PRD_blinkLED0.  Right click on it and select Properties.

You should see something like this:

The function is the name of the thread containing the code to be run, in this case _blinkLED0.  The leading underscore is required because blinkLED0() is a C function.  Functions written in assembly do not need the underscore.  The period is the period blinkLED0() should be called with in ticks.  Each tick is equivalent to 1ms, so it will be run every 200ms.  Hit cancel to exit out of the properties view.

Adding a Second Thread

A second thread is included in the ledprd.c source file called blinkLED1().  It simply toggles LED #1.  This section shows how to add it as a second thread that blinks LED #1 at a different rate than LED #0.

1)	Expand the Scheduling entry in the DSP/BIOS Configuration Tool and right clock on PRD - Periodic Function Manager.  Select the Insert PRD menu option.  It will create a new scheduling entry called PRD0.

2)	Right click on PRD0 and select Properties.  Change the period field to 100 and the function field to _blinkLED1.  It will look like this when you are done:

3)	Hit OK to confirm the settings.  Single click on PRD0 and the Configuration Tool will let you change the name.  Change it to PRD_blinkLED1.

4)	Save the new DSP/BIOS configuration file.  Select File · Save.

5)	Re-compile your program.  Select Project · Build.

6)	Load the new led.out executable file.  Select File · Load Program then select ledprd.out in the ledprd\Debug directory in the file browser.

7)	Select the Debug · Run.  LED #0 will be blinking as before but LED #1 will also be blinking at twice the rate.

8)	When you are satisfied that both tasks are running, stop the program by selecting Debug · Halt.


DSP/BIOS Overview

DSP/BIOS is a real-time operating system developed by TI with features such as task scheduling and prioritization, inter-task communication and memory management.  It is small and modular so that any modules that are used can be compiled and linked into your application rather than a full blown operating system that exists completely separately from your code.  In many ways it is like a code library that happens to perform operating system type functions.

All of the examples that come with the DSK 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 Demo	A 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 File	A good starting point for DSP/BIOS users.  Contains a tutorial and To view
DSP/BIOS User’s Guide (SPRU423a)	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 Components

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

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 dsk_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
dsk_appcfg.h62 and dsk_appcfg.s62	Module specific variables for internal DSP/BIOS usage.
dsk_appcfg_c.c	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.
dsk_appcfg.h	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.
dsk_appcfg.cmd	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 rts6700.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 DSK.

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 DSK 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.  The led, ledprd and tone examples are essentially the dsk6713.cdb base seed with EMIF settings added for the SRAM and Flash/CPLD on the DSK and McBSP settings for the AIC23 codec.  The DSK_App and post examples contain more specific settings for things like DMA that are used by their programs.

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 DSK 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 DSK is first turned on, the DSP starts loading code based on the boot mode that has been selected.  When shipped from the factory, the POST is programmed into Flash and the jumpers are set to boot out of Flash.  The POST never stops running until Code Composer is started, although it is simply spinning in a loop and not doing anything visible.

When Code Composer is started, it halts the DSP through the JTAG interface and runs the StartUp() function in your .gel file (the default is DSK6713.gel).  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.


Device Driver Demos

The device driver demos encapsulate the codec data transfer using TI’s device driver model.  They perform audio-pass through using different BIOS primitives.  Device drivers hide details of the data transfer so DSP algorithm users and developers can focus more on the algorithm than getting the data transfer to work.  Once you understand the DSK_App example, the device driver demos are a good way to evaluate the differences between rolling your own code or using TI’s software infrastructure.

The demos only include relatively simple codec examples.  For full information about the drivers, more examples using the drivers and files you need to do development with the drivers, download the free Driver Developer’s Kit on the web from http://dspvillage.ti.com.


Running the Device Driver Demos

Follow these instructions to load and run the IOM demo.

1)	Close and projects you were working with previously by selecting Project · Close.  You should also close any open files you have open in your workspace avoid confusion.  Click on the X in the upper right hand corner of their windows to close them.

2)	Plug a pair of headphones or speakers into the DSK’s headphone jack.  Also connect an audio source like a CD player to the line input of the DSK using a standard 1/8" male to male audio cable.

3)	Open the tsk_echo67.pjt Code Composer project using Project · Open and selecting tsk_echo64.pjt.  It is in the directory c:\CCStudio_v3.1\examples\dsk6713\bios\audio.

4)	Load the tsk_echo67.out executable file.  Select File · Load Program.  It will open a file browser dialog.  Select the tsk_echo64.out file in the audio\Debug directory in the file browser and hit "Open" to load the executable file.

5)	Select the Debug · Run option under the Debug menu.  You will hear your audio source playing through the DSK on the headphone output.  Adjust the volume of your audio source until you get to a comfortable listening level.

6)	When you are satisfied that the program is indeed running correctly, stop the program by selecting Debug · Halt.

7)	Repeat steps 1-6 for the other demos, swi_echo67 and pip_echo67 in the same directory.


6713 Boot Process

When the 6713 comes out of reset, it copies 1Kbyte of data from the beginning of Flash memory (CE1, address 0x90000000) to the beginning of the 6713’s internal memory at address 0.  It then jumps to address 0 and starts execution.

Since applications are significantly larger than 1Kbyte, a Flash bootable program includes a boot code stub in the first 1Kbyte region that loads the application from Flash.  To make the process easier, the C6000 hex utility is capable of packing application code in an easy to parse bootloader table.

Making a Program Bootable

The POST is a good example of a bootable BIOS program, open the POST project to view the completed steps below:

1)	Create a memory section called BOOT using the BIOS configuration tool under System · Mem by right clicking on "MEM – Memory Section Manager" and selecting Insert MEM.  The section should start at address 0 with a length of 0x400.  If a memory section such as ISRAM already exists at address 0, you’ll need to move its start address to 0x400 and decrease its length by 0x400.

2)	Add the boot code that parses the boot table to your program using Project · Add Files to Project.  You can use the boot.asm that comes with the POST as a base for your own projects.  The boot code is stored in a section called .boot_load using the .sect directive at the top of boot.asm.

3)	The .boot_load section defined in step 2 is a logical section.  The BOOT section defined in step 1 is a real physical section.  The linker command file specifies which logical memory sections should be linked in each physical memory section.  Since the BIOS configuration tool only auto-generates a linker command file linking standard BIOS and C runtime sections, the auto-generated file postcfg.cmd will not include any references to the BOOT section you just created.  Create a separate linker command file such as userlinker.cmd in the POST project that places the .boot_load section in BOOT and then include the autogenerated linker command file postcfg.cmd to add the standard references.


Generating a Bootable Hex File

This section describes the steps necessary to convert the post.out file into the post.hex file needed by FlashBurn as an example you can apply to your own programs.  You do not have to perform these actions simply to put the POST in Flash if you have an existing hex file already.

A hex file contains binary data at the addresses you specify in a file format readable by the Flashburn utility and other Flash programmers.  The utility requires several flags to select the proper output format.  In this example, the flags are stored in the file post_hex.cmd which is a text file that can be edited to suit other purposes.  The key flags are:

Flag	Description
-a	Select ASCII hex file format for output
-memwidth 8	Generate output for an 8-bit wide Flash device
-bootorg 0x90000400	Address to place the boot table (base of Flash + 0x400)
-bootsection .boot_load 0x90000000	Place the .boot_load memory section at the beginning of Flash (address 0x90000000)

To convert the file Debug\post.out into the hex file post.hex using the flags stored in post_hex.cmd, open a DOS Command Prompt window and type the following:

cd c:\CCStudio_v3.1\examples\dsk6713\bsl\post

c:\CCStudio_v3.1\c6000\cgtools\bin\hex6x post_hex.cmd

The file post.hex is now ready for programming with FlashBurn.  For more details on the hex utility, please see the Code Composer help under Code Generation Tools · Hex Conversion Utility.


DSK Versions

There are two versions of the 6713 DSK:

Version History	Characteristic Features	Identifier
Version 1	8 Mb SDRAM	Board 1, CPLD 2
Version 2	16 Mb SDRAM	Board 2, CPLD 2

The only difference between the two DSK versions is the size of the SDRAM on the board.  Only one software change is required to make use of the 16 Mb SDRAM, that is that the SDRSZ (SDRAM row size) of the EMIF’s SDCTL register must be changed to 12 rows from 11 rows.

A version 2 board can be differentiated from a version 1 board in software by reading the CPLD VERSION register.  A board version of 2 represents a version 2 DSK.

The Board Support Library, GEL file, POST and Diagnostic Utility that ships with the version 2 DSK have all been modified to automatically check the board version and set the SDRSZ field correctly regardless of whether a version 1 or version 2 DSK is being used.  Running version 1 software on a version 2 board, however, will result in a SDRAM failure because the SDRSZ field will not be set up correctly.