Forums

TI DM642 Video Capture or I2C initialization problem

Started by Matthias January 26, 2006
Hi,

I am trying a simple video loop through application using the EVM DM642
from Spectrum Digital. (EVM v3 with TI decoders, CCS 3.1, DSP/BIOS 5.2)

As far as I can tell my code as well as the DSP/BIOS configuration is
identical to the samples provided.
Unfortunately, the program hangs during the start up phase, either
during EVM_init() or in the capture task during the first call to
FVID_alloc. The behaviour is exactly like Ryan has described it last
year. Please refer to his posting below. (This is not meant as being
top-posted, but rather considered as kind of attachment...).

I assume I am missing a small but crucial part for initialization or
configuration.

He did not get a reply - maybe I have more luck?
BTW, did you solve it, Ryan?

Any hint or comment is appreciated!

Regards,
Matthias


On 2005-03-16, Ryan wrote in comp.dsp:

> I have designed an inhouse development board similar to the EVMDM642 > developed by Spectrum Digital. The similarities are the SDRAM and > SAA7115 video decoder I use are exactly the same as the EVM. (Okay the > SDRAM is half the size of the EVM, but the speed grade is the same. I > have adjusted the EMIF setup so that the number of address bits is now > 11 instead of 12). > > I am having a problem initialising the video capture driver. I am > testing my board using the provided example video software, ie in the > folder: board\evmdm642\examples\video\driver. > > The problem I am having is with the call to the function FVID_alloc. > The other driver init functions preceding this call seem to execute > okay as they all return the expected values. However when I call the > FVID_alloc func, 1 of the following most often occurs: > it returns with -2 (semaphore timeout occured), I get stuck in a loop > waiting for the I2C bus to become available, or I vector off into some > meaningless memory space and the programs hangs. Note the program > executes from SDRAM, internal RAM is used only as Data space. Cache is > disabled. I have also altered the GEL file so that the FPGA is not > loaded etc. > > At first I thought I had a SDRAM problem, but I wrote a little test > program that exexutes from internal RAM and performs a series of reads > & writes (all 1's, all 0's and random values) to SDRAM and it passes > every time. > > The interesting thing is that if I place break points between the main > driver init function calls (ie slow the program down), then the driver > often intialises okay. It is only when I try and init the driver at > normal speed does it hang badly. > > So as it stands now I am not sure if there is a hardware or software > problem. I am using CCS ver 2.20.18. Another thing that concerns me is > that the EVMDM642 that I purchased was the first version and it uses a > TMX320DM642 DSP. So I am not sure that this version of CCS is fully > compatible with the TMS320DM642 that I am now using on my board. Are > the CSL, run-time libraries, GIO funcs etc the same or have there been > corrections due to errors in the TMX DSP? > > Could someone please inform me what versions are available for DM642 > devices after 2.20.18 (excluding the latest ver 3.0) and if possible > where I could obtain a patch? > > If anyone could shed some light on my problems I would appreciate it > very much!! > > Thanks > Ryan
Matthias wrote:
> > As far as I can tell my code as well as the DSP/BIOS configuration is > identical to the samples provided.
The first thing to do is see whether the example code exactly as supplied out of the box works. If not, then either your board or setup is faulty. One thing is to make sure you have the newest CSL - some CSL releases have had bugs that prevent the video samples working. If the sample code works but yours doesn't, then you've broken it! The c6000 is very unforgiving of trampling over unallocated memory - shared code and data space and memory-mapped registers are a recipe for weirdness, and often difficult to pin down. If you hit the "Halt" button and the code breaks in an unexpected place (usually executing data as code), then you can be fairly sure you've blown a stack or scribbled off the end of your memory. Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton