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 does not synchronize on subsequent frames when missing beginning of VS of the first frame

Other Parts Discussed in Thread: DS92LV2421, DM3730

Hi

I'm working with AM/DM3730 on a CompuLab SOM, running Linux 3.0 and a camera connected to the parallel interface. Because the camera is 'far away' from the mainboard, the data is converted to a serial data stream and transmitted to the mainboard on a cable. On the mainboard the data is being deserialized. ds92lv2421 acts as serializer/deserializer. The pixelclock is being used to clock this system. The pixelclock is only running when the camera is in streaming mode (pixelclock starts an integration time before first rising edge of VS). Usually the system can capture images successfully.

My problem: If on the mainboard the deserializer locks after the camera started sending data (activity on VS, HS, ... before the deserializer actually starts working), what can happen when the integration time is very low or the serdes-system takes longer to lock, the ISP gets out of sync and won't be able to get back into sync on subsequent frames resp. next rising edge of VS. Out of sync means, that the image data is corrupt (wrong colors, received image starts in the middle of the sensor image).

The V4L2 framework is used to control the ISP and the camera.

Why would the ISP not get back in sync on the next rising edge of VS? Does anyone have an idea if this can be solved in firmware?

BR,

Michael

  • Michael,

    Ideally ISS should synchronize on next VS. Is this happening every time or once in a while? An immediate work around that you can try is that, to delay enabling ISS so that it starts only after the syncs are locked and stable. 

  • Hi Renjith

    Thanks for you advice. If I enable the ISP only after the serdes system reached lock state the problem can be resolved.

    It only happened once in a while that it took longer for the deserializer to reach lock and the camera would start sending data before that happened. But when that occurred, the image (written to memory by the resizer) would always be faulty. This could only be cured by resetting the ISP. However, when under the same circumstances taking the output from CCDC in raw format, image data would be ok.

    Thanks,

    Michael

  • Hi Michael,

    Thanks for the update. So does this mean that the issue is completely resolved?