TPS65987D: DisplayPort negotiation issue.

Aleksey Starovoytov

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65988, TUSB1064, 10G-EXPANSION-EVM

Hello.

I am working on implementing USB Type-C solution that can accept DisplayPort video as input, and provide 30W of power back to recharge laptop.
Our solution uses TPS65987D TC as PD controller.
I have figured out how to negotiate power delivery, and now it is able to provide necessary voltage in one second.
But, I do have an issue with negotiation of video stream. As a test source I do use CTL J41 Cromebook, which is capable to pump DP signal via USB-C.
We do use SPI flash to load patch, but it can be done via I2C from main processor as well.
In Application Customization Tool I did set Alternate Mode Entry Queue to have only one SVID 0xff01.
However, I do not see it is doing anything except providing a power.

Here is my project file.

Anyone have any suggestion?
custom_04-18-19_00.pjt

over 6 years ago

0 Eric Beljaars over 6 years ago

TI__Mastermind 36751 points

Hi Aleksey,

I would recommend looking at the DisplayPort alternate mode app note: www.ti.com/.../slva844b.pdf
This app note explains what the register settings should be for DP mode.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Thanks Eric for the answer.

I did studied this app note quite a bit already, and I will do some more.
Anyway, I got some more result, and some more questions.
Looks like the project that I posted last time was more for TPS65988 not for TPS65987D. How I have created different project, which is simplified.
It does negotiate power ok and then it sends IRQ with new data in register 0c5F, and byte 2 of this registers are 0x07 which indicates of DP presence. Also HPD line is HI all the time, but laptop screen does not blink and it is not seeing external monitor or anything.

Any suggestion?

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

Do you have a PD analyzer available? it would help in your debug to see if the DP alt mode is properly entered and configured. Additionally, you would be able to see if the HPD message is sent or not.

Thanks,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

HI Eric.

Unfortunately, PD analyzer is not available here.
We have to debug using register read-back.
In slva844b document in table 5, there is a debugging steps.
Step 1 is to check register 0x34;
Here is the read-back from it;

Addr=0x70, Reg=0x34
Register size(# of bytes) = 6
Byte 1 = 0xc8, Binary = [1100 1000], ASCII = È
Byte 2 = 0xb0, Binary = [1011 0000], ASCII = °
Byte 3 = 0x04, Binary = [0000 0100], ASCII = EOT
Byte 4 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 5 = 0x50, Binary = [0101 0000], ASCII = P
Byte 6 = 0x00, Binary = [0000 0000], ASCII = NUL

Step 2 is to verify reg 0x51;
here it is:

Addr=0x70, Reg=0x51
Register size(# of bytes) = 6
Byte 1 = 0x03, Binary = [0000 0011], ASCII = ETX
Byte 2 = 0x45, Binary = [0100 0101], ASCII = E
Byte 3 = 0x1c, Binary = [0001 1100], ASCII = FS
Byte 4 = 0x0c, Binary = [0000 1100], ASCII = \f
Byte 5 = 0x10, Binary = [0001 0000], ASCII = DLE
Byte 6 = 0x00, Binary = [0000 0000], ASCII = NUL

This two looks ok, now HPD signal, it was HIGH all the time, I did change it and now when TPS65987d sees DP availability it pill one of the GPIO HIGH which make HPD to go high, but it does not change anything also.

Also I can see that PD controller communicates via CC lines, but SBU and Data lines are flat.

Any suggestions?

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

HPD should be configured to the HPD GPIO event, I see this is the case in your project file. From your description, it does not sound like this issue is related to the PD controller. The DP mode is being entered correctly and HPD is being asserted. I would suggest checking other parts of your system related to DP mode.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric.

Thanks for the answer again. You mentioned that GPIO with connected HPD needs to be configured as HPD GPIO event. I have HPD connected to GPIO3 and to configure it I use field that says "Pin Multiplexed to Alternate Function" is it correct? And one more question, does HPD on PD controller configures as input or output?

Thanks,
Aleksey

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

That is correct, you would see GPIO3 set to "Pin Multiplexed to Alternate Function".
HPD on the 87D can be either an input or an output depending on the DisplayPort data role.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Simpl_04-24-19_00.pjtHi Eric,

In our design we do use High speed MUX that can be controlled via I2C, and now I can get some status from it.

After 87D gets configured for a power and turn itself into DP mode, it send signal to initiate HPD, and I can read that HPD is asserted in High speed MUX, but there is no signs of it on the laptop. Also this mux device have status register, and it says that supper speed lines are suspended, which happens when there is no communication via SBU/AUX lines. Here is the last project file that is used on 87D device.

Any more suggestion?

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

Everything in your .PJT file looks correct in terms of the PD controller. I suspect the issue may be with the superspeed mux. I would suggest asking a new question with the superspeed mux part number so that teams expert can look at the issue.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric,

Thanks for suggestion, we do use PS8742A from Parade Tech. It can be controlled via I2C or pin strapping. I did tried both ways, and with I2C can get more information but no video.
After the mux signal is connected to DP to HDMI converter IS from same vendor. Then we do use HDMI switch.
Originally HDMI 5V IN was connected to 5V rail of the device, and now I added MOSFET switch between 5V rail and Input line to initiate HPD triggering.
This 5V switch is controlled via GPIO4 of 87D, which is configured as "Port 0 AMSEL Event".
I can send you our schematic for review but not on public forum.

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

Unfortunately, I cannot support the Parade parts in your system. I would suggest reaching out to them for support on this issue.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Aleksey Starovoytov

Intellectual 400 points

Eric,

Based on TI App Note "slva844b" Table 5 monitor of laptop should flash black and resume to normal operation when it receive Hot Plug message.
Also base on document DP-Alt-Mode-Overview-for-VESA-v1.pdf, Page 13 from vesa.org HPD is being send via CC lines, and CC lines are connectod to TPS65987D only.
And like I said in one of my previous posts, I can see HPD line, that is connected to PD controller, to go HI, however nothing is happening on laptop at that moment, which leads me to think that TPS65987D ignores HPD input and not telling laptop to start communicate via SBU/AUX cannels.

Thanks for your new suggestions.
Aleksey

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

This does not sound like an issue with HPD. The PD controller is behaving as expected and is setting the HPD GPIO correctly. The PD controller does not touch the SBU lines which is where it sounds like your issue may be.

Thanks,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric,

Here is the screenshot from oscilloscope that measures HPD line (blue) and CC lline (yellow), and triggers on HPD rise.

Is this what we need to see or something incorrect here?

Thank you.
Aleksey

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

This looks correct, the HPD GPIO goes high and the CC packets over the Type-C cable are seen directly after. I don't see an issue here from the PD controller perspective.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Eric,

Thank for all of your help, I will communicate with Highspeed mux from now.
Anyway, one more question, is there any more communication needs to be happened before it starts to talk over SBU lines?

Thanks,
Aleksey

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

SBU Communication should start after the HPD Signal. The PD controller does not control the SBU communication.

Thanks,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric,

Thanks again, for your answers. Do you think this issue here because of DP HPD timing requirements?

Aleksey

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

The TPS65987D is compliant with the latest Vesa spec with regards to HPD timing.

Thanks,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi everyone,

Unfortunately, our issue have not being resolved yet.

I was looking in document slva844 and found that DisplayPort status can be read in reg 0x58.
I did look at this register, and it is looking not really correct for me.
However in the Ref manual there is no good description of every field of the reg 0x58.
Here is my reed-back of it, can someone tell me if anything wrong here;

Addr=0x70, Reg=0x58
Register size(# of bytes) = 37
Byte 1 = 0x03, Binary = [0000 0011], ASCII = ETX
Byte 2 = 0x8a, Binary = [1000 1010], ASCII = Š
Byte 3 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 4 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 5 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 6 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 7 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 8 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte 9 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte10 = 0x06, Binary = [0000 0110], ASCII = ACK
Byte11 = 0x04, Binary = [0000 0100], ASCII = EOT
Byte12 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte13 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte14 = 0x45, Binary = [0100 0101], ASCII = E
Byte15 = 0x1c, Binary = [0001 1100], ASCII = FS
Byte16 = 0x0c, Binary = [0000 1100], ASCII = \f
Byte17 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte18 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte19 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte20 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte21 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte22 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte23 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte24 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte25 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte26 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte27 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte28 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte29 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte30 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte31 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte32 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte33 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte34 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte35 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte36 = 0x00, Binary = [0000 0000], ASCII = NUL
Byte37 = 0x00, Binary = [0000 0000], ASCII = NUL

Thank you.

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

This still looks ok to me. As we had discussed earlier on in the post, the TPS65987D is entering DP alt. mode and is handling the HPD correctly.
The error is not related to the PD controller.

Thank you,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric,

Thanks for reply. That is great that you not seeing any issue here. But I still have question, do we need to do anything also to make it work. As I understand, after HPD line on PD go HI, it sends Attention message on CC line, and in a few moments laptop needs to start communicating over SBU line, if it is configured correctly.
In our situation PD negotiate power and Alt mode, than send our MCU interrupt, we go configure SS MUX and rise HPD line of PD ( actual video path HPD line stays HI all the time, so it is always ready to receive stream).
PD sends attention message, but we cannot detect any activity on SBU lines.
I have oscilloscope connected to SBU with trigger for any activity, and it stays flat.
By the way, a little USB-C to HDMI converter does everything it needs to do on both USB-C connectors of this Chrombook.

Thank you,
Aleksey

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hello Eric,

I did ask similar question by showing you terminal read back from register 0x58.
Now, I do have Aardvark adapter connected to my computer, and I can communicate from Application Customization Tool directly to our board.
And here is the 0x58 register:

For some reason DP status RX looks incorrect.

One more think, that TI TUSB1064 HS Mux is almost pin compatible with HS MUX device from Parade that we used.
Thus, with a little rework, I did relapsed Parade IC to yours TI TUSB1064, and I do have identical result.
I did measure voltage levels on AUX lines of legacy DP and positive is 3.09V, negative is 0.02V, however SBU lines levels equal each other and it is at 0.05V.

Thanks and Best Regards.

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Hi Aleksey,

Since you are designing a DP UFP, I would only check DP Status TX. The DP Status RX fields would be populated in the DP_DFP. Again, I don't believe this is an issue with the TPS65987D.
Can you reproduce this issue on the TPS65987EVM with the 10G-EXPANSION-EVM?

Thanks,
Eric

0 Aleksey Starovoytov over 6 years ago in reply to Eric Beljaars

Intellectual 400 points

Hi Eric,

Unfortunately, we have no TPS65987EVM in house yet.
However, I did notice couple more anomalies on this TPS65987D IC. Even thou in reg 0x58 it says that it is connected to DP,
on GPIO5 that is configures as Port 0 AMSEL Event, it outputs LOW; while the GPIO2 that configured as Port 0 USB3 Event - outputs HIGH.
And one more, GPIO1, which is configured as Port 0 Cable Orientation Event - always HIGH. When I disconnect USB-c plug and connect it again GPIO1 become LOW for a moment and
then become HIGH, regardless of actual orientation.

Any suggestion?

Thanks

0 Eric Beljaars over 6 years ago in reply to Aleksey Starovoytov

TI__Mastermind 36751 points

Aleksey,

I would suggest checking this behavior with a TPS65987EVM once it is available. The TPS65987EVM uses the DP Mode event instead of AMSEL. The Cable orientation event strictly relies on which CC pin is used for PD messaging. I would suggest checking the cables you are using since we have never seen any issues with this GPIO event not working correctly.

Thanks,
Eric

Interface

Interface forum

TPS65987D: DisplayPort negotiation issue.