• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 1367 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.

TPS65982: Alternate Mode Entry register (0x38) order is ignored in actual traffic

WST
Expert 1015 points
Part Number: TPS65982

I was using one image and changing the Alternate Mode Entry register (0x38) mode order between display port 0xff01 and thunderbolt 0x8087.

In the 1st image I have 0x8087/mode 1 as the first SVID, and 0xFF01/mode 1 as the 2nd SVID. The 2nd image has the opposite order.

I download an image to my TPS65982 and then connect to a Dell laptop and trace the PD traffic. No matter which image I use, the Discover SVIDs Ack message that comes from the TPS65982 on my board has byte 6 = 01, byte 7 = FF, byte 8 = 87 and byte 9 = 80. Bytes A-D have 0x00 in them for the two required blank SVIDs. It doesn't matter which image I load, I always get the same order. Here is what the trace is in either case:

I checked the images in the Appl Configuration tool and looked at Register 0x38 in raw mode and they flip between the two images. The register 0x38 raw value for the DP first is: 0x180870001ff01. The register 0x38 raw value for the TBlt first is: 0x1ff0100018087.

And, if I use the HostInterface tool (HIT) after loading each image, and read register 0x38 over I2C I see that they flip in the two images and match the config tool. So the downloaded images are different.
For DPort 1st, the raw value read using the 'read' command is 0x180870001ff01L. Using the register list and reading register 0x38 I see the Highest Priority SVID = 0xff01, and Second = 0x8087.
For TBlt 1st, the raw value read using the 'read' command is 0x1ff0100018087L. Using the register list and reading register 0x38 I see the Highest Priority SVID = 0x8087, and Second = 0xff01. Here is a picture from the 2nd:

I also confirmed this by using the read/write commands and changing register 0x38 in one image. So, why is the TPS65982 responding with the SVIDs on the PD handshake going out in the same order, no matter what register 0x38 says?

I looked at the traffic with two different PD analyzers and they both show the same order. When I read the Data Status register with the HIT, it says that a TBlt connection is made with either image, so apparently bytes 8 & 9 of the Discover SVIDs Ack message has priority. The Rev3, v1.0 PD documentation isn't clear on which one of the two in a word has priority, it shows SVID0 = bits 31:16, and SVID1 = bits 15:0. It seems like the Dell is choosing bits 15:0?

My solution at the moment is to only have one SVID per image, and drop the other one. Then I don't have to worry about the priority, but I wanted to understand what is going on.

WST

  • 0
    Expert 1015 points
    Something else that is a slight problem... The only way I can use the HIT tool to re-write this register to change the order is to use the 'read' and 'write' commands, I can't change it using the Register List -> 0x38 view and the 'Write Register' button. It ignores my changes and switches it back to what it was before.
  • 0 in reply to WST
    Expert 1015 points
    I think I may have misunderstood something. Since my TPS65982 is acting as a UFP, I don't think the Alt mode entry register is used by the host. Is this correct? I think the Alt mode entry is controlled by the Host/DFP, not the UFP. So perhaps this register isn't being used in my configuration and so the order isn't important for my UFP device. However, looking at the PD trace, it says that the ACK message comes from the UFP (my part), so I'm not sure why it wouldn't flip if the register is flipped.

    Also, I think bits 31:16 are indeed the 0x8087 which the Dell chooses, and according to the PD spec, the upper bits are SVID0 (seems backwards to me) and the lower 16 (15:0) are SVID1.
  • 0 in reply to WST
    TI__Mastermind 36756 points
    Hi WST,

    we are looking into this and will update you asap.

    Thank you,
    Eric
  • 0 in reply to WST
    TI__Genius 12990 points
    Hi WST,

    I have seen this before as well. I will use register list to write something then go back in the same register to find my write has been over written. It should work. I would suggest to re-read the register to confirm it has been written right after you write it.

    Thanks
  • 0 in reply to WST
    TI__Genius 12990 points
    Correct, if both sides support both modes then the DFP will look to Alt mode entry register to find out which mode has highest priority. I will try to recreate your PD trace and see if I can find an explaination.
  • 0
    TI__Genius 12990 points
    Hi WST,

    All our parts are hardwired so that TBT will enter before DP reguardless of what the alt mode entry register says. I hope this helps, please let me know if I did not answer your question

    Thanks
  • 0 in reply to Jeffrey Mueller
    Expert 1015 points

    Thanks for the info, that is really helpful. I will just have a separate image, or disable the TBT mode if I want to use the display port. But it is good to know that it wasn't something I was doing wrong.

    WST