Site Index
   Home
   File Upload
Google

Transfer Site
Main Site

DSK5416/5510 FAQ

This FAQ applies to DSK development kits manufactured by Spectrum Digital. At the current time, this includes the:

  • 5416 DSK
  • 5510 DSK

Section 1: Installation

Section 2: Board Usage

Section 3: DSK5510 Specific Issues

Section 4: DSK5416 Specific Issues


Section 1: Installation

1.1 Problems when using Xilinx tools
There is a known issue with systems running both Xilinx ISE tools version 5.1 and earlier. During the Xilinx tools installation the defaults install device drivers for the Xilinx Multilinx USB JTAG cable even if you are not using it (most customers use the parallel port version). The Xilinx device drivers will filter out commands to the on-board USB port on the Spectrum Digital DSKs and Windows will never recognize the board. This issue was officially resolved in release 5.2 of the Xilinx tools.

The workaround is to remove the Xilinx USB device drivers and reinstall the Xilinx tools without Multilinx USB drivers.

  1. Uninstall the Xilinx tools.
  2. Go to the windows/system32/drivers directory and remove mlnxfltr.sys and mltilnx.sys.
  3. Unplug your DSK.
  4. Go to your Windows device manager (from the Control Panel) and delete any USB hubs.
  5. Reboot your PC, Windows will restore support for the hubs.
  6. Plug both the USB and power cables back into the DSK. The Add New Hardware wizard should pop up and ask for the location of the drivers. Put the DSK software installation CD-ROM back in the CD-ROM driver and let Windows automatically search for the drivers.
  7. At this point the DSK should be recognized by Windows (you should be able to go to the device manager and see something like "SD Based USB Debug Tools".
  8. Re-install the Xilinx tools making sure NOT to install and Xilinx USB Multilinx drivers.

This issue is described on the Xilinx support site at: Xilinx Support

1.2 Diagnostic utility won't run if installed in a path with spaces
Versions of the diagnostic utility prior to 1.10 have a bug that prevent the utility from properly locating the embedded emulator driver files if the DSK version of Code Composer was installed in a directory with spaces in its pathname. For example, if Code Composer is installed in:

    C:\Program Files\ti

the diagnostic utility will pop up an error in a dialog box that reads (the error message will be slightly different based on which DSK you are using):

    Can't load driver Files\ti\drivers\5510DSKDiag.exe

You can either re-install the software in a different location without spaces in the path (like c:\ti) or just copy the ti\drivers directory to a new path without spaces and run the diagnostic utility manually from there.

1.3 Which external emulator/Code Composer versions can be used together?
DSKs come bundled with a special version of Code Composer that only works with the on-board JTAG emulator. Some rules of thumb are:

  1. The full version of Code Composer can make use of either the on-board JTAG emulator or an external emulator. The DSK version of Code Composer will only work with the on-board JTAG emulator.
  2. You cannot use the on-board emulator to debug a non-DSK target.
  3. An external JTAG emulator will only work with the full version of Code Composer.

If you are designing your own hardware you will need the full version of Code Composer as well as an external JTAG emulator. Spectrum Digital offers its XDS510 USB JTAG Emulator as a direct replacement for DSK users looking to upgrade to an external emulator, other emulators are available from Texas Instruments and other vendors.

1.4 How do I use a DSK with the Reference Frameworks or DDK?
The original DSK releases do not correspond directly with Code Composer versions such as 2.20 or 2.21. TI software releases such as the Reference Frameworks or DDK are generally targeted with users of the full version of Code Composer in mind and therefore ship with code that matches BIOS versions that ship with the full versions.

Both the Reference Frameworks and can be re-built on DSK versions of Composer using a script provided at the base of the RF or DDK install trees. This script will rebuild all of the BIOS configuration (.cdb) files in the examples using the version of Code Composer you are using. Instructions on how to run the scripts are provided in the RF and DDK release notes. For example, the RF release notes from dspvillage.ti.com can be found here:

https://www-a.ti.com/downloads/sds_support/rf_v2_20_00/relnotes_rf_v2_20_00_08.html


Section 2: Board Usage

2.1 Daughtercard Access
The convention when using TI daughtercards is to have the daughtercard pull down the DC_DETECT pin (pin 75 on the peripheral expansion connector). On the 5510 DSK, pulling this pin low will enable the power supply and data buffers to the daughtercard connectors.

The X_RESET pin (pin 59 on the peripheral expansion connector) is used as a daughtercard reset. When power is applied to the DSK the X_RESET will be held low until the power supplies are stable then driven high by the CPLD. For most daughtercards this provides the desired reset behavior. However, you can reset the daughtercard again in software by toggling the DC_RESET bit in the CPLD register. See the 5510 DSK help file for more information about the CPLD registers.

2.2 Can the DSP access the USB port directly?
The USB port is only connected to the on-board USB JTAG emulator on the DSK. Other than the JTAG signals needed for emulation, there are no communications signals from the USB emulation section to the DSP. There is no way for the DSP to communicate through the USB interface other than through the JTAG emulator.

2.3 Optional Power Connector(J6) part number correction.
The part number for teh Optional Power Connector(J6) in the DSK Technical Reference has been updated. The incorrect part number printed in the reference previously is Molex #15-24-4041. The correct part number is:

    Molex  #53109-0410
-or-
    Tyco Electronics  #174552-1

Section 3: DSK5510 Specific Issues

3.1 Stack modes
A C55x DSP can use one of three stack modes:

  • Dual 16-bit with fast return
  • Dual 16-bit with slow return
  • 32-bit with slow return

The stack mode is determined by bits 28 and 29 of the 32-bit word at the reset vector. The default stack mode is 32-bit with slow return. You can view the current mode by pointing a disassembly window at the reset vector. For more information about stack modes, see the Stack Operation section of the TMS320C55x DSP CPU Reference Guide (SPRU371) and the Memory Management Issues section of the TMS320C55x DSP Programmer's Guide (SPRU376).

One constraint of the 32-bit with slow return stack mode is that the data stack and system stack change in a synchronized manner. This implies that both stacks must be the same size. Other stack modes do not have this restriction.

To change the stack mode you need to:

  1. Move the reset vector to a modifyable location. The reset vector points to 0xFFFF00 in the internal ROM when the DSP comes out of reset which cannot be changed. Most programs will move the interrupt vectors to internal RAM.
  2. Change the 32-bit word at the reset vector to reflect the stack mode. For the change to take place, a hardware or software reset must occur. DSP/BIOS programs can set the stack mode in Scheduling --> HWI pane of the DSP/BIOS GUI configuration.

DSP/BIOS has been designed to work in of all three-stack modes.

3.2 Memory model constraints
The C55x processor has two memory models - large and small. In both models code can exist anywhere in the address space of the DSP.

In the large memory model data can be placed anywhere in the address space. However, data objects cannot cross 64Kword boundaries because the C compiler implements data pointer arithmetic that will wrap around at the lower 16-bits when these boundaries are crossed. The linker will enforce a restriction that DSP/BIOS sections must not cross 64Kword boundaries.

In the small memory model all data is limited to a single 64Kword page. Since the DSP's memory mapped registers are located starting at address 0 and most programs access these registers through their own code, DSP/BIOS or the CSL, almost all small model programs should place their data in the first page of the DSP's memory.

The default memory map provided in dsk5510.cdb has memory sections arranged in such a manner that they don't span across a page boundary.

3.3 Register usage
See Appendix B of the TMS320C5000 DSP/BIOS Application Programming Interface (API) Reference Guide (SPRU404) for detailed information about the register usage model and DSP/BIOS.

3.4 Performance optimizations
Placement of code and data im memory can affect performance greatly. More information about memory placement issues can be found in the Memory Mangement section of the TMS320C55x DSP Programmer's Guide (SPRU376).

3.5 CPU revisions
The 5510 DSK ships with revision 2.2 of the silicon. For proper code generation, the CPU revision must be specified correctly. DSP/BIOS programs reflect the revision level in the DSP/BIOS configuration under the System --> Global Settings pane.

CSL programs require that a preprocessor define be set to match the processor revision. CSL programs should define CHIP_5510PG2_2 in the preprocessor section of the program's build options. DSP/BIOS programs that use the CSL make this definition automatically so extra effort is needed.

3.6 External memory considerations
External memory references have a much higher latency than internal memory (10-20 cycles vs. 1 cycle). When moving code from internal memory to external memory performace can degrade real-time constraints may no longer be met.

When partitioning code and data between internal and external memory, the following priorities should be assigned (in this order):

  1. Frequently used code should be in internal memory. Every instruction must be fetched from its location in memory so if code is in external memory the additional latency will felt with every instruction.
  2. Stacks should be in internal memory. Stacks are typically small and heavily used (especially in interrupt handlers) so placing them in internal memory provides a good cost/benefit tradeoff.
  3. Frequently used data should be in internal memory.

Infrequently used code and data can be placed in external memory with the least imact on performance.

The 5510 has in internal instruction cache which is disabled by default. It helps to minimize the imact of placing code in external memory. The cache can be enabled through the Chip Support Library. See the DSP/BIOS API Guide (SPRU404) for more information on cache usage and its usage effect on task contexts.

When trying to run code out of SDRAM from Code Composer, remember that SDRAM loses its contents unless it is constantly refreshed by the EMIF. In end products, boot code normally sets the EMIF up and then copies application code into SDRAM before it starts the code running. Code Composer is a debug environment environment where an application is loaded through the JTAG interface. When debugging code running out of external memory with Code Composer, set the EMIF up in the GEL file before loading your code or the code will fail. The c5510_dsk.gel file that ships with the DSK performs this initialization.

The 5510 DSK uses a 25/3 PLL multiplier to get 200MHz operation. If you change the PLL to another frequency, you must adjust the SDRAM refresh interval to match the new freqency. This change wherever you set up the EMIF (the GEL file or the application code). See the online help for the 5510 DSK (TMS320VC5510DSK --> Hardware --> On-Board External Memory) for further details.

3.7 DMA considerations
Each C55x DMA channel has a setting that indicates which internal bus should be used to access the source and destination data. A different setting is used for either the internal DARAM, internal SARAM, EMIF or I/O registers. When you move data from one type of memory to another you must update the DMA settings to reflect the bus it sits on.

If you take the BIOS audio example and try to move it to external memory the application will not work because its DMA is set up transfer data from buffers in internal DARAM. The DMA settings can be changed in the CSL configuration under the Transfer Source and Destination fields for each channel.

3.8 DMA1 example/DMA transfers to SARAM or EMIF
Many users use the DMA1 example to experiment with DMA transfers to SARAM or the EMIF. DMA1 does DARAM to DARAM transfers. In general, doing transfers outside of DARAM is just a matter of changing the source/destination bus settings in the DMA configuration.

Each DMA channel's 32-bit DMA source and destination address is split between two 16-bit physical registers (upper and lower). Between Code Composer 2.12 and 2.20, the convention used to store 32-bit addresses in the DMA_Config CSL structure and its interpretation by the DMA_config() function call changed. One version expects the 16 low bits of the address to be stored in the low field, and 16 high bits to be stored in the high field. The other version expects the full 32-bit address to be stored in the low field which gets split up into a high and low address by DMA_config().

In 5510 DSK version of Code Composer (a version between 2.12 and 2.20) the code generated by the CDB files (in appnamecfg_c.c) doesn't match what DMA_config() expects. The CDB generated code only puts the lower 16 address bits in the lower source and destination registers. When DMA_config() executes, it takes the upper 16 bits of the lower address field of the config structure (which is always 0) and puts it into the upper address register. So even if you specify a large address in the BIOS config, the actual address put into the register will always point to a value in the first 64Kwords which on the 5510 is all DARAM.

To fix any problems, overwrite the addresses set by DMA_config() with your own code:

    /* Address is in 8-bit bytes, not 16-bit words */
    addr = (Uint32)buffer << 1;
    DMA_RSETH(myhDma, DMACDSAL, addr & 0xffff));
    DMA_RSETH(myhDma, DMACDSAU, (addr >> 16));

The dsk_app example in examples\dsk5510\bsl does this already so it can be used as a working test case.


Section 4: DSK5416 Specific Issues

4.1 Left/right audio channels get swapped after a debug event
Audio data is transferred between the DSP and the PCM3002 codec serially through a McBSP. When a debug event (a breakpoint, functions in your GEL file) occcurs, Code Composer will temporarily halt the DSP through the JTAG emulation connection to execute the operation. Since the codec is clocked externally to the DSP, it continues running while the DSP is halted. When the DSP is released, execution will continue but the DSP is likely to be out of sync relative to the codec. This typically exhibits itself as a swapping of the left and right audio channels and is expected behavior.

There is no workaround to automatically keep the left and right channels consistent during DSP halts on a 5416 DSK. This is because the PCM3002 stereo audio samples are always packed as a pair of 32-bit words (64-bits total). Since the largest atomic McBSP data element transfer is 32-bits, you cannot read both left and right samples in a single operation. The left and right samples will always appear to be independent.

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