dm365 v4l2 driver sometimes dequeues wrong buffer

Jan,

Which is the sensor that you are using? What is the resolution and frame rate? What is the pixel clock used for sending the data from camera? 

Hi,

I use sensor from Aptina mt9d111. It outputs processed YUV data in V4L2_MBUS_FMT_UYVY8_2X8 and resizer formats them to V4L2_MBUS_FMT_NV12_1X20 to be able to encode them with  dm365 h264 encoder. Frame rate is cca 9 fps on 1600x1200, but I tried also smaller resolutions (with higher fps) and the behaviour is the same. Pixel clock frequency is 40MHz.

regards
Jan

Jan,

Can you try the increasing the VSYNC duration in the camera sensor registers and see whether any difference occurs? Try to increase VYSNC duration by a good margin and your frame rate also should drop to 8 or less fps. This will help in identifying any latency in the interrupt handler is causing the problem or not.

Hi,

Unfortunately my sensor have no settings to set VSYNC duration, but I have enabled readout of bottom dark rows, which has similar effect. Know everything seems ok, so it seems that interrupt latencies may be the source of the problems. Do you think it can be solved inside the driver? Some kind of locking could do the job.

regards
Jan

Jan,

Its possible to change the VSYNC duration using the registers R6/R8 Vertical Blanking located at the offset 0x06/0x08. The default value is 0x20, try checking the value that your driver might be writing and then increase the value and see if there is any difference exists or not.

What I assume is that, since the path is through resizer, there will be a slight latency introduced by the resizer and since you are using resizer output done as the interrupt, and by the time your handler completes, next VSYNC would have occurred. So if the VYSNC delay is too low, then there won't be ample time to do the handling part. 

Hi,

I thought you want me to make the  vsync pulse longer - no just lower the fps, I also think that Vertical blanking time has no effect to the pulse length (with respect to actual frame) and it just specifies the time when next integration will start (and next rising edge on VSYNC). There is also a problem with the fact that the sensor is unable to output pixclk during vertical blanking and it seems that dm365 image interface does not like that.

Nevertheless both approaches solved my problem (prolonging the pulse by adding some blank rows even changing the VBLANK period). I'm just curious if this problem can be solved directly in VPFE driver.

regards
Jan

Hi Renjith,

 now I also discovered that the described problem is very sensitive to another drivers activity. When some other driver do a hard work (with some delays) errors in video stream are more frequent.

I have tried to add a small delay to vpfe_schedule_next_buffer (called from dma isr), and it's getting better, but this is not a good approach...

 regards
Jan

Jan,

I don't think changing the VBLANK will be the solution, but instead we can observe and understand the behavior better. I don't want to reduce the frame rate, instead I want to give more time to the interrupt handler. But in any case sensor should have output pixel clock during the blanking interval.

So, is that the reason for this behavior? Since the whole VPBE is driven by in the input pixel clock, what will be the effect of stopping the pixel clock in the pipe-line. I think more analysis needs to be done about this.

I don't have the MT9111 datasheet with me. I'm referring to MT9P031 datasheet which I feel that its almost similar. According to the camera datasheet, pixel clock should always be running even during blanking interval.  

Can you check whether HS/VS/PIXCLK lines are configured as input or output ISP? If this is output, then the signals are driven by ISP and not camera. Then there is a chance the pixel need not be active during blanking. If it is configured as output, the can we try to configure it as input (both ISP and camera registers).

Jan,

This info is interesting. So then I think we can almost confirm the interrupt handler latency is the culprit. If we can get continuous PIXCLK then that itself should solve the problem I believe.

Hi Renjith,

I have confused myself about PIXCLK signal. In fact it is continuous in all circumstances. It is the HSYNC signal that is inhibited while vertical blanking. It caused problems when I need to read full size image from the sensor (1600x1200) through resizer. Local field application engineer helped me with this and we enabled the readout of bottom dark rows, which has the effect of adding several HSYNC pulses after the frame.

Back to the actual problem with frame order. I have measured the behavior of synchro signals with an oscilloscope. Following figure depicts the situation when the stream is ok. D0 is VSYNC, D1 is HSYNC, D2 is PIXCLK (40MHz) and D3 is a pulse made in the resizer interrupt (rsz_dma_isr()).

Even if the interrupt is fired after next VSYNC pulse, the stream is correct. I can force this behavior by adding a 50us delay (udelay(50)) to the interrupt routine. Without this nasty workaround the frame order is corrupted and on the scope I can see that the interrupt is often triggered more lately.

Is this information enough for you to identify the problem and found proper solution, please?

 best regards
Jan

Jan,

This is really good info. From the wave forms its very evident that the handler is getting called after the VSYNC rising edge, which should have happened during the VSYNC LOW. Because of which it ends up writing next buffers address in the address register little late. This will get updated only after next VD. So, the resizer will use the old buffer instead. 

Can you dump all the VPFE registers and share? If not all, at least 

1. IPIPE I/F Configuration 2 (CFG2)

2. MODESET

Jan,

Also when you introduce udelay(50); what is happening is that it is consistently delaying all the frames. If I put F1 it will start getting written after current F0 is written. There will be a additional latency of 1 frame, but only thing is that the order will be consistently maintained. 

Hi, 

 here is the vpfe registers dump (in the time when VIDIOC_STREAM_ON was called)

IPIPE Configuration context
**************************************************
Operation mode = CONTINUOUS
Resizer chained
Serializer is disabled
Previewer is configured
Resizer is configured
IPIPEIF Registers
**************************************************
IPIPEIF ENABLE = 0x0
IPIPEIF CFG = 0x2000
IPIPEIF PPLN = 0x0
IPIPEIF LPFR = 0x0
IPIPEIF HNUM = 0x0
IPIPEIF VNUM = 0x0
IPIPEIF ADDRU = 0x0
IPIPEIF ADDRL = 0x0
IPIPEIF ADOFS = 0x0
IPIPEIF RSZ = 0x10
IPIPEIF GAIN = 0x200
IPIPEIF DPCM = 0x0
IPIPEIF CFG2 = 0x48
IPIPEIF INIRSZ = 0x0
IPIPEIF OCLIP = fff
IPIPEIF DTUDF = 0
IPIPEIF CLKDIV = 1
IPIPEIF DPC1 = 0
IPIPEIF DPC2 = 0
IPIPEIF DFSGVL = 0
IPIPEIF DFSGTH = fff
IPIPEIF RSZ3A = 10
IPIPEIF INIRSZ3A = 0
**************************************************
IPIPE Registers
**************************************************
IPIPE[0] : 1
IPIPE[4] : 0
IPIPE[8] : 3
IPIPE[c] : e4
IPIPE[10] : 1
IPIPE[14] : 4af
IPIPE[18] : 0
IPIPE[1c] : 63f
IPIPE[20] : 0
IPIPE[24] : 0
IPIPE[28] : 1
IPIPE[2c] : e
IPIPE[30] : 0
IPIPE[34] : 0
IPIPE[38] : 0
IPIPE[3c] : 0
IPIPE[40] : 0
IPIPE[44] : 0
IPIPE[48] : 0
IPIPE[4c] : 0
IPIPE[50] : 0
IPIPE[54] : 0
IPIPE[58] : 0
IPIPE[5c] : 0
IPIPE[60] : 0
IPIPE[64] : 0
IPIPE[68] : 0
IPIPE[6c] : 0
IPIPE[70] : 0
IPIPE[74] : 0
IPIPE[78] : 0
IPIPE[7c] : 0
IPIPE[80] : 0
IPIPE[84] : 0
IPIPE[88] : 0
IPIPE[8c] : 0
IPIPE[90] : 0
IPIPE[94] : 0
IPIPE[98] : 0
IPIPE[9c] : 0
IPIPE[a0] : 0
IPIPE[a4] : 0
IPIPE[a8] : 0
IPIPE[ac] : 0
IPIPE[b0] : 0
IPIPE[b4] : 0
IPIPE[b8] : 0
IPIPE[bc] : 0
IPIPE[c0] : 0
IPIPE[c4] : 0
IPIPE[c8] : 0
IPIPE[cc] : 0
IPIPE[d0] : 0
IPIPE[d4] : 0
IPIPE[d8] : 0
IPIPE[dc] : 0
IPIPE[e0] : 0
IPIPE[e4] : 0
IPIPE[e8] : 0
IPIPE[ec] : 0
IPIPE[f0] : 0
IPIPE[f4] : 0
IPIPE[f8] : 0
IPIPE[fc] : 0
IPIPE[100] : 0
IPIPE[104] : 0
IPIPE[108] : 0
IPIPE[10c] : 0
IPIPE[110] : 0
IPIPE[114] : 0
IPIPE[118] : 0
IPIPE[11c] : 0
IPIPE[120] : 0
IPIPE[124] : 0
IPIPE[128] : 0
IPIPE[12c] : 0
IPIPE[130] : 0
IPIPE[134] : 0
IPIPE[138] : 0
IPIPE[13c] : 0
IPIPE[140] : 0
IPIPE[144] : 0
IPIPE[148] : 0
IPIPE[14c] : 0
IPIPE[150] : 0
IPIPE[154] : 0
IPIPE[158] : 0
IPIPE[15c] : 0
IPIPE[160] : 0
IPIPE[164] : 0
IPIPE[168] : 0
IPIPE[16c] : 0
IPIPE[170] : 0
IPIPE[174] : 0
IPIPE[178] : 0
IPIPE[17c] : 0
IPIPE[180] : 0
IPIPE[184] : 0
IPIPE[188] : 0
IPIPE[18c] : 0
IPIPE[190] : 0
IPIPE[194] : 0
IPIPE[198] : 0
IPIPE[19c] : 0
IPIPE[1a0] : 0
IPIPE[1a4] : 0
IPIPE[1a8] : 0
IPIPE[1ac] : 0
IPIPE[1b0] : 0
IPIPE[1b4] : 0
IPIPE[1b8] : 0
IPIPE[1bc] : 0
IPIPE[1c0] : 0
IPIPE[1c4] : 0
IPIPE[1c8] : 0
IPIPE[1cc] : 0
IPIPE[1d0] : 0
IPIPE[1d4] : 0
IPIPE[1d8] : 0
IPIPE[1dc] : 0
IPIPE[1e0] : 400
IPIPE[1e4] : 400
IPIPE[1e8] : 400
IPIPE[1ec] : 400
IPIPE[1f0] : 0
IPIPE[1f4] : 0
IPIPE[1f8] : 0
IPIPE[1fc] : 0
IPIPE[200] : 0
IPIPE[204] : 0
IPIPE[208] : 0
IPIPE[20c] : 0
IPIPE[210] : 0
IPIPE[214] : 0
IPIPE[218] : 0
IPIPE[21c] : 0
IPIPE[220] : 0
IPIPE[224] : 0
IPIPE[228] : 0
IPIPE[22c] : 100
IPIPE[230] : 0
IPIPE[234] : 0
IPIPE[238] : 0
IPIPE[23c] : 100
IPIPE[240] : 0
IPIPE[244] : 0
IPIPE[248] : 0
IPIPE[24c] : 100
IPIPE[250] : 0
IPIPE[254] : 0
IPIPE[258] : 0
IPIPE[25c] : 10
IPIPE[260] : 100
IPIPE[264] : 0
IPIPE[268] : 0
IPIPE[26c] : 0
IPIPE[270] : 100
IPIPE[274] : 0
IPIPE[278] : 0
IPIPE[27c] : 0
IPIPE[280] : 100
IPIPE[284] : 0
IPIPE[288] : 0
IPIPE[28c] : 0
IPIPE[290] : 0
IPIPE[294] : 10
IPIPE[298] : 4d
IPIPE[29c] : 96
IPIPE[2a0] : 1d
IPIPE[2a4] : fd5
IPIPE[2a8] : fab
IPIPE[2ac] : 80
IPIPE[2b0] : 80
IPIPE[2b4] : f95
IPIPE[2b8] : feb
IPIPE[2bc] : 0
IPIPE[2c0] : 80
IPIPE[2c4] : 80
IPIPE[2c8] : 0
IPIPE[2cc] : 0
IPIPE[2d0] : 0
IPIPE[2d4] : 0
IPIPE[2d8] : 0
IPIPE[2dc] : 0
IPIPE[2e0] : 0
IPIPE[2e4] : 0
IPIPE[2e8] : 0
IPIPE[2ec] : 0
IPIPE[2f0] : 0
IPIPE[2f4] : 0
IPIPE[2f8] : 0
IPIPE[2fc] : 0
IPIPE[300] : 0
IPIPE[304] : 0
IPIPE[308] : 0
IPIPE[30c] : 0
IPIPE[310] : 0
IPIPE[314] : 0
IPIPE[318] : 0
IPIPE[31c] : 0
IPIPE[320] : 1
IPIPE[324] : ff
IPIPE[328] : 0
IPIPE[32c] : 0
IPIPE[330] : 0
IPIPE[334] : 0
IPIPE[338] : 0
IPIPE[33c] : 0
IPIPE[340] : 0
IPIPE[344] : 0
IPIPE[348] : 0
IPIPE[34c] : 0
IPIPE[350] : 0
IPIPE[354] : 0
IPIPE[358] : 0
IPIPE[35c] : 0
IPIPE[360] : 0
IPIPE[364] : 0
IPIPE[368] : 0
IPIPE[36c] : 0
IPIPE[370] : 0
IPIPE[374] : 0
IPIPE[378] : 0
IPIPE[37c] : 0
IPIPE[380] : 0
IPIPE[384] : 0
IPIPE[388] : 0
IPIPE[38c] : 0
IPIPE[390] : 0
IPIPE[394] : 0
IPIPE[398] : 0
IPIPE[39c] : 0
IPIPE[3a0] : 0
IPIPE[3a4] : 0
IPIPE[3a8] : 0
IPIPE[3ac] : 0
IPIPE[3b0] : 1
IPIPE[3b4] : 0
IPIPE[3b8] : 1
IPIPE[3bc] : 0
IPIPE[3c0] : 1
IPIPE[3c4] : 0
IPIPE[3c8] : 1
IPIPE[3cc] : 0
IPIPE[3d0] : 1
IPIPE[3d4] : 0
IPIPE[3d8] : 1
IPIPE[3dc] : 0
IPIPE[3e0] : 1
IPIPE[3e4] : 0
IPIPE[3e8] : 1
IPIPE[3ec] : 0
IPIPE[3f0] : 0
IPIPE[3f4] : 0
IPIPE[3f8] : 0
Resizer Registers
**************************************************
RSZ_SRC_EN = 0x1
RSZ_SRC_MODE = 0x0
RSZ_SRC_FMT0 = 0x0
RSZ_SRC_FMT1 = 0x0
RSZ_SRC_VPS = 0x0
RSZ_SRC_VSZ = 0x4af
RSZ_SRC_HPS = 0x0
RSZ_SRC_HSZ = 0x63f
RSZ_DMA_RZA = 0x0
RSZ_DMA_RZB = 0x0
RSZ_DMA_STA = 0x0
RSZ_GCK_MMR = 0x1
RSZ_GCK_SDR = 0x1
RSZ_IRQ_RZA = 0x1fff
RSZ_IRQ_RZB = 0x1fff
RSZ_YUV_Y_MIN = 0x0
RSZ_YUV_Y_MAX = 0xff
RSZ_YUV_C_MIN = 0x0
RSZ_YUV_C_MAX = 0xff
RSZ_YUV_PHS = 0x0
RSZ_SEQ = 0x0
RSZ A EN = 0x1
RSZ A MODE = 0x0
RSZ A 420 = 0x3
RSZ A I_VPS = 0x0
RSZ A I_HPS = 0x0
RSZ A O_VSZ = 0x4af
RSZ A O_HSZ = 0x63f
RSZ A V_PHS_Y = 0x0
RSZ A V_PHS_C = 0x0
RSZ A V_DIF = 0x100
RSZ A V_TYP = 0x0
RSZ A V_LPF = 0x0
RSZ A H_PHS = 0x0
RSZ A H_PHS_ADJ = 0x0
RSZ A H_DIF = 0x100
RSZ A H_TYP = 0x0
RSZ A H_LPF = 0x0
RSZ A DWN_EN = 0x0
RSZ A DWN_AV = 0x0
RSZ A RGB_EN = 0x0
RSZ A RGB_TYP = 0x0
RSZ A RGB_BLD = 0x0
RSZ A SDR_Y_BAD_H = 0x8499
RSZ A SDR_Y_BAD_L = 0xe000
RSZ A SDR_Y_SAD_H = 0x8499
RSZ A SDR_Y_SAD_L = 0xe000
RSZ A SDR_Y_OFT = 0x640
RSZ A SDR_Y_Y_PTR_S = 0x0
RSZ A SDR_Y_PTR_E = 0x4b0
RSZ A SDR_C_BAD_H = 0x84b7
RSZ A SDR_C_BAD_L = 0x2c00
RSZ A SDR_C_SAD_H = 0x84b7
RSZ A SDR_C_SAD_L = 0x2c00
RSZ A SDR_C_OFT = 0x640
RSZ A SDR_C_PTR_S = 0x0
RSZ A SDR_C_PTR_E = 0x258
RSZ B EN = 0x1
RSZ B MODE = 0x0
RSZ B 420 = 0x0
RSZ B I_VPS = 0x0
RSZ B I_HPS = 0x0
RSZ B O_VSZ = 0xef
RSZ B O_HSZ = 0x13f
RSZ B V_PHS_Y = 0x0
RSZ B V_PHS_C = 0x0
RSZ B V_DIF = 0x500
RSZ B V_TYP = 0x0
RSZ B V_LPF = 0x0
RSZ B H_PHS = 0x0
RSZ B H_PHS_ADJ = 0x0
RSZ B H_DIF = 0x500
RSZ B H_TYP = 0x0
RSZ B H_LPF = 0x0
RSZ B DWN_EN = 0x0
RSZ B DWN_AV = 0x0
RSZ B RGB_EN = 0x0
RSZ B RGB_TYP = 0x0
RSZ B RGB_BLD = 0x0
RSZ B SDR_Y_BAD_H = 0x84d4
RSZ B SDR_Y_BAD_L = 0x7800
RSZ B SDR_Y_SAD_H = 0x84d4
RSZ B SDR_Y_SAD_L = 0x7800
RSZ B SDR_Y_OFT = 0x280
RSZ B SDR_Y_Y_PTR_S = 0x0
RSZ B SDR_Y_PTR_E = 0xf0
RSZ b SDR_C_BAD_H = 0x0
RSZ B SDR_C_BAD_L = 0x0
RSZ B SDR_C_SAD_H = 0x0
RSZ B SDR_C_SAD_L = 0x0
RSZ B SDR_C_OFT = 0x0
RSZ B SDR_C_PTR_S = 0x0
RSZ B SDR_C_PTR_E = 0x78

--- CCDC registry dump ---
SYNCEN = 0x0001
MODESET = 0x2000
HDW = 0x0000
VDW = 0x0000
PPLN = 0x0000
LPFR = 0x0000
SPH = 0x0000
LNH = 0x0c7f
SLV0 = 0x0001
SLV1 = 0x0001
LNV = 0x04af
CULH = 0xffff
CULV = 0x00ff
HSIZE = 0x0064
SDOFST = 0x0000
CADU = 0x0000
CADL = 0x0000
LINCFG0 = 0x0000
LINCFG1 = 0x0000
CCOLP = 0x0000
CRGAIN = 0x0200
CGRGAIN = 0x0200
CGBGAIN = 0x0200
CBGAIN = 0x0200
COFSTA = 0x0000
FLSHCFG0 = 0x0000
FLSHCFG1 = 0x0000
FLSHCFG2 = 0x0000
VDINT0 = 0x04af
VDINT1 = 0x0259
VDINT2 = 0x0000
MISC = 0x0000
CGAMMAWD = 0x0000
REC656IF = 0x0000
CCDCFG = 0x0802
DFCCTL = 0x0000
VDFSATLV = 0x0000
DFCMEMCTL = 0x0000
DFCMEM0 = 0x0000
DFCMEM1 = 0x0000
DFCMEM2 = 0x0000
DFCMEM3 = 0x0000
DFCMEM4 = 0x0000
CLAMPCFG = 0x0000
CLDCOFST = 0x0000
CLSV = 0x0000
CLHWIN0 = 0x0000
CLHWIN1 = 0x0000
CLHWIN2 = 0x0000
CLVRV = 0x0000
CLVWIN0 = 0x0000
CLVWIN1 = 0x0000
CLVWIN2 = 0x0000
CLVWIN3 = 0x0000
DATAHOFST = 0x0000
DATAVOFST = 0x0000
LSCHVAL = 0x0000
LSCVVAL = 0x0000
TWODLSCCFG = 0x0000
TWODLSCOFST = 0x0000
TWODLSCINI = 0x0000
TWODLSCGRBU = 0x0000
TWODLSCGRBL = 0x0000
TWODLSCGROF = 0x0000
TWODLSCORBU = 0x0000
TWODLSCORBL = 0x0000
TWODLSCOROF = 0x0000
TWODLSCIRQEN = 0x0000
TWODLSCIRQST = 0x0000
FMTCFG = 0x0000
FMTPLEN = 0x0000
FMTSPH = 0x0000
FMTLNH = 0x0000
FMTSLV = 0x0000
FMTLNV = 0x0000
FMTRLEN = 0x0000
FMTHCNT = 0x0000
FMTAPTR_BASE = 0x0000
FMTPGMVF0 = 0x0000
FMTPGMVF1 = 0x0000
FMTPGMAPU0 = 0x0000
FMTPGMAPU1 = 0x0000
FMTPGMAPS0 = 0x0000
FMTPGMAPS1 = 0x0000
FMTPGMAPS2 = 0x0000
FMTPGMAPS3 = 0x0000
FMTPGMAPS4 = 0x0000
FMTPGMAPS5 = 0x0000
FMTPGMAPS6 = 0x0000
FMTPGMAPS7 = 0x0000
CSCCTL = 0x0000
CSCM0 = 0x0000
CSCM1 = 0x0000
CSCM2 = 0x0000
CSCM3 = 0x0000
CSCM4 = 0x0000
CSCM5 = 0x0000
CSCM6 = 0x0000
CSCM7 = 0x0000
OBWIN0 = 0x0000
OBWIN1 = 0x0000
OBWIN2 = 0x0000
OBWIN3 = 0x0000
OBVAL0 = 0x0000
OBVAL1 = 0x0000
OBVAL2 = 0x0000
OBVAL3 = 0x0000
OBVAL4 = 0x0000
OBVAL5 = 0x0000
OBVAL6 = 0x0000
OBVAL7 = 0x0000
CLKCTL = 0x0000

Jan,

Can you try the following?

1. Setting the value IPIPE CFG2 to 0x4C instead of current 0x48? 

2. Setting the value MODESET to 0x2004 instead of current 0x2000? 

I believe the issue is with the polarity of VD signals. If this solves the issue do remember to check the HDPOL field of these registers, as I think that is also wrong. You might be capturing a left side clipped frame. 

Hi Renjith,

I have tried your advice with VDPOL but with no luck. From the scope screens you can see that the polarity of both is positive.

Renjith Thomas said:

I believe the issue is with the polarity of VD signals. If this solves the issue do remember to check the HDPOL field of these registers, as I think that is also wrong. You might be capturing a left side clipped frame.

Changing the HDPOL in IPIPE CFG2 to negative causes the left side clipped frame, so I'm pretty sure that my original setting is correct.

regards
Jan

Jan,

When you change VDPOL in both registers, do you see any difference in the waveform? If possible can you share the waveform?

Hi,

I have next remark about VDPOL and HDPOL. When they are set to same value in IPIPE CFG2 and MODESET the captured frame looks ok (no cropping etc.) with no regard to selected value (negative/positive). However it has no effect to the problem with buffer rewriting.

The only solution so far is the described 50us delay in the interrupt. But why to stay there longer then it is really needed...

regards
Jan

Renjith Thomas said:

When you change VDPOL in both registers, do you see any difference in the waveform? If possible can you share the waveform?

 There is no difference

Resizer dma interrupt is still fired after the start of next VSYNC pulse.

I can also change the polarity of sync signals directly on the sensor, but I don't believe it will make any difference.

regards
Jan

Hi,

after next digging around I have found this line in vpss.c

isp5_write((isp5_read(0x14) | 0x1f0a0f1f), 0x14);

The second LSB of this register (INTSEL) sets the source of VPSSINT5, which is actually the channel triggering vpfe_imp_dma_isr() routine that we are interested in.

Surprisingly the value 0x0f is marked as reserved in the description of INTSEL. I have tried to change the value to 0x16 (22) RSZ_INT_EOF0 (is this correct?) but again it has no effect on buffer rewriting :(

 best regards
Jan

Jan,

Have you tried changing the polarity of the VSYNC signals from the sensor? Just try this, as I'm believing that some how the interrupt is triggered when VSYNC is over, which should have happened in the beginning of VSYNC pulse. 

Hi Renjith,

I have checked it now, but unfortunately sensor does not have this possibility. VSYNC signal is called LINE_VALID and goes high when the frame data is fed to the output pins and goes low during vertical blanking period. According to this I assume that setting VDPOL to positive should be correct.

regards
Jan

Hi Renjith,

I have tried another method to make things working, but no luck. My idea to increase interrupt priority was wrong.

regards
Jan

Jan,

Glad that its fixed!