Index

MityDSP Frequently Asked Questions (FAQ)



Last Updated May 15, 2008
MityDSP FAQ Summary


1.0 Introduction
2.0 Software Development
   2.1 Why does it take the DSP so long to respond to an interrupt?
   2.2 I'm only writing 160 bytes to FLASH, why does it take so long?
   2.3 Why don't I see my serial port characters when I'm debugging?
   2.4 I seem to be missing/losing tick timers, why?
   2.5 What's the deal with the long keyword anyway?
   2.6 How do I use TI's Chip Support Library (CSL) with the MityDSP-Pro?
   2.7 I just updated to TI's Code Generation Tools v6.1.2, and now I get errors with DSP/BIOS header files when I compile my project... what's up?
3.0 FPGA/Firmware Development
4.0 Hardware
   4.1 The TI6711 can be clocked at 200MHz, but the MityDSP runs at 100MHz by default. Can I increase the DSP clock speed for my application?
5.0 Support Tools
   5.1 Why do I care about the Application Data Space in the FLASH settings of the Bootloader?
6.0 Network
   6.1 My program dies after a while of heavy network traffic? Am I losing buffers?
   6.2 Why can't I use the tsDSPNetStackInit structure to tune lwIP parameters anymore?
   6.3 I just updated to the latest MDK, and my previous network code does not compile anymore, what gives?
   6.4 How about a quick "porting guide" that summarizes the changes I need to make to use the new network libraries?
7.0 Other
   7.1 Why isn't the latest MDK available for download for my application?


1.0 Introduction

The purpose of this document is to capture common frequently asked questions (FAQs) that we at Critical Link, LLC receive regarding the development systems employing the MityDSP. The goal is to provide additional resources to other customers who may have similar questions.

Back to Top

2.0 Software Development

This section is intended to answer FAQs commonly raised by MityDSP software development engineers.

Back to Top

2.1 Why does it take the DSP so long to respond to an interrupt?

From the Code Composer Studio (CCS) Help pages regarding the Interrupt Flexibility Options (-mi Option):

On the C6000 architecture, interrupts cannot be taken in the delay slots of a branch. In some instances the compiler can generate code that cannot be interrupted for a potentially large number of cycles.

What this means is that it is possible for the TI compiler to generate code that can cause the CPU to not respond to an interrupt for quite some time. Note that the CPU will always detect the interrupt condition, but simply not call the related ISR until it is out of the code block in question.

In general this situation only occurs in optimized code, and only in sections of code that utilize tight for-loop conditions, such as:

for (i = 0; i < 100000; i++)
{ 
   a[i] = b[i]; 
}

By using the -mi option (e.g., -mi2000) in the Build Options for your project, you can instruct the compiler to force gauranteed window of interrupt handling opportunity every N CPU instructions. This is necessary if you have ISRs that require low latency (say, a high speed ADC FIFO drain routine or an ethernet driver). All MityDSP libraries provided by CL employ a -mi setting of 10000 or less. By default, the compiler will assume no restrictions on interrupt latency requirements.

As of CCS version 3.1, the TI provided realtime common libraries (the rts6700.lib, containing functions like memcpy) and the downloadable DSP libraries (containing floating point FFT algorithms) are compiled with the -mi flag disabled. Therefore, a user will be required to rebuild the runtime libraries with the flag set in order to ensure low latency interrupts are achieved.

Our experience has been that many problems relating to lost tick-timer clocks, network hick-ups, ADC capture FIFO overflows, parser errors (due to bad message data), and any other long interrupt latency problems have ultimately be tied back to this issue. Further information can be found by researching the -mu and -mi options on the CCS compiler.

This is a new procedure, beginning with version 6.1 of TI's Code Generation Tools:

  1. The new TI libraries require recent versions of perl, gmake, and unzip. These can be downloaded and compiled individually, but it is easiest to download and install a copy of "cygwin", a linux-like environment that can be run under Windows. Go to www.cygwin.com and select the "install cygwin now" link. This will download a setup program. Just run the setup program and follow the instructions. The default set of installed programs does not include "unzip" (gunzip will not work with *.zip files) or the compiler required.

    To add unzip, run (or rerun) the cygwin setup program. When you get to the "Select Packages" screen, make sure the view is set to "Categories". Expand the "Archive" category and scroll down until the unzip package is found. By default, the "New" column will show "Skip". Click on this once to change "Skip" to the current version (5.52-2 at the time of this writing). Do the same for the "make" and "gcc" packages, under the "Devel" tree. Press the "Next" button to continue the installation.
     
  2. Open a cygwin "bash" window. This will be familiar to linux users. It is very similar to a command window in DOS.
     
  3. Navigate to the directory where the latest Code Generation Tools were installed. The "cd" command is used in cygwin, but to get to a given drive, you use the path /cygdrive/C (to get to the C: drive). Directory separators are "/" not backslash, which is used to escape special characters, such as spaces.

    So if the tools were installed in the Windows directory:
       C:\Program Files\C6000Code Generation Tools 6.1.2

    You get there in cygwin using:
       cd /cygdrive/C/Program\ Files/C6000Code\ Generation\ Tools\ 6.1.2
     
  4. Next add the compiler, linker, etc. to the search path by issuing the following commands:
       cd bin
       PATH=$PWD:$PATH

     
  5. Go to the lib directory and unzip the run-time library source code:
       cd ../lib
       unzip rtssrc.zip

     
  6. Edit the Makefile to add the appropriate -mi option. This can be done in any text editor (vi, if you're comfortable in the *nix environment), but notepad can also be used by issuing the following commands:
       unix2dos Makefile
       notepad Makefile


    Regardless of the text editor, add "-mi10000" (or whatever argument to -mi your project requires) to the OPT_ALL line. Also, change all occurences of "gmake" to "make" within the Makefile. The "make" included in cygwin is gmake, but has been renamed.
     
  7. Save the original copies of the libraries, just in case something goes wrong. For the MityDSP:
       mv rts6700.lib rts6700_orig.lib
       mv fastmath67x.lib fastmath67x_orig.lib


    For the MityDSP-Pro:
       mv rts64plus.lib rts64plus_orig.lib
     
  8. Rebuild the appropriate libraries. For the MityDSP:
       make rts6700.lib
       make fastmath67x.lib


    For the MityDSP-Pro:
       make rts64plus.lib
     

This is the procedure prior to version 6.1 of TI's Code Generation Tools:

  1. Initially, the code generation tools are installed in a cgtools directory within your CCS installation (e.g., "C:\CCStudio_v3.3\cgtools"). However, their default location for subsequent CGTOOLS downloads from TI is "C:\Program Files\C6000 Code Generation Tools x.x.x", where x.x.x is the current CGTOOLS version. Locate the proper directory for your installation. The rest of these istructions refer to the directory as $(Cgtools_dir).
  2. Start a CMD prompt.
  3. Do the following to rebuild your RTS library:
  4. Rebuild your code.

If your project needs different settings for the -mi flag, you may change the argument to the "-mi" flag supplied above.

NOTE: For the MityDSP-Pro, the procedure is the same, except the library name is "rts64plus.lib". In addition, the argument to the -mv flag in the mk6x command changes from 6700 to 6400+.

For version 3.1 of Code Composer Studio, we have discovered that the rts.src supplied by the CCS install disks from TI are corrupt. TI will provide an update for this code if you request it, or if you download the latest CGTOOLS patch (from the CCS Update Advisor) the rts.src file should be correct.

Back to Top

2.2 I'm only writing 160 bytes to FLASH, why does it take so long?

Keep in mind that the if you are using the tcDspFlash::write() method, the following operations take place:

  1. Data that is included from the FLASH sector(s) that the write request spans but is not part of the actual write request is loaded from FLASH to a local memory buffer. This is done in order to preserve the data following the next set of operations.
  2. The sector(s) that the write request spans are then erased.
  3. The sector(s) that the write request spans are rewritten.

So regardless of how small a write you are performing, if you are writing to a sector that is 16 KBytes big, you are effectively reading 16 KBytes, erasing 16 KBytes, then reprogramming 16 KBytes of data. The FLASH memory interface is slow, and such an operation may take hundreds of milliseconds to complete.

Users that wish to avoid such long intervals, or anticipate frequent FLASH update cycles should consider using the tcDspFlash::rawWrite() method. This method does not perform a forced erase on a sector, but rather simply writes the requested bytes to the locations in FLASH and returns, a fairly quick operation. However, the data in FLASH must be all 0xF's for this technique to work.

Typically, a user writing small chunks of data will erase a sector in FLASH, then write a small structure out in memory and "walk" up in the sector (writing to a different location within the same FLASH) until it hits the top of the sector, then re-erase the sector and start over. This requires a bit more management in the application but yeilds much longer FLASH life (which is specified at 100,000 cycles for the MityDSP) as well as much faster FLASH update cycles.

Another option is to use the tcDspStorageCache class to cache FLASH writes. See the documentation provided in the Core Library for details.

Back to Top

2.3 Why don't I see my serial port characters when I'm debugging?

Oftentimes when using the TI emulator/debugger to walk line-by-line through software a user will issue a tcDspSerial::put() command, then be surprised to see that no data is displayed on the attached serial device. This is due to the underlying UART design and the way that the Spectrum Digital Emulator works with the TI CCS debugging suite.

The MityDSP UART core consists of an FPGA based UART containing a 64 byte transmit and 64 byte receive buffer. The FPGA issues two interrupts, one indicating receive data is available and one indicating that the transmit FIFO is empty. The DSP tcDspSerial class also provides transmit and receive buffers (4K and 32K bytes, respectively), and installs an interrupt handler that moves data between these buffers and the FPGA FIFOs based on the received FPGA interrupts.

When a tcDspSerial::put() command is issued, data is transferred from the user supplied buffer to the DSP transmit buffer, and if necessary the transmit FIFO empty interrupt is then enabled and the function returns. Because of the high priority of the TI emulator, quite often the TX interrupt ISR is not called prior to the next effective breakpoint inserted by the emulator while line-by-line debugging is being performed. If no data is sent to the FPGA, then no data is transmitted by the UART. Note also than only 64 bytes will be transferred before another ISR call will be required.

Back to Top

2.4 I seem to be missing/losing tick timers, why?

By default, the system tick timer ISR in a normal MityDSP BIOS enabled program runs at the lowest interrupt priority. The tick timer works by generating a counter based interrupt once a millisecond (by default). The BIOS inserted ISR handles the interrupt and bumps a system counter used by CLK_getltime() and the other timer driven functions (TSK_delay(), etc.). Often during debugging or runtime users have observed that the tick-timer runs "slow". This is due to the fact that the tick timer ISR is not able to run fast enough to keep up with the timer generated interrupts. Reasons for this behaviour include:

Back to Top

2.5 What's the deal with the long keyword anyway?

For the TI 6000 series processors, CCS interprets the long keyword as a 40 bit (5 byte) integer. This isn't necessarily a problem, and in some cases users may require the additional integer dynamic range that the processor supports. However, this subtlety can create issues if you are:

Back to Top

2.6 How do I use TI's Chip Support Library (CSL) with the MityDSP-Pro?

The Chip Support Library for the 645x processor found on the MityDSP is not included in the CCS3.3 standard installation. Here are the steps to obtain it, and rebuild the libraries for use with the MityDSP-Pro:

  1. Download the latest copy of SPRC234.zip from the TI website.
  2. Open the zip file and navigate down until you find a directory named "6455". In this folder you will find another zip file named 6455_default_package.zip. Extract the contents of this folder to your C:\CCStudio_v3.3 directory (or wherever you've installed code composer).
  3. Rename the just-copied "default package" folder to "C6455".
  4. In this C6455 folder, go into a sub-folder named csl_c6455_src. Edit the file "Makefile.inc" and add the option "-mi10000" to the lines starting with release_CC_OPTS and release_ASM_OPTS. This will build the CSL with the same interrupt threshold as the default MityDSP libraries.
  5. Add the CSL3X_ROOT_DIR environment variable to your system. To do this, right click on "My Computer" and choose "Properties". On the "Advanced" tab, select "Environment Variables". Create a new variable, name it "CSL3X_ROOT_DIR" and set it to C:\CCStudio_v3.3\C6455 (or wherever your Code Composer installation directory is).
  6. Open a command window and go to your top level CCS install directory (C:\CCStudio_v3.3) and execute "DosRun.bat"
  7. In the same command window, goto the subdirectory "C6455\csl_c6455_src" and enter "set path=C:\CCStudio_v3.3\C6455\csl_c6455_src;%path%"
  8. Run the batch files "build_c6455.bat" and "build_c6454.bat" to rebuild the CSL libraries (again within the same command window opened above).
  9. Copy the resulting "csl_c6454.lib" and "csl_c6455.lib" files over to "..\csl_c6455\lib\csl_c6454.lib" and "..\csl_c6455\lib\csl_c6455.lib".
  10. For any MityDSP-Pro projects using the CSL, you'll need to add the Include Search Path "$(Install_dir)\C6455\csl_c6455\inc" to your project Compiler Options. To the Linker Options, add the Library Search Path "$(Install_dir)\C6455\csl_c6455\lib" and the library "csl_c6454.lib" or "csl_6455.lib".

If you're using DSP/BIOS in your project, that's it. However, if you need to use the INTC module from the CSL (never use this with DSP/BIOS), there are a few more steps...

  1. Go back to the C6455 folder and enter another folder named csl_c64xplus_intc_src. Edit the file "Makefile.inc" and add the option "-mi10000" to the lines starting with release_CC_OPTS and release_ASM_OPTS.
  2. In the command window, also goto this subdirectory (should be "..\csl_c64xplus_intc_src" if starting from the last set of instructions) and enter "set path=C:\CCStudio_v3.3\C6455\csl_c64xplus_intc_src;%path%"
  3. Run the batch file "build_c64xplus_intc.bat" to rebuild the INTC module of the CSL library.
  4. For convenience, copy the resulting "csl_c64xplus_intc.lib" over to "..\csl_c6455\lib\csl_c64xplus_intc.lib" so it's on the same library search path as the rest of the CSL libraries.
  5. For any MityDSP-Pro projects using the INTC module of the CSL, you'll need to add the Include Search Path "$(Install_dir)/C6455/csl_c64xplus_intc/inc" to your project Compiler Options. To the Linker Options, add the Library Search Path "$(Install_dir)\C6455\csl_c6455\lib" and the library "csl_c64xplus_intc.lib".

If your project needs different settings for the -mi flag, you may change the argument to the "-mi" flag supplied above. Also, don't forget to update the rts64plus.lib file i while you're at it... see 2.1 Why does it take the DSP so long to respond to an interrupt?.

Back to Top

2.7 I just updated to TI's Code Generation Tools v6.1.2, and now I get errors with DSP/BIOS header files when I compile my project... what's up?

When TI moved from v6.0 of their Code Generation Tools to v6.1, there were some significant changes to the run-time libraries and C/C++ header files. While the changes added some new functionality, there was also at least one piece of "questionable" code introduced. In the errno.h header file the following is now present:

extern _DATA_ACCESS int errno;
#ifdef __cplusplus
  #define errno ::std::errno
#else
  #define errno errno
#endif

Therefore, everywhere the word "errno" appears in C++ code, the preprocessor will change it to "::std::errno". This means that if your application has a structure or class member named "errno", or even an enumeration, macro, or method named "errno", the above substitution will be made and your code will likely not compile. To fix this, either rename the item in your code, or make sure errno.h is not included in the file.

What's worse, TI actually caught themselves in this trap. Several of their DSP/BIOS header files (tsk.h, sem.h, etc.) have data structures with members named "errno". If you get compilation errors that point to these DSP/BIOS headers, the only thing you can do is to move the inclusion of the DSP/BIOS headers to a point prior to the includion of errno.h.

NOTE: Few of the MityDSP MDK header files include errno.h. One notable exception is DspNetStack.h. Therefore, DSP/BIOS includes must be made prior to DspNetStack.h as well.

Back to Top

3.0 FPGA/Firmware Development

This section is intended to answer FAQs commonly raised by MityDSP FPGA firmware (VHDL) development engineers.

Back to Top

4.0 Hardware

This section is intended to answer FAQs concerning the MityDSP card and / or common hardware interfaces and cores provided by Critical Link.

Back to Top

4.1 The TI6711 can be clocked at 200MHz, but the MityDSP runs at 100MHz by default. Can I increase the DSP clock speed for my application?

NOTE: This applies to the MityDSP and MityDSP-XM only.

Yes, in general the clock speed of the DSP may be increased. Usually the only penalty is power consumption and heat generated. A macro has been provided to support changing both the CPU clock speed and the external memory interface (EMIF) clock speed. Please note, though, that changing the EMIF speed requires that FPGA builds (which are primarily clocked using the EMIF clock) be made with appropriate timing constraints. Arbitrarily adjusting the EMIF is not recommended unless you know what you're doing. The nominal/recommended EMIF speed is 50 MHz.

The example below shows how you would configure the DSP to run at 200 MHz, with the EMIF running at 50 MHz. This is normally the option users pick if extra CPU cycles are required.

    #include 
    
    int main(int argc, char* argv[])
    {
       RECONFIG_CLOCKS(CPU_FREQ_200MHZ,EMIF_FREQ_50MHZ)
       
       ... rest of code here....
    }

Note that you will also have to change the clock speed in your DSP/BIOS configuration file (*.cdb file) so that all operating system timers operate at the proper rate.

Back to Top

5.0 Support Tools

This section is intended to answer FAQs concerning MityDSP support software developed by Critical Link.

Back to Top

5.1 Why do I care about the Application Data Space in the FLASH settings of the Bootloader?

The MityDSP bootloader architecture is designed in such a way as to provide a certain level of abstraction of the FLASH memory devices from an application developer. In general, a software developer needing to interface to the FLASH to store non-volatile application data should not write code that hardcodes FLASH sector configuration (starting addresses, blocksizes, etc.) or attempts to directly interface to the FLASH part. Instead, the tcDspFlash class should be used. There are several reasons governing this guidance:

The Bootloader GUI tool provides a user with control over the allocation of the FLASH application code and data regions for a MityDSP. See the help page in the GUI tool for more information. Typically, the top sector(s) of the FLASH are reserved for application data.

Once the MityDSP application code and data space has been stored by the Bootloader, software developers can locate the application data area in FLASH, determine it's size and offset without any knowledge of the topology of the FLASH part. This allows for portable code between the various MityDSP platforms. As an example, the following code locates the application sector area for the MityDSP and performs a write call:

{
     // This section of code is required, per tcDspFlash documentation
#ifdef MITYDSP_PRO
     const unsigned int FLASH_BASE_ADDR = 0xB0000000;
     const unsigned int BANK_SEL_ADDR   = 0xA0000004;
#else
     const unsigned int FLASH_BASE_ADDR = 0x90000000;
     const unsigned int BANK_SEL_ADDR   = 0xB0000004;
#endif
     char* myAppBuff = new char[1024];

     // Initialize the tcDspBankSelector object for the flash device
     tcDspBankSelect* mpBankSel = new tcDspBankSelect((void*)BANK_SEL_ADDR);

     // Use the factory to obtain a base class pointer to the flash device
     tcDspFlash* mpFlash = new tcDspFlash((void *)FLASH_BASE_ADDR, mpBankSel);
     
     // Read the base configuration of the MityDSP (Bootloader GUI settings)
     tcDspConfig *myConfig = tcDspConfig::GetInstance(myFlash);
     
     // Get the location of the application data area
     unsigned int AppFlashOffset = myConfig->GetAppDataOffset();
     unsigned int AppFlashSize   = myConfig->GetAppDataSize();
     
     // Do checks if AppFlashSize is too small...
     
     // Write to the application data area
     mpFlash->write(AppFlashOffset, myAppBuff, 1024);
}
Back to Top

6.0 Network

This section is intended to answer FAQs related to Network processing.

Back to Top

6.1 My program dies after a while of heavy network traffic? Am I losing buffers?

With heavy CPU usage, processing of network packets can be delayed. It was found that LWIP's internal mailbox length was set to 50. Once the mailbox is full, messages are simply dropped, and the buffer will not be released. This was seen on PBUFs, but may effect other buffer types.

You can verify that the mailbox is dropping items by checking the MboxPostDrops field of the SysArchStats structure. This should always remain at zero.

Back to Top

6.2 Why can't I use the tsDSPNetStackInit structure to tune lwIP parameters anymore?

While the previous tuning parameters were convenient, they were creating a significant code maintenance issue in the MDK. The lwIP stack used in the MDK is an independent, open source project. The changes to allow run-time adjustment of internal stack parameters were essentially custom changes applied by Critical Link to the lwIP baseline. Every time the lwIP project changed a file, these custom changes would have to be re-examined and possibly re-applied.

So rather than "fight city hall", starting with MDK 2.1, lwIP was broken out into a separate library, which consists of the open source lwIP project, and the few architecture files that are needed to define certain functionality specific to the MityDSP. All internal parameters are set at compile time, via the lwipopts.h file.

In most instances, the library provided with the MDK can be used as-is. Should your project have specific requirements not addressed by the default configuration, the complete source code for lwIP (and the project file to build it) is now provided with all MDK distributions. To tune lwIP for your application (if needed), simply open the lwip.prj file in Code Composer, change lwipopts.h as required for your project, and rebuild the libraries (debug and release versions).

Back to Top

6.3 I just updated to the latest MDK, and my previous network code does not compile anymore, what gives?

As discussed in the previous question, starting with MDK 2.1, the MityDSP network libraries were reorganized. The lwIP code now sits in its own library, and the network drivers, interface layer, and various network utilities not part of lwIP are now in the Net library. The previous Clients, Telnetd, Httpd, and WINS libraries are all now part of the Net library.

This requires some changes to the include paths used in your project, the libraries linked, and a slight modification to the stack initialization code. This is all described in the documentation for the Net and lwIP libraries provided in the MDK.

Other than these path name changes, there are no changes to the API's, so no changes to the logic in your application should be required, with one minor exception. The lwIP project now includes a DHCP client, so the DSPNetDHCP and DSPNetDHCPIsBound functions no longer exist. Simply use dhcp_start() and netif_is_up() from the lwIP library in their place.

Back to Top

6.4 How about a quick "porting guide" that summarizes the changes I need to make to use the new network libraries?

FAQ 6.3 discussed the changes to the various MityDSP Network libraries starting with MDK 2.1. Here is a quick summary of the code changes required to update legacy code. Please refer to the full documentation for complete details.

Back to Top

7.0 Other

This section is intended to answer FAQs that cannot be categorized in sections 1.0 through 5.0.

Back to Top

7.1 Why isn't the latest MDK available for download for my application?

New MityDSP MDK's are released periodically to add features or correct problems found in previous releases. Each MDK strives to be 100% backward compatible with previous releases at an API level. However, underlying implementation details, and the internal interfaces between software and firmware objects is subject to change from release to release. This means that firmware files produced with one revision of the MDK may not be mixed and matched with software built against another release in all cases.

Therefore, all application-specific firmware and software must be built against the same MDK. Since Critical Link supplies the application firmware for many customers, even those who develop their own software, coordination of new application firmware and software builds is required between Critical Link and the customer. An update in turn requires a regression test of the application firmware on a customer's specific I/O board.

Unless your application requires new functionality, or is experiencing problems with an existing MDK, no upgrade is necessary or recommended. If you think you require an upgrade, please contact Critical Link and we'll verify whether or not the latest MDK will address your issue and assist with the upgrade process.

Back to Top


  
Copyright © 2005-2007, Critical Link LLC, All rights reserved.