PTN3460I Sometimes fails to get sync right?

cancel
Showing results for 
Search instead for 
Did you mean: 

PTN3460I Sometimes fails to get sync right?

792 Views
borisyost
Contributor II

PTN3460I hard-wired connected to an AMD GPU with 2-lane DisplayPort, resolution 720p.  About 97% of the time, it works fine.  ~3% of trials, something really weird happens.  It appears the video data is there, and shows up at the right time, but the clock and syncs are too slow and just stuffed over the top of the video data.  The clock goes faster and faster...slowly...until it gets to the speed it is supposed to be (pixel clock is 74.25 MHz for this resolution, and we are using the double-wide bus so half of that) and then it all works.  When it works, it is correct and stable indefinitely for as long as we have cared to watch.  The slow speeding up process can take 20 minutes.

Anybody seen anything like this?

Tags (2)
0 Kudos
9 Replies

432 Views
GordyCarlson
NXP Employee
NXP Employee

Some additional data from the customer noted within this paragraph from one of their recent emails...

-------------------------------------------------------------------------------------------------------------------------

Experiment/problem description:

  • Video timing is 720p, which is 74.25 MHz pixel clock.  The LVDS bus is double-wide so the LVDS clock should be 37.125 MHz.
  • Data pattern is horizontal black/white lines.  Therefore, on a data pair, there should be a uniform square wave in the visible region and a flat line in the blanking region.
  • Probing an LVDS data pair using a differential probe near the DP converter.

Result:

  • 97% of the time, it works. 
  • ~3% of the time, it doesn’t work.  The failure is at startup.  Our system screws up because there is no Vsync present.  On closer examination, it appears that the data is present at approximately the right time with the correct data.  However, the clock is going too slow and the timing is all over the place. See attached data.
  • It goes faster and faster until it gets to the speed it is supposed to be at, and then it starts working.  This process sometimes takes 20 min.
  • Once a channel is working, it continues to work indefinitely.
  • Our usual resolution is 720p.  We have also tested the system at VGA, XGA, SXGA.  It also fails in a similar manner at XGA and SXGA.  It never fails at VGA (200 trials).

-----------------------------------------------------------------------------------------

I have alerted the product group apps mgr/team to this thread and asked their attention....

To my knowledge, NXP does not have a demo/reference board for this device, so customer has purchased a third party Versalogic (VL-EPH-V6) video converter board to examine and compare with their circuit.

http://versalogic.com/products/DS.asp?ProductID=253

http://www.digikey.com/product-search/en?keywords=1241-1303-ND%20

We could also benefit from any product group comments on various firmware versions used with the PTN3460.

-Gordy

0 Kudos

432 Views
reyes
NXP TechSupport
NXP TechSupport

Hi,

Versalogic board sold in Digikey is a mini-DP to LVDS board using PTN3460, similar to PTN3460 demo board OM11064, PTN3460I demo board OM13561, only simplified.

Does customer have similar issue using Versalogic board?

Please provide customer’s application, test setup and design block diagram to study.

You can send it this via (open community) or via Sales Force Case (private question), customer have already am open case about this issue (Case#00084496).

Regards,

Jose

0 Kudos

432 Views
GordyCarlson
NXP Employee
NXP Employee

Boris,

    Can you provide the info that Jose requests?  If it needs to go privately, please provide it to Eric Eckenrode/Avnet DFAE, who can attach it to his service request Case noted above.

-Gordy

ericeckenrode

0 Kudos

432 Views
borisyost
Contributor II

Vsync (or lack thereof):

     We have been analyzing this by two methods.  The LVDS output of this thing is going to an FPGA, and the "failure" is that the FPGA fails to find the Vsync bit, both by failing to pass a Vsync from the LVDS deserializing block to other blocks, and because we have a Vsync counter/timer and it is getting either nothing or garbage.  The other method is that we are feeding it deliberately engineered video content (based on looking at the bit positions on the LVDS lanes) so that you can easily "decode" stuff with an oscilloscope by eye, and/or use fancy triggering functions like pulse-width to find the Vsync.

     It's not there. In addition, the problem is not merely the presence/absence of Vsync, it's the slow-clock and the video timing that is not correlated with the video data.  The same data sent to a DE-only panel would be a total mess also.

"EDID" issues and system block diagram:

    Well, as mentioned above, there is no panel.  It's going to an FPGA.  The GPU/processor is using an RTOS with a driver written by a specialty software house.  The driver does not use EDID, nor does it ask for it.

Fun with Versalogic:

     It's on the list of things to do.  One issue is that we are working with an integrated system with stuff soldered down to the board.  I have a science project in my head for how to cob in mini-DP connectors to our system so that we can use the Versalogic board with our real system.  I have to deal with issues such as unfortunately HPD was implemented with a blind via on a 2-point net.

      We have used the Versalogic board with an AMD GPU reference card which has actual connectors and a PCIe plug-in card form factor.  Didn't fail, but at the time we didn't have good failure statistics so I didn't really try it enough times to be sure that it never fails.

0 Kudos

432 Views
reyes
NXP TechSupport
NXP TechSupport

Hi Boris,

The problem you described seems to be similar to some particular application, LVDS to VGA conversion, that PTN3460 is not designed for.

PTN3460 is designed to drive LVDS panel directly, it is not suitable to drive another device to convert to different video format, due to there is no external crystal for the LVDS clock, FW cannot get rid of the LVDS clock jitter.

PTN3460 was designed with low cost in mind, it does not have crystal input pins. Hence it has a disadvantage that a LVDS to VGA converter cannot be connected to PTN3460 due to the very tight long-term jitter requirement of VGA displays and other displays that use HSync for clock reference input.

PTN3460 does not have a osc_out pin, hence it cannot drive and external crystal as it is now.

In order to support external crystal, PTN3460 needs to go through major changes:

1.HW new bond-out changes, new part number

Change pin 56 EPS to OSC_OUT, pin 55 to OSC_IN

FW changes to support external crystal

The new device can only either support single- OR only dual-supply mode, but not dual mode.

2. FW workaround

Use pin 55 as OSC_IN to accept external clock input (not crystal), if the system has 25/27/33 MHz clocks exist

Major FW changes to support external clock input

I apologize for the problems this may cause.


Have a great day,
Jose

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

432 Views
borisyost
Contributor II

Jose:

     I see you have heard about our other problem with clock jitter, and we are interested in your proposed solution.

     This problem, however, is different.  The clock output, during a failing case, is not more or less stable than when it is working.  When it is failing, it's the wrong frequency, and the syncs are not lined up with the data.  The output would not work with a panel either; the frame length would be short.

Boris

0 Kudos

432 Views
GordyCarlson
NXP Employee
NXP Employee

Jose,

  The customer is using F1 rev firmware devices.  Per the internal discussion, we have recommended they try F2 firmware devices.  The Disty and NXP salespeople involved are ordering the samples for the customer.

  In the meantime, Boris has tried the Versalogic third party board and it works, here are his comments...

-------------------------------

Team:

I tried the Versalogic board with an AMD GPU reference design (not our board) with the “same” (same company, but not exactly the same because of system context) driver and RTOS.  Booted 200 trials with one test protocol, then 60 more trials with a slightly modified protocol.  Never fails.

One issue is unfortunately this is not the same firmware as what we have. I’ll see if I can get this thing hooked up to Windows and run the DPCD tool.  And then there is the science experiment of cutting in mini-DP connectors to our hard-wired system.

Boris

-----------------------------

He also noted that the PTN3460 version on the Versalogic board is marked.... PTN3460BS , S1K589 , 04,  ZSD1328.

The Versalogic board itself is marked   VL-EPH-V6SA Rev. 1.00, 754865 (that’s probably a SN)

  So our next steps will be trying the F2 rev firmware parts when he receives them.  He may also try modifying his target board and inserting the Versalogic board into the signal chain as an additional experiment.

  Jose, thanks again for your support. Will keep you posted on the progress.

Gordy

0 Kudos

432 Views
borisyost
Contributor II

We got a board reworked with F2 devices.  3 channels worked; one channel has some problem we haven't figured out yet and has never worked and does not fail like our usual failure; it is probably a problem with rework.  Of the 3 channels that work, we did 600 reps and have not yet observed a failure.

0 Kudos

432 Views
reyes
NXP TechSupport
NXP TechSupport

Hi,

One question, what do you mean “no Vsync present”? Is the “Vsync” in the LVDS data packing or any pin/connector?

LVDS panel normally supports DE only mode instead of Hsync/Vsync mode in the LVDS data packing, so that the Vsync is not used for the LCD panel.

Can you provide us the LCD panel specification (720p) and EDID for the panel to check?

Regards,

Jose Reyes

0 Kudos