DM642 Video capture issue

Started by jerome May 3, 2005
Hi,

As I said it in another post we currently work on a card which includes a
DSP TI TMS320DM642, a video decoder (SAA7118), SDRAM, etc....

Our aim is to capture a NTSC YUV video, save it and later compress it.

Until now we've succeeded in configuring the registers of the video
decoder; the output video data are as expected so this part has been
validated.

To capture these video data we've been using an example code given by TI
in a datasheet (SPRU629 if i remember well but I can be wrong).
Unfortunately we don't succeed in making it work!

First we've noticed that EDMA never does what we are expecting that is to
say to read the video samples saved on the video FIFO and copy them in
internal memory. 
So we've checked if the events which are supposed to initiate DMA tranfers
occurr. None event occurrs.

We've checked if the video data really come until the pins of the video
port (register PDIN) and this part was good.

If we chose to sync on SAV and EAV codes or on CTL0 input the result is
the same.

Some questions :
- Have we got access to the video FIFO ? If so is it only by DMA ?
- What are YSRCA,CBSRCA,CBSRCA exactly ? Do they contain the adresses
where the video samples are to be saved ? OR is it another thing ? Could
you explain please ?
- Has anyone here succeeded in making the video capture work, from the
example code given by TI ?
- Has anyone here suceeded in making it work from another code ?

Thanks for your help !


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

jerome wrote:
> > To capture these video data we've been using an example code given by TI > in a datasheet (SPRU629 if i remember well but I can be wrong). > Unfortunately we don't succeed in making it work!
I don't know if there's a newer version, but I didn't get the examples in SPRU629d to work. Your best bet, IMO, is to start from the vport mini driver example. Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Thanks for your answer. 

Glad to see we're not the only ones who aren't able to make those examples
to work! 

For the mini-driver I guess that will be hard to start from it since we
don't have the EVM card. How can we start from this ?

Anybody else has an idea to help us ?

Thanks.


>jerome wrote: >> >> To capture these video data we've been using an example code given by
TI
>> in a datasheet (SPRU629 if i remember well but I can be wrong). >> Unfortunately we don't succeed in making it work! > >I don't know if there's a newer version, but I didn't get the examples >in SPRU629d to work. > >Your best bet, IMO, is to start from the vport mini driver example. > >Cheers > >mark-r > >-- >"Let's meet the panel. You couldn't ask for four finer comedians - >so that answers your next question..." > -- Humphrey Lyttleton >
This message was sent using the Comp.DSP web interface on www.DSPRelated.com
jerome wrote:
> > For the mini-driver I guess that will be hard to start from it since we > don't have the EVM card. How can we start from this ?
At the moment, I'm still using the EVM, so the issue of porting to production hardware hasn't arisen yet. But the driver code is well structured so it shouldn't be too difficult. The amount of work needed clearly depends on how close your video hardware is to the EVM. If you're using SAA7115 and SAA7105 (or the TI decoder as supplied on the newer EVMs), and are happy to capture BT.656, then the changes should be minimal. If you're using a different decoder, you'll need to rewrite the driver for this, but this should be limited to changing the structure that holds the registers, and the I2C addresses. Good luck! Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Hi,

In fact, after reading the documentation SPRA918A about the mini-port
driver, I think this won't really help us. The reason is what is done by
creating this driver is not far from what we are doing in our codes.

Moreover, I must notify that the video decoder is a SAA7118 and that it's
well configured since the output video data are as expected.

Could you tell me if I'm wrong : in YSRCA there are data and these data
are simply the address where the Y samples are stored ?! Idem for CBSRC
and CRSRC ?! Why is this address equal to 0x7BDEC5C5 (just after the VP
module has been validated in PERCFG, 'cause this value changes many times
after) ?? Why isn't this address in the VP2 Channel A data space ?!!

Thanks for the answer.

Jerome  

>jerome wrote: >> >> For the mini-driver I guess that will be hard to start from it since
we
>> don't have the EVM card. How can we start from this ? > >At the moment, I'm still using the EVM, so the issue of porting to >production hardware hasn't arisen yet. But the driver code is well >structured so it shouldn't be too difficult. > >The amount of work needed clearly depends on how close your video >hardware is to the EVM. If you're using SAA7115 and SAA7105 (or the >TI decoder as supplied on the newer EVMs), and are happy to capture >BT.656, then the changes should be minimal. > >If you're using a different decoder, you'll need to rewrite the driver >for this, but this should be limited to changing the structure that >holds the registers, and the I2C addresses. > >Good luck! > >Cheers > >mark-r > >-- >"Let's meet the panel. You couldn't ask for four finer comedians - >so that answers your next question..." > -- Humphrey Lyttleton >
This message was sent using the Comp.DSP web interface on www.DSPRelated.com
jerome wrote:
> > Could you tell me if I'm wrong : in YSRCA there are data and these data > are simply the address where the Y samples are stored ?! Idem for CBSRC > and CRSRC ?! Why is this address equal to 0x7BDEC5C5 (just after the VP > module has been validated in PERCFG, 'cause this value changes many times > after) ?? Why isn't this address in the VP2 Channel A data space ?!!
YSRCA is the output of the Y capture FIFO, so yes, it will always contain the oldest unread Y sample. This is used as the source address for the Y channel EDMA transfer. Note that the video port is tightly coupled to the EDMA controller - you would never read YSRCA directly. I don't know why the address of YSRCA changes - as far as I know, it should be a fixed address, as returned by the Chip Support Library when the port is opened. Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Hi,

>YSRCA is the output of the Y capture FIFO, so yes, it will always >contain the oldest unread Y sample.
Ok. So, please tell me if I'm right or wrong : the incoming video data samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the user defined thresholds an EDMA event is generated, the first (or last) 64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the data in YSRCA and copy them in a user defined memory space ?
>I don't know why the address of YSRCA changes - as far as I know, it >should be a fixed address, as returned by the Chip Support Library >when the port is opened.
I think I wasn't clear last time : the address of YSRCA never changes, it's always 0x7C000000, but what changes are the data in YSRCA. So apparently, from what you said, if YSRCA is the output of the FIFO it's normal that the data always change. Maybe we found the reason why the capture doesn't work. In the documentation SPRU629D, on page 3-20, it's said that VCOUNT can be reset either by a change on EAV (bit V notifying if we are in the vertical blanking period or not) or either by using the VCTL1 input. In our card, VCTL1 is not connected. So we don't have the choice, VCOUNT must be reset when there is a change on EAV. The issue is that the video decoder SAA7118 doesn't add SAV and EAV codes when we are in the vertical blanking period. As a consequence, the DSP can never see a change on EAV and then VCOUNT is never reset !! How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? Do you think our problem comes from this ? Thanks a lot. Jerome This message was sent using the Comp.DSP web interface on www.DSPRelated.com
Hi,

>YSRCA is the output of the Y capture FIFO, so yes, it will always >contain the oldest unread Y sample.
Ok. So, please tell me if I'm right or wrong : the incoming video data samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the user defined thresholds an EDMA event is generated, the first (or last) 64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the data in YSRCA and copy them in a user defined memory space ?
>I don't know why the address of YSRCA changes - as far as I know, it >should be a fixed address, as returned by the Chip Support Library >when the port is opened.
I think I wasn't clear last time : the address of YSRCA never changes, it's always 0x7C000000, but what changes are the data in YSRCA. So apparently, from what you said, if YSRCA is the output of the FIFO it's normal that the data always change. Maybe we found the reason why the capture doesn't work. In the documentation SPRU629D, on page 3-20, it's said that VCOUNT can be reset either by a change on EAV (bit V notifying if we are in the vertical blanking period or not) or either by using the VCTL1 input. In our card, VCTL1 is not connected. So we don't have the choice, VCOUNT must be reset when there is a change on EAV. The issue is that the video decoder SAA7118 doesn't add SAV and EAV codes when we are in the vertical blanking period. As a consequence, the DSP can never see a change on EAV and then VCOUNT is never reset !! How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? Do you think our problem comes from this ? Thanks a lot. Jerome This message was sent using the Comp.DSP web interface on www.DSPRelated.com
jerome wrote:
> > Ok. So, please tell me if I'm right or wrong : the incoming video data > samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the > user defined thresholds an EDMA event is generated, the first (or last) > 64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the > data in YSRCA and copy them in a user defined memory space ?
Correct. When there are VCATHRLD dwords in the FIFO, an EDMA event occurs and the EDMA controller reads VCATHRLD dwords from the port into user memory. The EDMA operates in fixed-source, increment-destination mode, so it always reads the same address (the YSRCA register) but places the samples linearly in user memory. VCATHRLD is usually set to be a line's worth of samples, but doesn't have to be. Also, there are 2 VCATHRLD registers (VCATHRLD1 and VCATHRLD2) for odd and even fields. This process continues until the EDMA has transferred all the bytes it has been asked for (usually a field's worth), then it stops and fires its TCC event if it has one. The program must reconfigure the EDMA in time for the next field (or, alternatively, use Reloads to do it automatically, as the vport driver does).
> How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? > Do you think our problem comes from this ?
I use SAV/EAV, and it works fine with the SAA7115. I don't think that the 7118 would be all that different, but I've never used it. To be honest, I still think your best bet is to port the vport mini driver to your board, if only to prove your hardware. If you have the 7115 and 7118 data sheets side-by-side, you should be able to create a register structure for your part, then it should pretty much just work. If you don't have a display port (the vport app assumes an SAA7105 on port 2), you'll need to validate your images somehow, but at least you'll know the port is working. Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Hi,

>Correct. When there are VCATHRLD dwords in the FIFO, an EDMA event >occurs and the EDMA controller reads VCATHRLD dwords from the port into >user memory. The EDMA operates in fixed-source, increment-destination >mode, so it always reads the same address (the YSRCA register) but >places the samples linearly in user memory. VCATHRLD is usually set to >be a line's worth of samples, but doesn't have to be. Also, there are >2 VCATHRLD registers (VCATHRLD1 and VCATHRLD2) for odd and even fields.
Thanks for this explanation. It becomes more understandable for me.
>> How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? >> Do you think our problem comes from this ?
>I use SAV/EAV, and it works fine with the SAA7115. I don't think that >the 7118 would be all that different, but I've never used it.
I'm sorry but i can't see how you can reset VCOUNT thanks to SAV/EAV codes if these codes aren't included during the vertical blanking period?! Maybe you found a way to add them ? Could you explain how you do it ? Thanks.
>To be honest, I still think your best bet is to port the vport mini >driver to your board, if only to prove your hardware. If you have >the 7115 and 7118 data sheets side-by-side, you should be able to >create a register structure for your part, then it should pretty >much just work. If you don't have a display port (the vport app >assumes an SAA7105 on port 2), you'll need to validate your images >somehow, but at least you'll know the port is working.
Yes you're surely right but the fact is that i spent a lot of time typing a .h file with all the SAA7118 registers values and above all the part that concerns the video decoder is totaly validated. All the registers have the good values, the output signals are right too. I don't want to do it once again. Thanks for your help. Jerome This message was sent using the Comp.DSP web interface on www.DSPRelated.com