Video frame shifting on DM648 EVM

Unfortunately I believe with the video ports on the DM648 there is not a reliable mechanism to capture all disconnect/reconnect events, so there is a potential for this sort of shifting before the EDMA and the video port are synchronized with each other again.

 From what I have seen on previous devices with similar video ports (DM642) the only way to get a more reliable disconnect/reconnect event is to have the video encoder you are getting the video from send you a event over a GPIO line that drives an interrupt.

 Okay, thanks for the information

 One more question: We have never seen this issue on the DM642 EVM.  Does that hardware have the GPIO connection you mention?

The EVM does not unfortunately, the more recent driver for the DM642 video ports checks for over run events every frame and will reset the DMAs if it finds one, and that covers most cases of this phenomenon. It is not seen very often, the probability of seeing it is relatively low, you might have to disconnect and reconnect the video 100 times or more before you see it, and when you do see it doing another disconnect/reconnect will almost always clear the condition. Because it does not happen very often, and only when you are disconnecting and reconnecting video sources all the time, it was not seen by most customers, and if it was most would think it a fluke and when they disconnect/reconnect again it is gone.

 Okay, that makes sense as far as why we never saw the issue with the DM642.  

 I tried checking for overrun events in the driver using VPORT_IntCallBack on the DM648 EVM, but I never saw any events.  Is this functionality working for the DM648?  (I am trying to figure out if I might have done something wrong in my ISR implementation.)

I would imagine that the interrupts are functional with the DM648 driver, however I have not had a chance to look closely at them (I work more with the other Davinci devices). You could prove if they were working or not by examining the VPIS (video port interrupt status) register to see if any of the error bits are getting set, in a test environment you could poll on these in your code to see if/when the events actually take place. If the appropriate bits are set and you see no interrupt than there is a configuration problem of some sort, if the bits are never set than the hardware is never detecting one of the error conditions. The bits are discussed in section 2.4.4 of the video port manual SPRUEM1 below.

http://focus.ti.com/lit/ug/spruem1/spruem1.pdf

The error bits are not getting set on plugging video cable back. Any thoughts on why these error bits don't get set? Any configuration is required prior to expect this error bits  ??

An overrun condition does not always occour when you disconnect and reconnect the video, it depends at the point in the frame that the video source is disconnected and reconnected. For example if you disconnect and reconnect during blanking intervals there should be no problems and you would not see any events, whereas disconnecting and reconnecting in the midst of the frame can trigger an overrun condition that the DM648 video port can detect. This is why it can take several attempts before this type of issue is seen, the timing of the disconnect/reconnect relative to what point in the frame you are introduces a random looking element.

 The detection of these events should always be on with the DM648 video ports (i.e. the bits should set), however it only fires an interrupt if that has been setup. Do note that at least with the DM648 video ports that the overrun indicator will not catch all connect disconnect events that do put the EDMA out of sync, but it should catch the vast majority of them.

So it turns out I could get interrupts when I used the vpfe handle instead of the vpbe handle to hook in the ISR to the video driver.  Cut and paste errors strike again!

I also found the reason why polling the VPIS register wasn't working for us.  If you assign a bit to fire the ISR, you can't rely on it to be set if you try to poll it from anywhere but the ISR.  So I stopped hooking in the ISR.  By not using the ISR, I am able to poll the VPIS for errors in the video port.

 Once I our VPIS polling working, I found that I would see the "short frame detected" bit go to 1 whenever the video input got stuck looking distorted.  When I see that flag I simply stop and start the driver using FVID_control() and the EDMA and everything seem to line up, making my picture look nice again.

 Thanks for all the help!

 One weird thing - when I set my "short frame detected" to one in the VPIS to clear it, then read the VPIS back again, the VPIS had been totally cleared.  My understanding is that only the one bit should be cleared, not all of them (before clearing it, two other bits were also 1).  Did I do something wrong?

Chris,

Which version of PSP drivers are you using?

There was a similar bug in earlier versions of PSP drivers.

In the latest PSP drivers, by default "short field detected" error is handled internally.

The application don't have to do anything thing to handle this scenario.

The driver will detect the error and reconfigure the EDMA parameters so that the picture becomes normal after plug-in/out of cable.

If the application registers a call back, then the driver will intimate the application when such errors occur through the callback,

though the application don't have to do anything special (like stop and restart driver - everything is done by the driver for you)!!

Regards,

Sivaraj R

  We are using pspdrivers_1_10_00_09, which came with dvsdk_1_10_00_26_DM648.  Is there a newer version?  I haven't seen one on the DM648 update site.

Chris,

1_10_00_09 is the latest PSP release and the short-field detected error is handled internally (with bug fixes for clearing the status). 

I suggest you to use the driver's callback function for your case.

How are you clearing the status bits in your application code? Are you accessing the register directly from application?

Remember that the driver will also clear this status register. So you might see unexpected results due to race condition!!

Regards,

Sivaraj R

 We are accessing the register in our application in order to read and clear the bits, though to tell the truth I never really felt comfortable with this.  I will switch to the callback function for handling the error.

 Can you tell me more about when/how the driver clears the status register?  If I use the ISR callback, do I need to worry about clearing the register?

 As far as the fix, we definitely still see an issue with that version, but it is pretty specific.  It happens when we switch between the cables for two feeds (i.e. not just plugging/unplugging).  We sometimes see the frame has a vertical shift, and this shift will last anywhere from 1 to about 30 seconds before the driver recovers.  However, in my testing I see the short frame error every time the image gets shifted.  So the best thing for me to do is to stop and restart the driver, so that I don't have to wait for the driver to recover on its own.

Have you enabled the auto-sync option in the capture driver?

If this is not done, then you will see similar issue while plug-in/plug-out of cable.

Auto-Sync can be enabled by setting the "autoSyncEnable" member of "VPORTCAP_Params" to TRUE.

To enable callback, use the "VPORT_CMD_SET_VINTCB" IOCTL with VPORT_VIntCbParams as argument.

Make sure that you set the "vIntMask" member to VPORT_INT_SFD.

When the driver detects a SFD error, it will call the application registered callback function (before clearing the VPORT status register) and when the call returns the driver clears the status register.

So if you poll the VPORT status register from the callback context, you will still see the bits set but you don't have to clear it from the application!!

 Thank you for the information regarding the VPORT status register.

 We are setting the auto-sync option to TRUE in the capture driver.

Do you still see shifting in video when you change the input?

What type of input are you changing - NTSC/PAL?

When you change the input, do the standard change from NTSC to PAL or vice versa?

 We have had auto-sync enabled from the start.  We still see the shifting in the video.

We are capturing NTSC.  The standard stays the same when we change the input.

In your earlier communication you have mentioned that video shift occurs only if you change the input and that shifting doesn't occur when the same input is plugged in again.

Is my understanding right?

 I am pretty sure this is the case. I didn't see the issue when I unplug/plug the same source.

It seems to me that the sync signals for the two sources would have a slight offset, which might confuse the driver a little.

Very strange!!

Is it possible to read TVP5154 registers during video shifting (using external I2C bus?) and check whether the signal is locked on by the decoder or not?

Meanwhile I will try to reproduce this error at my end.

Do you see a vertical shift or a horizontal shift?

 I think you should be able to reproduce just using the driver loopback example.  

 The shift is only vertical.  Sometimes it lasts a split-second, sometimes it lasts 20-30 seconds.  Usually it doesn't happen at all, though.

 If I get a chance, I will try to take a look at the TVP5154 registers, but the stop/start workaround is good for us for now.

Chris

I want to write some bytes of data on NOR Flash of  DM648EVM but is unable to do so, this post of yours tells me that you already had done so in order to perform your functions. Can you help me with code snippet or any example or link reference?

Plz note that I want a solution other than UBL or Flashburn utility

Regards

Mark

Hi Sivaraj,

We meet the same issue on DM642 now.

Does DM648 pspdriver method can apply to DM642?

Or we really need to  check video ports  for over run events every frame like Bernie mentioned?