• State Resolved
  • Locked Locked
  • Replies 26 replies
  • Answers 12 answers
  • Subscribers 33 subscribers
  • Views 3386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65987D: DisplayPort negotiation issue.

Aleksey Starovoytov
Intellectual 400 points
Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65988, TUSB1064

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

  • 0
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 points
    Hi Aleksey,

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

    Thanks,
    Eric
  • 0 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 points
    Hi Aleksey,

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

    Thanks,
    Eric
  • 0 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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 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 in reply to Aleksey Starovoytov
    TI__Mastermind 36756 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