Custom Firmware, Electronics Design, and PCB Layout

> Lab Book

TMS320C6722 Tutorial and Hard Learned Lessons

Daycounter has started working with the C6722 series of DSPs from TI.  The learning curve with the tools has been especially sharp, and this document highlights some of the difficulties we've had getting a custom board working, and lists some of the solutions that we've found as we've trudged through this project. 

We found that the TMS320 documentation is very fragmented, and they don't update it for versions of the tools.  There were no free reference designs or schematics for the C6722, and many of the people we dealt with in their technical support were inept at answering our questions.  Also there are no cohesive manuals on how to create, and debug a custom board.  They just assume that you have a DSK board from the start. 

Why the C6722

We settled on the C6722 because it is one of the few high performance DSPs that comes in a non-BGA package.  It's also quite affordable in quantities.  BGAs are a total pain, because they can't be hand soldered, and you have to use an x-ray machine to debug them.  Who has time or money to do that?  So having the chip in a QFP sold us on it. 

Tool Pricing Inconsistencies 

For some reason the pricing on the DSKs and  XDS510 USB emulators varies wildly between Spectrum Digital and TI.  For example, the XDS510 emulator costs $1995 when you purchase from TI and  only $1295 from Spectrum Digital.  We were quite upset when we found out that TI had marked it up $700 more for the exact same product.  TI's pricing isn't consistent in that it lists this for $1495, on some links and $1995 on other's - the exact same product.  After about a dozen emails we were able to get a refund of the full difference of $694.  Thank you TI !

No Affordable DSK or Evaluation Board, and No Reference Schematic

While TI has done a great job with their MSP430 series in supplying affordable evaluation boards, they have dropped the ball with their TMS series, and have left it up to third parties to develop evaluation boards.  For the C672X they've left it to a third party to develop a PADK which costs $2000.  Who in their right mind wants to buy an "evaluation board" for that sort of money.  

We desired a simple reference design schematic so we could create our custom board, and were told that they had no reference design, and had to buy the PADK to get it's schematic.  Didn't anyone at TI build a board to test out the C672X?  Couldn't they have posted the board they created for testing purposes as a reference?

Installing the software

We installed CCS 3.3, and then it took us a while to find the latest drivers from spectrum digital. Turns out that they have a version for CCS 3.3.  You need these latest drivers to work with the C672X, because earlier versions don't support these chips correctly.  Note that spectrum web site directs you to their CCS3.1 release (Rev 3.01.04) which isn't the latest.  You really need to download from this link:

http://support.spectrumdigital.com/ccs33/

setupCCSPlatinum_v30318.ZIP

Multiple JTAG devices 

We built our first board and connected the emulator to it.  We opened the SDConfig utility and when we ran the "Emulator/Test" were perplexed because it found 2 JTAG devices with an IR length of 54.  When we contacted tech support, they said that this was correct, one was an 8-bit BYPASS device and the other was the CPU.  It seems to me that TI should have placed this fun fact somewhere in their documentation, rather than leaving it up to the end user to scratch their head in bewilderment. 

We used the CCS Configuration routine and selected the following device: 

"C672x XDS510 USB", 

which contains the CPU and bypass. 

Connection Problems

Our biggest problem occurred when we opened CCS3.3 and tried to connect to our custom board.  It would not connect and gave us cryptic error messages.   It was a baffling problem because the JTAG port was working and passing the tests of SDConfig utility. Since we were new to this processor family it was hard to know if it was a hardware problem or if we were missing some configuration file, or if there was a problem with the driver.  I contacted TI Tech support, and they were completely clueless as to how to help us. They kept offering bad advice based on the error codes.  

We were able to figure out the problem as follows.  We knew that the chip's JTAG worked from SDConfig.  We know that the oscillator was working, but wondered if it wasn't correct.  We also know that we could put it in a mode upon reset such that it would try to boot from a slave device.  When we set the SPI0 pins up accordingly, we noticed that the SPI0 clock wasn't running.  So this narrowed the problem to either the reset or clock.  When we probed the reset pin it was low, and found a faulty connection.  Once this was resolved we were able to connect with CCS. Note this whole debug process took over a week as we dealt with an inept technical support person at TI who lead us down many wrong paths.  It seems to me that CCS should have been able to detect that the device was in a reset mode, and respond accordingly. Anyhow, when we were finally able to connect there was much rejoicing!

Setting up a Project 

At this point we downloaded the DSP/BIOS patch which is a library and the Chip Support Library CSL for the C672X.  We wrote a simple C program, and got all sorts of compile and link errors.  The biggest problem was that it couldn't find the _int00 entry point.  It took a while but we realized we needed a linker.cmd file. We found one under the sample program in the CSL download, and used this.  Another issue we found was that the CSL framework has changed for the C672X, and so there is no CSL_INIT function, which older versions of the CSL documentation claim that you need. Once we remove this, we got the program to compile, link and download. Yea!

Library files can be dropped and dragged into the project, just like any source file. This is a nice feature. 

Blinking an LED

The first step with any new controller design is to blink an LED. We were able to use the McAsp libraries from the CSL to configure the port pins as GPIO. We used the CSL_mcaspHwSetupRaw function to configure some of the pins as GPIO, set their direction to OUT, set them to an asserted state.  Unfortunately, the pins wouldn't go high.  Turns out the problem is that the PDCLEAR register was getting set after the PDOUT was set, with the call to the function, and so it was undoing the register contents of PDOUT. After we figured this out, we were able to get an LED lit. 

I've noted that the CSL API is very limited. They don't have any functions to read the value of the McAsp registers, which is frustrating. 

No C672X GEL files

TI doesn't supply any GEL files for the C672X.  One of the big questions I had was do you need a GEL file to connect to a C6722 chip.  I asked TI for a sample GEL file and they told me to buy the PADK for $2000. It turns out you don't need a GEL file to connect. 

View Registers Is Broken In CCS

I noticed that when I was trying to debug the McAsp port pins that they only had one register set for the McAsp, when in reality there are two ports. Same for other peripherals such as the SPIs.  I also noticed that the registers where split between the two ports  This made it difficult to debug, since what was displayed was the wrong memory location.  I contacted TI and they acknowledged the error, in CCS.   They gave the following link for as a solution:

http://www-k.ext.ti.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=26,E=0000000000008498200,K=2716,Sxi=3,Case=obj(52791)

This tells you to create custom XML files to configure register sets.  Shouldn't TI solve this issue and create the correct XML file -  not an end user.  Maybe I should sell them the XML file once I get it working.

I've follows the directions in this link and after about 8 hours of messing with it was unable to get it working.  I used a GEL file to load in the device registers, but the register window comes up blank and undefined.  

I've sent a help request to TI and they told me that for the 6722 it doesn't retrieve it's values from an xml file, and were unwilling to provide a device file.  They told me tough luck and to use the memory view instead.  

Creating a Custom Board For CsConfig

I noticed that many of board configurations used by CsConfig are XML files, so I tried to see if I could create my own board file, and had some success, as described in this link:

How to Create a Custom Board Configuration for Code Composer

Creating a Custom Platform for BIOS/DSP Configuration

You need to create your own board platform so that you can select it as a BIOS/DSP configuration.  Under the [BIOS]/packages/mycompany/platforms/myboard there are a bunch of ".tci" template files, which you can use as a basis for setting up your custom platform file.  Read the "readme.txt" file for instructions. We based our file off of the C6722 template. 

You need to modify two items within a comment !Name, and !Description.  Note these must remain in the comment, don't un-comment the lines. For example:

* !NAME! Daycounter.platforms.Day6722
* !DESCRIPTION 6XXX! Daycounter - 6722 Board Configuration

Save this file as Platform.tci, and store in a directory [BIOS]\packages\Daycounter\platforms\Day6722

Now open and CCS and select  "File/New BIOS/DSP Configuration" from the menu. Select the C6XXX tag and you should see the new custom board.   Select this board, and a BIOS configuration window will pop up.  This will be saved as a ".tcf" in your project directory file for future reference.  You must add this ".tcf file to your project. 

When the ".tcf" file is created, there are several other files which are created:

ProjNamecfg.h,  ProjNamecfg_c.c, ProjName.cdb, ProjNamecfg.cmd

the linker command file cfg.cmd must be added to the project, or you will get a whole bunch of linker errors. Don't use the cdb file in place of the tcf.  The .h and _c.c files will appear under the "Generated Files" directory. Include the cfg.h file in your source code.

When you build the project, the tconf.exe program executes the ".tcf" script.  The compiler should be smart enough to know when ".tcf" file has been updated. To be sure you can do a "rebuild all", to get any changes to the script to be included in your program. 

Ocasionally when you click on the ".tcf" file from the project window, nothing happens. I speculate that there is some sort of lock file mechanism that they use that get's out of sync.  I haven't figured out which processes need to be killed to free the lock, but you can always restart windows to fix the issue. 

Re-Installation Is Broken

If you've been using the evaluation copy of CCS and then decide to buy a license, when you try to install, it will tell you that you first need to un-install the previous version.  I found that after installing, the bios_5_31_02 had the directory tree intact, but there were no files inside any of the directories.  In addition, when I tried to open an existing DSP/BIOS configuration, it would give me a server error.  After blowing two hours trying to resolve the problem, I realized that this directory had to be completely deleted, for the installation program to update it.  I had remembered that there were several tci files that I has created, and so I fortuneately moved these before I deleted the directory.  Once the directory was removed.  I uninstalled, and then reinstalled, and the directory was installed correctly.  

I'm amazed that the the install is smart enough to remove all of the files except the ones I created, but not smart enough to put them back for the reinstall.  This bug wasted another 2 hours of my time.  I absolutely hate code composer studio.   

Create a PRD

Open the Clock Manager property box.  Set Microseconds/Int to the desired rate. This value is the tick period. 

A PRD is a periodic function call. Create a simple function which will be called periodically.  Toggling an LED makes a good test function.  This function can be a void with no parameters.  Under the Periodic Function Manager node create a new PRD.  Under the function property put in the name of your function to be called with an underscore.  Select the number of ticks. Select Continuous.

Edit the Periodic Function Manager node and set "Use CLK Manager to drive PRD" to true. 

Chip Support Library is Crap

I've tried using the CSL to configure the GPIO pins on the McBSP and the PLLC, and both APIs are inadequate to do the job. As far as I can tell the API set's the registers but without any sort of intelligent ordering.  There is no way to set a single register. They must be set as a group, and thus you can not setup registers in a sequence, which is critical for setting up peripherals like the PLL.  After messing with the PLLC API and having it mess up the system clock such that the board had to be reset, I gave up, and used the PLL documentation to directly access the PLL registers.  As far as I can tell all of the CSL APIs are very clunky, and are just a thin wrapper around the registers, and were created without any sort of necessary insight into how the sequence in which registers should be set up.

It makes much more sense to access the registers directly, and bypass CSL completely.  TI would be better off supplying a independent register API, where you could access each register selectively. The end goal is to abstract the hardware, but if the API doesn't work, then people will bypass it anyway.  The fact that they don't have any include files which contain register definitions is also very annoying.  

Because the CSL doesn't really abstract the hardware at all, and provides such heinously bad documentation, you still need to read the documentation for each of the modules anyhow, to figure out each register that needs to be set.   They would be much better off just dropping CSL all together, providing register definition files, and then give some real world examples, as they do with the MSP series.   

Reset Before Load

I was having a problem with making program changes and having the compiler update the program.  It took me a while to even recognize that my code changes where not being implemented.  I was able to determine if the change was truly programmed by changing which LED was blinking each time I recompiled.  It became clear that I had to do a CPU reset before compiling and loading the code, otherwise, the my code changes wouldn't take affect.  Because code wasn't getting updated, or at least it seemed to be updated only randomly, I thought that the compiler/debugger was unreliable, or that I was losing my mind.  

After some research, I found a TI document "Creating Device Initialization GEL Files" which described the reset process.  While it didn't outright tell how to resolve this issue.  I was able to figure out the following GEL script to get the program to load consistently: 

OnPreFileLoaded(){
      GEL_Reset();
}

It seems to me that they should supply a GEL file with ever processor that they make, so that you don't have to figure this out by trial and error.   If a CPU reset is needed before loading code, TI should tell you this upfront.  

PRD Resolution

Okay now I have the PRDs working but their resolution seems to only 1ms using the default frame work.  So now I have to figure out how to change this.  

Boot Utilities Require Perl

The Boot Utilities are hidden nested in the C672X System Patch zip file.  Extact the utilities into the CCS tools directory. 

TI, in their infinite wisdom, decided to write genAIS the program which generates bootable images in perl, rather than as a windows executable.  This forces the end user to download the 15 megabyte installation of Perl.  CCS is targeted for Windows, so why would they force you to learn yet another tool, I guess they were worried the learning curve for their tools wasn't already steep enough.  I suppose one of their engineers decided it would be more fun to program in Perl, than keep a single common platform for their end user customers.  

I downloaded Active Perl 5.8 from www.activestate.com.  Don't download the .zip version.  Download the .msi version.  You can click on it, and windows installer msiexec recognizes it and performs the install.  Once you set up the following environment variables in windows you are ready to run genAis. 

PERL5LIB= bootUtilDir\lib

PATHEXT = %PATHEXT%; .PL

PATH = %PATH%; bootUtilDir\bin

genAis

Create a batch file to execute genAis with the following line:

genAis -i Debug/myprogram.out -o myprogram.ais -bootmode spislave -otype ascii -pkg tqfp

pause

This will create an ASCII readable AIS file.

When this was first ran it resulted in an error with a conflict in the memory map.  This was fixed by opening the DSP/BIOS configuration, and selecting "System/MEM Memory Section Manager/IRAM"  I changed the starting address from 0x10000000 to  0x10001000 and subtracted 0x1000 from the default length - 0x0001f000.  This resolved the problem nicely, and the AIS file was generated. 

PLL Issues

I had some problems due to the PLL not being initialized properly.  For example, the CPU Load graph wasn't getting updated.   This was because the PLL wasn't turned on, and so the CPU was running at the oscillator rate. In addition, I couldn't seem to get the PRD to trigger more than about 40KHz.  The various instruments are updated by the CPU, during the idle cycle, and so if an interrupt is firing, and leaving no time for the idle, then the CPU load graph doesn't get updated. 

The PLL has very stringent requirements that must be observed.  These are listed in the data sheet. I tried using the chip support library, but of course this was buggy, and there was no real world example.  Instead I followed the PLL documentation, and modified the registers directly.  

Another interesting symptom that I was seeing before I got the PLL working was that the processor would run for a second and then go off to no-where land.   I believe this was because one or more of the PLL registers was incorrectly configured.  

Interrupts and DSP/BIOS

You may find this hard to believe, but TI doesn't provide a single example on how to use the CSL with DSP/BIOS.  So there isn't a single example, on how to make your own hardware interrupt service routines.  I set up HWI_INT5 to generate an interrupt that toggles an IO pin.  Then I configured the RTI timer to generate periodic interrupts.  I couldn't get it to invoke the interrupt.  I eventually noticed that the interrupt associated with HWI_INT5 wasn't being enabled.  I was surprised that the DSP/BIOS doesn't set enable the darn thing.  Their technical support guy told me that the DSP/BIOS sets up the vector, and ISR framework, but the the CSL enables the interrupts. 

Unfortunately, this core register isn't memory mapped and thus not directly accessible without the CSL.  I was eventually able to figure out that the function CSL_intcEventEnable will enable the individual interrupts. Finding the define for the interrupt number was a total hassle. I needed to use CSL_INTC_EVENTID_RTI_INT_OVL_REQ which is defined as 5, but it was nowhere to be found in the documentation, and I had to scan the header files with another known interrupt to locate it.  

Setting Up RTI

I tried setting up the RTI using the second timer, but noticed that the registers I set, got clobbered after running the program.  I figured out that the PRD manager was responsible for overwriting my changes.   Fortunately they provide a hook for RTI initialization.  So I moved my RTI initialization code to this hook, and the registers held their values.  

I had trouble with the ISR only being called once.  I figured that the interrupt needed to be explicitly cleared by the ISR.  Turns out the RTIINTFLAG register is used to do this, despite this fact being completely undocumented.  In addition, the register is not a simple read write register, when you write a 1 bit it will clear the pending interrupt.  A one line comment in the documentation stating this fact would have saved 2 hours of wasted time.   I kept writing zero to the register, and nothing would change. 

Also the CSL is broken in regards to setting the RTIINTFLAG register. When the funciton:

CSL_rtiHwControl (hRti, CSL_RTI_CMD_CLEAR_INT0, &intEvent); 

is invoked, it clears all of the pending interrupts in the RTINTFLAG register, not just the INT0 flag. The result is that my other pending  RTI interrupts get's cleared, and thus never called. 

So once again, you can't use CSL because it is a buggy piece of code.  I'm starting to think that TI subcontracted the development of all of it's tools and APIs to Microsoft. 

[Employment] [Downloads][Articles] [Contact Us]

Call us now at 801-523-8444  -  136 E. Steep Mountain Dr. Draper, UT 84020

© Copyright 2004 Daycounter, Inc.  All rights Reserved.