This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISP parallel input: interrupt is generated but no data in the buffer sometimes

Other Parts Discussed in Thread: DM3730

Hi,

We are working of camera driver on DM3730 using Android 2.3.4. The camera is ov5640. The camera is connected using CCDC input parallel.

A set of buffers are used as queue for data from camera (queue size  4). The address to buffer is passed using register CCDC_SDR_ADDR. ISP writes in this buffer & updates the completion using the ISR interrupt call. But sometimes, it returns success without updating the buffer. That is, sometimes there is no data written to the buffer, while an interrupt is generated by the ISP. We checked all the registers & found the register settings to be correct. We don't receive any error interrupt from the ISP.
 

 

Frames Written

F0

F1

F2

F3

F4

F1(Error)

F6

F7

F4(Error)

F9

F10

F10

 
Due to this error in writing to the buffer, the camera preview & recording receives frame F0,F1,F2,F3,F4,F1,F6,F7,F4,F9,F10,F11 instead of F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11.
Could someone suggest what could be wrong, and how to solve this. 
Best Regards.
  • Hi Garima,

    Would you specify which kernel version you are using and are your Android sources some TI's or some other. This info will be useful for analyzing the problem.

    According the description of the problem it seems that there is some delay during computing the frame which is bigger then time between frames. You could check time stamps of the frames are they correct?

    BR

    Tsvetolin Shulev

  • Hi Cvetolin,

    We are using kernel version 2.6.37, Android version 2.3.4. The kernel is from TI. 

    The chip is DM3730 1GHz.

    The frame size for capture is 640x480.

    But How do we can see the time stamp of a frame? Could you please explain?

    BR.

  • Garima,

    I'm not an ISP expert, the info might not be accurate. When you see F1(error) can you check the frame F4? Is it getting updated? I feel that there is some delay in the interrupt handler, where you are not changing the next buffer's base address immediately. If at all it starts with the next frame buffer write before changing the base address, it will take the new frame only after next VSYNC. 

    Alternatively, you can try increasing the VSYNC duration in the camera I2C registers and see any difference is there in the behavior? Also please do check that your VSYNC interrupt handler is minimal. 

    Also what is the pixel clock at which you are receiving data?

  • Thanks Renjith.

    We can not access frame F4 if the error occurs in F1 so we can not see if frame F4 was updated instead of F1.

    Strangely, the timestamp difference between the two consecutive frames is about 60-70 ms (~15 FPS), even though we had set it to be 30 FPS. So the timestamp goes something like this.

    60, 120, 180, 240, 60 (ERROR), 360...

    This means that the data in the frame buffer has not been updated, and it is showing the previous data.

    Even when we tried using lower FPS, the problem still existed, though the frequence of such occurance was lower for lower FPS capture.

    The pixel clock is generated by the ov5640 camera. The ov5640 document says that pixel clock for VGA 30 FPS (which we are setting) will be 48/96 MHz. 

    BR.

  • Garima,

    Are you de-allocating/freeing F4 because of which you are not able to access it? Even if you are freeing it, it might not really matter as ISP will be using the physical address. So, you can just try to save the F4 buffer pointer and try to access it instead of F1 and see whether it has valid data. 

    Regarding the time stamp, it is very obvious as data is not updated.

    I feel that your pixel clock rate is too high for a VGA 30fps capture. It should be around 24MHz. So, could you try measuring the current pixel clock using an oscilloscope or can you reduce the pixel clock to 24MHz and see whether any change in behavior occurs.

  • Garima,

    Is this issue solved? Perhaps, you might want to take a look at the solved post, where similar issue was there.

    http://e2e.ti.com/support/embedded/linux/f/354/t/223215.aspx?pi68664=1

  • Hi Renjith,

    Thanks for your efforts and the willingness to help.

    In our case, VD0 is set to last line of the image, and VD1 is set to 2/3 of the image height. When we disable the VD1 interrupt, the above problem gets resolved. We are exploring more into it why VD1 interrupt should cause a problem.

    Thanks once again for your help.

    BR.