• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 137 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.

TPS25751: How to renegotiate USB-C PD if we failed to transition PTCH->APP before the Source stops advertising.

Brad Basler
Prodigy 90 points
Part Number: TPS25751

Tool/software:

I've got a TPS25751 EVM at my desk with the EEPROM disconnected (J16 opened) attached to a microcontroller over I2Ct.

We are testing the use case of not having a dedicated external EEPROM and just streaming over a PATCH on boot. That seems to be working fine, PTCH -> APP transition is reliable.

However, I am manually starting this process off through a terminal. My timing is asynchronous with the USB-C connection being made.

I have the CC pin scoped and I can see that when I connect USB-C to the board, the CC line blips repeatedly for about 10 seconds.

My PTCH -> APP transition sends about 12.9kB @ 100kHz and then has to execute, the whole process takes about 2.36 seconds.

Practically this means that I have to start the PTCH->APP transition within 7 seconds of the USB-C cable being connected. If I wait too long, PTCH -> APP transition works fine, but the voltage never goes higher than 5V.

I tried a 'GSrC' command but that responds with "Task Rejected" (0x3), I'm guessing because the Receive Source Capabilities Register is NULLed.

I do get success if I send Gaid or GAID and then kick off a new PTCH -> APP transition.

However, there's got to be a way to start a new negotiation without resetting / repatching the chip. Does anyone know how?

-Thanks

-Brad

  • 0
    TI__Guru 63461 points

    Hello,

    Please confirm with the Gaid command you do not need the PTCH->APP transition.  This would only be needed with the GAID (Cold Reset Request).

    https://www.ti.com/lit/ug/slvucr8a/slvucr8a.pdf#page=58

    Alternatively, you could write to the port configuration register (0x28).  Disable and then re-enable the type-C state machine.

    https://www.ti.com/lit/ug/slvucr8a/slvucr8a.pdf#page=32

    Regards,
    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 90 points

    With 'Gaid' (as in warm reset), the device goes back into PTCH mode so a new PTCH->APP transition is required.

  • 0 in reply to Brad Basler
    Prodigy 90 points

    Hi Chris.

    Neither of these suggestions bore fruit.

    As far was the Warm Reset, it puts the device back into PTCH mode, so a PTCH->APP transition is needed.

    As far as writing to register 0x28, even writing the same data back to the device it seems to become corrupted, even though it looks OK to me over the logic analyzer.

    Sending "smbus_readblock 0x20 0x28 17" over a terminal yields the following data: 00282E0100000000000000000000000003

    Note the datasheet suggests the register is only 16 bytes but the device responds that there's 17 bytes, maybe it's a firmware change to TPS25751.

    Reading 17 bytes from register 0x28 as seen by my logic analyzer. Matches the terminal.

    Then if I write the same 17 bytes back....

    smbus_writeblock 0x20 0x28 17 00282E0100000000000000000000000003

    I get sensical data on the logic analyzer that matches expectations.

    From the TPS25751 EVM (Note, TPS25751 responses shown in Grey)

    Then when I read the data back, it responds that there's no LENGTH to register 0x28.

    Looking at my USB-C inline meter (Current / Voltage display), it's apparent that trying to write to register 0x28 is resetting the chip. It's back in PTCH mode. 

    I have verified that the TPS25751 device after reset (before PTCH->APP) responds to a read of register 0x28 the same way.

    If I read 16 bytes on register 0x28 and write back the same 16 bytes on register 0x28, the same reset/crash behavior occurs.

    Any other ideas?

  • 0 in reply to Brad Basler
    TI__Guru 63461 points

    Hello,

    Can you determine the state of the device after the initial transition from PTCH-APP mode? 

    Boot Flag Register, 0x2D

    PD Status Register, 0x40

    Brad Basler said:
    If I read 16 bytes on register 0x28 and write back the same 16 bytes on register 0x28, the same reset/crash behavior occurs.

    It appears that the second byte being read/written, 0x28, is invalid.  I will try to reproduce on my side.  

    Chris