DM365 Image Sensor Interface (ISIF) - Pixel clock status during blanking (outside HD and VD) ?

Just a precision:

I would assume that all signals are inputs to DM365: HD, VD, PCLK.

Stopping PCLK is generally not possible, and it doesn’t need to be stopped.

In ISIF, there is register setting for setting the Valid Data Area.

Please check SPH, LNH, PPLN, SLV, LNV, LPFR

By setting this, only valid data area can be processed.

Please refer to Figure 2-1 "Frame Image Format" for details in the VPFE User's Guide:  http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Hello Jeff, If I asked the question it is because on my camera head it is possible to output pclk with some constraints related to HSync / VSync active state.

I notice that is doesn't need to be stopped.

Concerning the registers setting, it seems (and i had the same feeling with this doc previous version) that the values of these registers was here only for generating such synchro signals (in output) not to decode them (in inputs).

It is possible for the davinci to generate such signals in output (while pclk stay in input), that is why this point is still not clear. In the registers description of (HDW, VDW,) PPLN, LPFR is is said in this sense: only used when HD and VD are set in output mode.

you are still right for the SPH, LNH, SLV, LNV registers.

thank for your help.

my problem is that i try to use the Appro IPNC using a YUV sensor and get problems synchronizing the ISIF and IPIPEIF with.

Hi Reda,

I am not sure about the exact problem you are facing, so any more details would help to analyze it better.

To answer your question about PCLK input and HD/VD as output, yes you can do it. You can have PCLK as your input to ISIF and make ISIF generate the timing for the frame.

What do you mean by the statement that you are not able to use Appro IPNC using a YUV sensor? Have you made changes in the code to support the YUV input mode? Are you getting the data captured at ISIF?

Based on your answers/inputs, i can answer you better.

Regards,

Anshuman

Hi Anshuman, glad to read you again.

Well indeed, I was debugging my application based on the avserver of ipnc.

I had problems with capturing images to buffers using a camera streaming YCbCr4:2:2 format images. Indeed I had no buffering while using "moduletest.out drv_isif".

Since I had devalidated (on my camera) PCLK outside HD and VD enveloppes and having read that PCLK was used in internal synchronisation of DM365's VPFE, i wondered if the source of my problem was not this point.

I have revalidated PCLK (always active) and I have set the VPFE better (through better understanding - especially that IPIPEIF was BEFORE ISIF in the datapath) and now something is buffered and I read some images. Still problems of image quality, but this is another story.

But still I wondered if the VPFE works perfectly when PCLK is validated only inside HD & VD enveloppes.

Thanks for enquiring anyway.

Regards

Reda

Hi Reda,

I did not understand your following quote correctly.

reda38 said:

But still I wondered if the VPFE works perfectly when PCLK is validated only inside HD & VD enveloppes.

In our systems we have tested that PCLK keeps on coming all the time, even during HD and VD signals. Is this not what you are looking for?

BTW, from your post, i was not clear whether you are able to get the YUV data correctly or not from the ISIF. If you want any help on ISIF settings, you can provide the register dump and the captured YUV data from ISIF so that we can help you answer better.

Regards,

Anshuman

hello anshuman.

For the sentence you quote and for the answer you gave i understand better now : in DM365 VPFE needs that PCLK to be always available even OUTSIDE HD and VD. That PCLK is active inside HD and VD is the normal behaviour but outside HD and VD is not so obvious.

My imaging system can choose to output PCLK either  inside and outside HD and VD or only inside. I had to choose. So now my choice is clear.

To answer your second question, I captured YUV data using the moduletest.out drv_isif and I recovered a IMAGExxx.RAW image that i inout into a YUV viewer and the result was like there was the Y plane missing.

My YUV data is on 8 bits (YUV8 input mode), and i set apparently correctly the channel order in my imaging system to adapt the UYVY order of isif. The data output on the camera are apparently good too, so I need to check more deeply, by getting a dump of ISIF registers during the run of drv_isif test and come back to you in case of problem or if  i solve the issue too.

thank you  for answers

Hi Reda,

Thanks for your feedback. Just another pointer, there are quite a few bits/registers related to YUV8 input mode in ISIF. Please take a note of those when you are programming the ISIF. It might be that one of the registers might be wrong. If you could share the data or the ISIF register settings, i could help. But as you said, you would try to find it out, it will be even better. Let me know whenever you need any info from us.

Regards,

Anshuman

Hello Anshuman,

I continued my investigations on the IPNC application I try to adapt to a YUV camera. I still have some doubt on my sensor clocking scheme, but i need to contact sensor manufacturer to be sure of this. In the meantime I need infos from you as regards to some settings of the ISIF. My camera is a VGA (640x480) and it outputs YUV422 on 8 bit, So there are 2 pixel clocks to get a UY or VY on 8 bit bus.

I hacked the Drv_isif_test_run procedure and had the 1st line of every image in buffer printed in the format  [ U Y V Y ].

And it appeared clearly that all the Y components were equal to 0 in memory. All U and V were clearly not zero and well changing when scene (or colour bars) changed. So ti seems IPIPE is well set (easy mux configuration, data from parallel input).

I have programmed my sensor to output a colour bars with static well defined values on a line and there are still some zeros even when data is high. So there is like a problem inside ISIF regarding this config.

I printed the configuration of the ISIF below and have added my understanding of registers setting. It arose 2 questions

*****1st question : concerning the packing of data in memory in the register   at @ 0x01c71088: CCD Config : Y8POS= even pixel ( U Y V Y); YCINSWAP=CIN[]=C[] and Y[] since INPMOD=2; SDRAM  pack = 16 bits/pixel.

As said in VPFE document paragraph 4.1.4.3 and 4.1.5 th YUV4.2.2 data are packed 2 pixels per 32bits words so it seems that my setting is OK.

*****2nd question: the IPNC set Number of Lines Vertical to 479 (a +1 will be added) but not the Number of pixels in line which is set to 640 instead of 639.

The problem of changing this application is that the code is so embedded in layers of software that risk is important to break details.

Here are my ISIF registers Dumping:

***************************************************************************************************

 0x01c71000: 00000003 SYNCEN: DWEN=1;SYEN=1
 0x01c71004: 00002000 MODESET: INPMOD=2 (YCbCr 8bit), HD,VD as input with polarity=positive
 0x01c71008: 00000000 HD pulse Width : no use here since HD=input
 0x01c7100c: 00000000 VD pulse Width : no use here since VD=input
 0x01c71010: 0000027f Pixels per line: 640
 0x01c71014: 000003bf Lines per Frame: 959 ! BUT no use since HD and VD= input
 0x01c71018: 00000000 Start Pixel Horizontal: 0
 0x01c7101c: 0000027f Number of pixels in line : 640
 0x01c71020: 00000000 Start Line Vertical0 (from VD) : 0
 0x01c71024: 00000000 Start Line Vertical1 (from VD) : 0
 0x01c71028: 000001df Number of Lines Vertical : 479
 0x01c7102c: 0000ffff Culling Horizontal : retain for all pixels
 0x01c71030: 000000ff Culling Vetical : retain for all pixels
 0x01c71034: 00000028 Horizontal Size (adress offset) for each line: 40 x 16 = 640;  Adress Increment setting
 0x01c71038: 00000000 SDRAM Line Offset : 0
 0x01c7103c: 00000426 SDRAM Adress high : 0x426
 0x01c71040: 00005700 SDRAM Adress low :  0x5700
 0x01c71044: 00000000 -
 0x01c71048: 00000000 -
 0x01c7104c: 0000b1b1 CCD Color Pattern:  R/Ye:  No use since YCbCr input data
 0x01c71050: 00000200 CCD Gain R/Ye Adjustment:  No use since YCbCr input; gain =1.0
 0x01c71054: 00000200 CCD Gain Gr/Cy Adjustment: No use since YCbCr input; gain =1.0
 0x01c71058: 00000200 CCD Gain Gb/G Adjustment:  No use since YCbCr input; gain =1.0
 0x01c7105c: 00000200 CCD Gain B/Mge Adjustment: No use since YCbCr input; gain =1.0
 0x01c71060: 00000000 CCD Offset Adjustment : 0
 0x01c71064: 00000000 Flash Config 0: Disable
 0x01c71068: 00000000 Flash Config 1: start line 0
 0x01c7106c: 00000000 Flash Config 2: valid width of the Flash timing signal 0
 0x01c71070: 000001df VDINT0 : line number interrupt 0= 479
 0x01c71074: 000001df VDINT1 : line number interrupt 1= 479
 0x01c71078: 000001df VDINT2 : line number interrupt 2= 479
 0x01c7107c: 00000000
 0x01c71080: 00000010 Gamma Correction Settings : Disable WB,H3A,Offset SDRAM,Offset IPIPE, CFA=Mosaic, GWDI=MSB bit=7 (for 8 bit data), Gamma control off
 0x01c71084: 00000000 CCIR656 controls = Off
 0x01c71088: 00000100 CCD Config : Y8POS= even pixel ( U Y V Y); YCINSWAP=CIN[]=C[] and Y[] since INPMOD=2; SDRAM pack = 16 bits/pixel.

 0x01c7108c to 0x01c710a8 : 00000000 Defect Correction Registers are all set to 0: no use here.
 0x01c710ac to 0x01c710d4 : 00000000 Black Clamping Registers are all set to 0: no use here.
 
 I leave the Color Space Converter coefficients which are not used here.
***************************************************************************************************

Best Regards and thank for your help.

Here are the registers, best regards.

Hi Reda,

reda38 said:

*****1st question : concerning the packing of data in memory in the register   at @ 0x01c71088: CCD Config : Y8POS= even pixel ( U Y V Y); YCINSWAP=CIN[]=C[] and Y[] since INPMOD=2; SDRAM  pack = 16 bits/pixel.

As said in VPFE document paragraph 4.1.4.3 and 4.1.5 th YUV4.2.2 data are packed 2 pixels per 32bits words so it seems that my setting is OK.

Looking at your registers, it is clear that you are having only Y8POS bit set and rest all is default. I assume changing the value of Y8POS from 1 to 0, should not have made a difference. Isnt it?

All your registers are looking good.

reda38 said:

*****2nd question: the IPNC set Number of Lines Vertical to 479 (a +1 will be added) but not the Number of pixels in line which is set to 640 instead of 639.

The problem of changing this application is that the code is so embedded in layers of software that risk is important to break details.

***************************************************************************************************

 

You are right. LNH should be set to 639 instead of 640.

A few more suggestions to try:

1. Fill your buffer with some known pattern before capturing. This is to ensure that you are getting 0x00 or is it some old data.

2. Change your VDINT0, VDINT1 register value to say 460 or 470, instead of 479.

3. Have you checked the data in other lines or the complete frame?

4. Can you change the SLV0 and SLV1 to say 1 instead of 0?

5. Can you change the HD/VD polarity also?

Regards,

Anshuman

Hi Anshuman,

New advances in debugging this problem. I followed some of your suggestions and some of mine!

-First of all, I reduced the input date speed and set my color bars out of my sensor. On an observable pattern of these bars, the Y component is not 0 for a width. So the problem comes from the davinci.

-As suggested by you in 1/ I filled the buffer with 0xAA, this debug part of the code was already written. I noticed that the 0 were written by the application or davinci hardware. And this was observable on the first line  but also on the whole image as suggested by you in 3/.

-I have not tried other suggestions, because I checked if the SDRAM pack was not an issue. I changed the SDRAM pack of 16bits per pixel to 8 bits per pixel and it worked. There was no more 0 on the first line. I displayed the YUV image, and it was half filled with my pattern but color inverted and by an homogenous zone which corresponded to the AA pixel value left in buffer. So I had to discover why the Y and UV channels were swapped and why the second part of image was not filled up.

-I have tried the ODD position for the Y channel. My sensor sends U Y V Y. the ODD position made the color appear OK. So could you explain why ODD and EVEN means in the TI datasheet. Indeed what I translated is :  EVEN position is (Y First, UV second) and ODD position is (UV first , Y second).

-Now my half image problem was solved when i dug into the drv_isif.c and the CSL_ccdcHwSetup.c. Indeed the sdram.outwidth was set to the validwidth which is representing my piwel width and not my bytes width which was 2 times this number. This also is a consequence of having changed the sdram packing to 8bits/pixels. Which is not totally true in the words meaning. What i guess is that the sdram packing indicates the number of bits per pixel channel and not the whole pixel (all components).

So by just replacing the sdram.outwidth by the ddrdataHoffset which represents length of data, i got the right image width and size (670x480x2bytes) with the right colors.

No need to tweek the other parameters. I will have a look anyway to the LNH parameter not set properly. But it must be sure it hasnot been replaced inside the code.

Can you confirm

1-the ODD/EVEN point in term of hardware. the datasheet is not very explicit

2-the sdram packing issue, words used are not proper or there is a mix of parameters which make my application work.

thank you for your help and suggestions

A few more suggestions to try:

1. Fill your buffer with some known pattern before capturing. This is to ensure that you are getting 0x00 or is it some old data.

2. Change your VDINT0, VDINT1 register value to say 460 or 470, instead of 479.

3. Have you checked the data in other lines or the complete frame?

4. Can you change the SLV0 and SLV1 to say 1 instead of 0?

5. Can you change the HD/VD polarity also?

Hello Anshuman,

Thank you for the answer and the actions taken for documentation. I hope I made no understanding mistake in relating my changes.

I will now try to send the YUV422 data to the resizer to get YUV420 and then to the H264 encoder. Pbms will arise surely. But his is another story.

Regards and thank upi for h.your help

.

Reda.

Thanks for the confirmation.

Regards,

Anshuman

i have a  problem  in our dm365 that is when the vpfe_isr  interrupt enter i find the MODESET MDFS bit always  is 0   (odd field ). so data is not copy to Application  compare dm365 evm  the   MODESET MDFS bit  is 0 and 1 in turn  .why? our dm365 is ycbcr 16bit data input

thank your give me a suggestion  to slove the probem. 

Regards.

Hello Aen, The topic has been verified answerred. To give your question more chances to be answered, you should create another new topic with your question.

reda

Hello Aen,

FYI. I have answered your question in another post.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Dear,

I am developing a program to capture raw data from FPGA-> ISIF -> SDRAM.

I am using leopard dm368 board, could you show me ISIF register dump?

Thank you!