SN75DP130: aux bus disconnected on some powercycles (DP source mode default register settings)

enginner is assigned for this issue, you will get reply soon.

Bart

Do you have a scope capture of the power cycling sequence?

If VCC ramps up, RSTn being hold low for 400ms and then driven high, and then EN ramps up, do you still see this issue?

Thanks

David

dp130_schematics.pdf

Hi David,

I attached our schematics.

Unfortunately we have no control over the EN pin which is connected to VCC through 0R resistor.

The rstn is connected through 1uF capacitor to ground.

I will make a scope capture of the VVC and rstn power up.

Do you have any idea what the difference in register values between a good and bad cycle tell us?

Br,

Bart

I attached the requested scope images.

I believe this rstn is in accordance with datasheet SLLSE57E.

We really need a fix through some i2c register accesses as this decoder is in the field for several years already and we cannot make any board/bom changes at this point.

Hi David,

That's unfortunate, but at least it's a clear answer which confirms our experiments.
We will look into delaying initial HPD assertion until considerably after DP130 power-up to make sure it sees a high-going level.

Thanks for your effort.

Best regards,

Bart

Hi David,

We have received new fw from the monitor mainboard colleagues which now issue a hpd low going pulse of 100 ms, 10 seconds after applying dp130 power.
We're still able to reproduce the same issue.

Does the hpd pulse need to be longer or are we missing something?

Br,

Bart

Hi David,

Furthermore, we now disable the squelch detection and autopowerdown in the driver:

        dpv2_dp130_write_reg(dev, 0x01,  0x03); // Disable autopowerdown when hotplug goes low
        dpv2_dp130_write_reg(dev, 0x03,  0x08); // Disable squelch detection

Do we need to remove this for the workaround to work or what is your recommendation regarding these settings?

Br,

Bart

Bart

Squelch detection would only impact the main link, disabling the squelch detection would not impact the AUX traffic from the source to the sink.

You can disable auto power down, this would impact the power consumption.

Are you still seeing AUX not going through the DP130 even with the HPD toggle? Are you toggling the HPD_SNK? And if you manually unplug and plug the cable, are you able to get AUX going through the DP130?

Thanks

David

Hi David,

Yes, we still see that the aux is not going through the dp130 with a 100 ms hpd toggle of HPD_SNK.
Unplug and replugging the cable does fix the blocked aux.

Br,

Bart

Hi David,

The behavior observed is not consistent: sometimes the dp130 needs a soft reset first (i2cset -y -f <bus #> <device address> 0x1b 0x80) and then a hpd pulse or cable unplug-plug to restore proper aux communication.
Does this sounds logical to you?

I'll try to soft rest the dp130 whenever we detect a long hpd pulse (>= 1000 ms), this way in the monitor, it should first get a soft reset followed by a high going hpd_snk.

Are there any known issues around the soft reset?
We don't want to create regression for other working use cases.

Br,

Bart

Hi David,

As this is a known issue

"I did verify that this is an issue with couple flops inside the DP130 internal HPD controller being initialized to the wrong state during power up, and this in turn, produce an incorrect internal EN signal which would impact the AUX communication."

I have to insist in asking if you have more information about this issue and the way to workaround it.
My suspicion is that the problem is caused by the hpd_snk being asserted already when the dp130 is powered and never toggles.
Can you confirm this?
If this is the case, unfortunately, it doesn't seem like we will be able to postpone the initial hpd assertion from the monitor mainboard.

Br,

Bart

Hi David,

I have a seemingly working workaround:

Monitor mainboard issues hpd pulse of 1000 ms after 10 secs of power to dp130.
In the driver we detect the falling edge of the hpd and issue a dp130 soft reset.
Just after the rising edge of the hpd the aux communication is restored.

I hope to get some confirmation from you that this is a good approach or what it should be.

We now still face a lot of partially automated testing for regression so fingers crossed.

Br,

Bart

Bart

My suspicion is that the problem is caused by the hpd_snk being asserted already when the dp130 is powered and never toggles.
Can you confirm this?

This is correct. HPD being high when the DP130 powered up could result in the flops inside the HPD controller get set to the wrong state and not producing the correct internal EN signal.

The workaround we tried was to unplug/plug the cable to produce a transition at HPD_SNK and verified this fixed the issue. We don't need to issue a reset to fix this issue. But I don't see an issue with your proposed workaround. 

Are you seeing the issue on every DP130? 

Thanks

David

Hi David, 

I think that could be a normal condition to have a connected monitor powered before the DP130, so if in this case what the steps to take to avoid problems?

It's enough to issue a soft reset?

Obviously unplug/plug the cable is not always a feasible solution.

Regards

Bart

Unfortunately, a soft reset by itself does not fully resolve the problem because the issue is within the flop inside the HPD controller logic. 

Do you see the issue consistently with certain DP130? 

Thanks

David

Hi David,

Please note that I didn't pose the last question on the forum, that was another person named ACM.

It's my experience that we need to unplug (high -> low hpd); soft reset; plug (low -> high hpd) to fix the problem in all cases.
In most cases unplug plug was enough to fix the problem, but not all.
A soft reset by itself had no noticeable influence on the problem at all.

I have not had the time to test a bunch of devices so I cannot give you any statistics.
I was hoping that TI could provide these statistics as this is a known issue and it was mentioned that some devices are affected and others not,
but without any further specifics.

We were able to successfully work around this issue in our monitor with board to board dp connection as we have control over the hpd.
But we also use the same decoder with externally connected monitors, so it's likely that we're getting or will be getting failure reports from the field.
So I was also hoping for a better solution that works in all use cases, but there doesn't seem to be one?

Br,

Bart

Bart

Since not all units will have this HPD issue, I am wondering is it possible that we can swap out the units that have this HPD issue?

Do you also have the ability of changing the power sequence so the 1.1V comes up before the 3.3V?

But you are right, for the units that have this problem, a soft reset will not fix the issue. A HPD unplug/plug and/or a soft reset will fix this issue.

Thanks

David

Hi David,

This decoder has been in the field for several years.
Our policy is to replace in warranty if a device is returned and the problem is hardware related.
I have no view on how many devices have been swapped already for such issue.

Do you have any idea on the statistics of affected ics?

We have the SS device stuffed, so we cannot change the power sequence.

Br,

Bart

Bart

Unfortunately, I don't have the statistics of the ICs being affected by this issue.

When this issue was initially debugged, we noticed that when the power up sequence is being properly followed, the good units will always be good units and bad units will always be bad units. So my expectation is that once the bad unit is being replaced, you will not see the issue again on that particular decoder.

Thanks

David