CCDC Image Drifting

This seems like a vertical sync timing problem, it is very strange that the drift is not regular, if it is able to go both directions (up and down) seemingly at random than I would suspect that your CCD is somehow outputting varying line distances between vertical sync events, as I have never seen the VPFE vary its sync timings over time. The first place I would check is the vertical sync line, if you can put a scope on to see if anything seems out of place, like if there is any significant jitter, or it is not happening at the rate you expect.

Since you have a lot of other things going on in your system one possibility is that it may be outside of the capture sequence, such as if you are getting the offset somewhere else in software as you pass the frame to the resizer and off to the network. You should be able to rule this out by using a constant test image passed repeatedly through to the resizer and network, or by viewing the output from the previewer directly on the target (using JTAG or some other means of transfer). Doing this you should be able to better narrow down where the vertical drifting is coming in on the video pipeline, and from there the actual issue should be easier to find.

Thank you Bernie for your reply.

Some additional inputs based on your comments:

- I could observe that the drift is present right at the output of the previewer (I used the Image viewer tool provided by CCS with JTAG).
- The drift is always going down (bottom of the image appears at the top, more and more...)

One thing you said is interesting. You talk about the CCD outputting "varying line distances between vertical sync events". I am using a MT9M032 sensor which keeps the VD signal up during the whole image acquisition, and toggles the HD signal once for each row (up during the active rows, down during blanking). When you say varying line distances, are to talking about missing some HD high level events (hence the CCDC could be missing aleatory some rows every frames)?

Franck said:

- I could observe that the drift is present right at the output of the previewer (I used the Image viewer tool provided by CCS with JTAG).

If it is directly out of the previewer than that narrows things down quite a bit, since there is only one hardware step from the CCDC bus into memory, thus there must be something with the CCDC configuration, or the CCD itself.

Franck said:

One thing you said is interesting. You talk about the CCD outputting "varying line distances between vertical sync events". I am using a MT9M032 sensor which keeps the VD signal up during the whole image acquisition, and toggles the HD signal once for each row (up during the active rows, down during blanking). When you say varying line distances, are to talking about missing some HD high level events (hence the CCDC could be missing aleatory some rows every frames)?

On the DM6437 this would mean that the VSYNC edge is not aligned with the actual edge of the image, or is varying oddly, I imagine the CCD is outputting in a very periodic manner? If the VSYNC was misaligned than this could amount to missing HD events, but I don't believe this is a case of the CCDC simply not seeing HSYNCS, that would be very unusual since the sync connection is so simple and should be well driven, do the sync lines look clean on a scope?

On the other hand since your original post made it sound like this was an intermittent drift (good for a few seconds than drifting) that would make it seem like more of a hardware related issue, where noise could be impacting how the DM6437 perceives the syncs.

Your assumption of noisy syncs signal is probably right, because I am working with a temporary prototype board with a poor connection layout between the DM6437 and the image sensor. I have also been able to create drifting by moving the cable between the DM6437 and the image sensor. Thanks for your thoughts, that helped me to narrow my debugging.

We can certainly assume that the output of the CCD is correct (I checked signals at the scope directly at its output and everything is fine). I would have expected that the CCDC and Previewer would "reset" their internal state when they get a VD rising edge, no matter if the preceeding image capture has successfully completed or not. But it looks like it is not the case. If something wrong happens with a given capture, the CCDC/Previewer seem to remain indefinitely out of sync, even if good captures are now present at their input. Here are the observations that are making me think that way:

- If no drifting happens, if I put a breakpoint on the previewer EDMA completion interrupt call DDC_VPFEIsr(), I can see that both CCDC and Previewer PCR.Busy bits are at 0. Which is expected since the image acquisition has completed and both modules are waiting for the next frame.

- If drifting happened (image vertically shifted, but stable), a breakpoint at the same place shows that both modules are busy (bit set) when the interrupt is raised. I suspect that both modules are actually getting the next frame while the VPFE DMA "thinks" it is receiving the missing rows from the last frame. Do you think this makes some sense?

- Also, I tried for fun to cancel a frame acquisition by setting the Restart bit of the MT9M032 CCD in the middle of a given frame (this causes the current frame to be interrupted which also clears the FV signal, and start a new frame from the first row with a new FV sync signal). This results in an instantaneous vertical shifting in the output image which remains indefenitely present during the next frame acquisitions.

I know that this is exceptional conditions of use, but would you see a way to make sure that following a partially received frame, the whole thing gets back on track? Do you think a video module reset through the PSC would be the only way to restore things?

Thanks again

Franck said:

I would have expected that the CCDC and Previewer would "reset" their internal state when they get a VD rising edge, no matter if the preceeding image capture has successfully completed or not. But it looks like it is not the case.

I would agree mostly, I don't believe VD will truly reset the internal state (once it starts capturing lines I believe it ignores it), but after counting off all the lines you configured the VPFE for, it should wait until a new VD edge to begin capturing more lines synced with HD. What I suspect is that noise on your VD signal is sufficient enough that you are getting VD edges detected all the time (possibly every line) which would cause this effect. Or for an alternative theory...

My impression has always been that VD as an input is edge triggered, so even though your sensor is asserting it during the whole frame, it should only mean one event. There exists the possibility that it is level triggered (or edge triggered on the pixel clock). If you have the temporary hardware handy and easily modified, you could test this theory by removing the VD line from the sensor and triggering it manually by hand (or asserting it constantly with a pull resistor). Of course you would be out of sync almost every time statistically, but if you see the frames stop coming when disconnected, it proves that VD does something, and if they come constantly when the VD is asserted constantly than it would imply a level/clock edge trigger. This is something I could try to dig up internally, but it would take time so if you could test you would know sooner if this is your problem.

This is something that we do not really test for, since it is generally assumed that the connection between the video source and the display is solid and providing reliable periodic frames, and I would not see this much anyway as most customers I work with use BT.656 style video capture and display which uses embedded syncs (which do recover within a frame of desynchronization).

Franck said:

I know that this is exceptional conditions of use, but would you see a way to make sure that following a partially received frame, the whole thing gets back on track? Do you think a video module reset through the PSC would be the only way to restore things?

If the VD signal is triggered at the start of each frame only, it should recover itself by the next frame. If it was really stuck than a reset by the PSC would also recover things, but that is probably overkill, and since this condition is difficult to detect programatically, it may not be practical.

I finally could do the test you suggested. I constantly asserted VD and observed if frames were coming, and they were not. So that means a edge triggered signal as you initially expected...  Hopefully I should get the "real" mainboard soon so I should be able to confirm your theory that I might be getting VD edges detected all the time with my prototype board...

Thanks again for the support you provided,

Franck