8-bit BT.656 embedded sync capture on VIP1 PORTB

Another update ,We have verified that 8-bit bt.656 embedded sync capture is happening  on VIP1 PORTB using chains application .

Hi, we are trying to do the same thing (capture on VIP1 PORTB in 8 bit .656)  and finding the same as you are.

I recently just got the register map but am having trouble getting at the registers. If I try in u-boot, the HDVSS isn't fully enabled so md/mw hangs. If I use the JTAG I can read registers ok if I download a program via CodeComposer 5.2 but if I don't download a program, and just try to connect to the target directly - I seem to get complete garbage from the VIP1_PARSER register space.

Would you mind sharing how you read/access the registers to check the status of the VIP1 port?  I'll trade with any progress I'm able to make on getting this to work.

Best regards

Ian

Hi Ian ,

I am also loading the firmware into the target and checking for the register values .  I can't debug when i am just connecting to the target in CCS  .

The firmware_loader binary will be loading the firmware into the VPSS-M3 core ,but I am loading the firmware again after connecting to the target in CCS and debugging .

Can you tell me the progress that you have made in  bt.656 capture on VIP1 PORTB ? are you able to capture bt,656 data ?

Thanks,

Siva .

Hi,

Thanks for the update Siva. I'll have to find/try loading the firmware into the target as well

It's a pretty straight forward answer on capturing on VIP1 PORTB. So far none!  I've been able to run a capture on port A (16 bit) but when I modify the OMX setup to use PORTB, 8 BIT it builds the framework but never delivers any data or any errors. I've verified I have a proper 8 bit stream of data coming in @ 27MHz, although my format is CrYCbY not YCrYCb (which is another concern , but I do see a valid FF 00 00 <xyz) sequence in the right order so I'm mostly just expecting bogus colors for the moment.. if I can get anything at all.

That's why I'm looking for the registers, to see if the hardware is detecting the stream as valid, and then debug from there. I've seen a few threads about not being able to get 8 bit PORTB captures working and a very quiet response from TI on the matter.  

Regards

Ian

Ian ,

Can you read the VIP registers now , Does the VIP registers show the incoming stream as valid ? Have you tried bt.656 8-bit capture  on VIP0 PORTA ?

Thanks,

Siva .

Hi Ian ,

Any updates at your side ?

Thanks,

Siva .

Hi Siva,

(Apologies to the delay,  I had to switch to another task and only got back to it yesterday).

I did get access to the registers, but I found an easier method to use mem_util <addr> to read/write individual registers without having to match up firmware/kernel images and go through the code composer. Handy utility to have.

Anyway, I am now at the point you are too. With video coming in, I can enable the VIP1B port and see that it detects the video src dimensions.

My registers now read

0x4810551C = 0x9000

0x48105570 = 0x02d000fD.

But while the size and connection is detected, "VDET" Status for Portb is still clear. I'm thinking that VDET_STATUS should have gone high? Not exactly well documented that bit...

I did find, that if I have my video stream running before I boot the linux system ( using the ezsdk prebuilt kernel/filesystem via NFS) that I get a fatal exception during boot. (Unhandled interrupt it would seem). If I stop the video stream, boot linux, then turn on the video - no crash.

Not sure if this is an i2c bus issue (I have to use the i2c bus from u-boot to configure my incoming video presently)  or a stray interrupt (SRC/CONN FIQ ?) that happens. Something to fix later I guess.

How about you - any progress on your side?

Hi Ian ,

Sorry for the late reply ,I was working on other custom board . I have tried 8-bit bt.656 capture on VIP0 PORTA  using the OMX app ,Its working fine for me and i am getting a clear display . In our custom board the video decoder is connected to FPGA and FPGA is sending the bt.656 embedded sync stream on VIP0 PORTA  .

I came back to the problem bt.656 capture on VIP1 PORTB , I don't see any display and the OMX application hangs  . Previously I was trying bt.656 video capture on VIP0 PORTB on other board ,I didn't get any display on VIP0 PORTB too . I am clueless regarding PORTB capture ,I can see the input video is detected by VIP parser block ,but the frames are not captured by OMX VFCC component .

0x48105a70   -  0x02D000F2 for VIP1 PORTB .

Also you mentioned "VDET " status for PORTB is still clear ,Can you tell me which register you are seeing for VDET_STATUS ? any progress you have made on your side ?

Thanks,

Siva .

Were you seeing VDET bit getting set for VIP0_PortA? I dont think so, this bit is not used for single channel capture.

Thanks,

Brijesh Jadav

Hi Brijesh ,

Can you confirm us that 8-bit bt.656 embedded sync capture works on VIP1 PORTB using OMX VFCC component . We are able to prove the bt,656 embedded sync capture on VIP1 PORTB using chains application .

But ,with the OMX application i am not able to capture on VIP1 PORTB . Can you suggest me where i can look into in OMX framework  to solve the PORTB capture problem ?

Thanks,

Siva .

Hi Ian ,

Any updates at your side, Have you tried out anything new ? Can you please share what you have done .

Thanks,

Siva .

Hi Ti Engineers ,

Can anyone from TI help me with this issue ,bt.656 stream capture on PORTB ? Can you people say something about this ?

It's been a long time since i posted this problem ,Please comment . PORTB capture works or it doesn't work using EZSDK 5.04 ?

Thanks,

Siva .

Hi Ti ,

I am attaching the OMX logs (with DEBUG LEVEL=3) for bt.656 capture on PORTA (working ) and PORTB(not working ) .7484.log3_omx_porta.txt8836.log3_omx_portb.txt

From the logs i observe that Capture_drvOverflowDetectAndReset() has been called  4 times incase of PORTA but only one time in case of PORTB .

Can the above observation mean something ? Can anyone help me out in finding the problem in PORTB ?

Thanks .

Hello Siva, I only just got to look at this again.

I still do not have a working capture. I had been waiting on driver sources to help debug/tweak the captures but TI has since declared that won't happen so I'm back to prodding registers to try and figure out what is broken.

Thanks for your logs btw. I've been trying to see if I can get the loggerSM working on my setup but haven't had any luck.  (It's a major pain in the neck to find/compile this code as none of the paths in the ezsdk install dir match the installation I've found... ).  Did you find an easy way to use the logger? What did you use for the client / to retrieve the logs? I have the app compiled in with the libraries but can't find the output yet to know if it's working...

I realise one thing looking through your post by the way. Are you using VIP2_PORTB or VIP1_PORTB ?? Because of the inconsistency in  the TI docs regarding naming port 0 and port 1 vs port 1 and port 2 is tedious so I'm not sure now which port you are capturing on. If it's VIP2_PORTB - are you sure your pin mux tables are set correctly? This 8 bit port is shared with the ethernet so I wonder if that's why you might be having problems.  VIP1_PORTB should work though... assuming you have the y/cr/cb data on the right 8 bits.

My latest test, seems to be reporting a size of 720x254 which is absurd. Somehow the VIP_PARSER seems to be missing the end of field/frame. The capture chipset (Analog devices part) correctly reports the 720x240 format /resolution... I have seen the DM8148 report the correct 720x240 size before though so not sure what changed between my tests - still looking into this.

Hi Ian,

For the OMX logs you can try using the loggerSMDump.out  utility ,its there in /usr/share/ti/ti-uia folder in the ezsdk root filesystem . There are various debug levels ,you can set the debug levels in the OMX application  .  Below link will help you .

http://processors.wiki.ti.com/index.php/OMX_Viewing_Media_Controller_Traces

Regarding PORTB capture , I am trying to do the capture on VIP2 PORTB now , previously I tried on VIP1 PORTB with another setup . I have checked the PINMUX details for VIP2 PORTB lines ,they are correct . I can see that resolution got detected in VIP parser block which confirms the pin muxing of VIP2 PORTB . Still i am not able to capture any frames on VIP2 PORTB .

Have you gone through my logs ?Have you found out anything interesting ?

Ian ,

Any updates on PORTB capture ? Seen anything different ,Can you share on the progress that you have made on PORTB capture ?

Thanks,

Siva .

Hi Siva,

Hot off the press, I just confirmed 8 bit capture using the openMAX drivers/ezsdk platform.

I found that I had to update to the newest EZSDK (5.05.04.01) and the associated modules/firmware for it to work.

Previously I had been using 5.03 and 5.04... ezsdk releases and not had any luck. I have some other issues with the filesystem/kernel stability but the video capture does at least work.  Now I need to make sure I'm getting all the lines/can deinterlace fields etc properly. I think right now we're just running from one field - but honestly, figuring out what is being captured isn't so obvious from the code/docs. 

I suggest you try the new platform release (oct16th release) and see if that helps you make progress.

Ian

Hi Ian ,

Thanks for the update ,good news at last . I will update to EZSDK 5.05 . Can you tell me on which port 8-bit bt.656 capture started working ? Is it on VIP1 PORTB or VIP2 PORTB?

Thanks,

Siva .

Tested VIP1 PORTB so far.

I hope to test VIP2 PORT B today but need to move my filesystem and kernel over to NAND flash first.

Regards and good luck

Ian

FYI VIP2 PortB appears to be working as well.

I don't have display of the captured video running standalone without the network at present, so I'm assuming the picture is okay, but the capture program is reporting frames detected and the VIP_PARSER/VFCC/VPDMA appear correctly configured.

Ian

Hi, I face the same problem with you now, I use RDK2.8,VIP0 A.

Can you tell me how you solved this? I need your help.

Thanks.

Hi,

   In the DM8168-EVM we got the TVP5147 working with V4L2, you can find more info here:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/326172/1170437.aspx#1170437

-David