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: TPS65987D

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65982, TPS65988, TPS65987, USB-C-PD-DUO-EVM

Hi Eric,

I am still having issues with customising the firmware on the TPS65987D part. I didn't have any luck over SPI, so am now trying to use the I2C Host Interface to update.

After establishing connection (proven by seeing "APP" when querying the status register as shown below), I attempt to do perform a Host Interface FW Update, using a low-region binary created in the Application Customization Tool. This seems to run OK, but then fails when verifying at the end. This happens whether I attempt to flash either Region 0 or Region 1.

Any ideas why this is not working as expected? One other question - how does the user switch between the application running from region 0 or 1?

Thanks,

Iain.

  • Hi Iain,

    I would suggest using the latest version of the TPS6598x Application Customization tool to do this instead. You can connect to the GUI by selecting Debug --> Debug Mode. Then in the Commands Tab, you will see a Host Interface FW update item. This command has been updated for use with TPS65987 and TPS65988. The GUI you are using above was developed for TPS65982 series of devices.

    Thank you,
    Eric

  • Hi Eric,

    Thanks again for the quick response.

    Understood - I've been using Application Customization Tool V5.13 to configure my application, which should work with the TPS65987 I believe. I didn't know about the Host Interface FW update tool within this software before.

    However, I have just tried this, and am still running into issues - please see below. I get great comms over I2C1, can read all the registers etc and can see the "APP" running, but when I attempt the FW update via I2C I get a "Boot FAILURE" message - any ideas why?

    In reality, all I am trying to do is change the application so it asks for 12V and 20V from a power source instead of just 5V - is there a simpler way to do this other than this custom application method I am attempting?

    Thanks,

    Iain,

  • Hi Iain,

    If you simply want to adjust the source capabilities, you can do so by directly modifying the Source Capabilities register (0x33) in debug mode. This will update the register contents in real time. There is no need to reflash the configuration when doing this. However, this will only update the config in the device RAM, so if you power cycle the device, it will return to the original config.

    Thanks,
    Eric

  • Hey Eric,

    Thanks again for the advice.

    Yes indeed, this would be perfect and I don't need to permanently flash this, since I can have access to the I2C anytime.

    However... I have been trying this, and this doesn't work for me either unfortunately :(

    By way of example, here is my simple test:

    Firstly, I look to see the source capabilities of my USB-C wall charger:

    Which matches what I expect.

    Then, I change the sink capabilities register (0x33) to add a PDO for 12V / 3A, as shown here:

    And then click off and back on to this register to make sure it has been written correctly.

    However, when I check the active PDO after making the changes, this is what I see:

    Which is just as it was before I made the changes to the sink capabilities, and is the base USB-C PDO as I understand it. I also have a voltmeter on the output of the device which confirms the output remains at 5V, i.e. it never jumps up to 12V.

    What am I missing - is there a command I need to send to re-negotiate the PD contract? Or do I somehow need to specify that PDO2 is preferred over PDO1? I am sure I must be missing something simple, or have a fundamental misunderstanding somewhere, but nothing I try seems to have any effect on the negotiated voltage.

    Any ideas?

    Thanks again,

    Iain.

  • Hi Iain,

    After you have changed the sink capabilities on your device, you need to send the GSrC command for Get Source Capabilities. This would cause the wall adapter to send its source capabilities again and the TPS65987D will send a new request message based on its new sink capabilities. This can also be done using the TPS6598x Application Customization GUI in debug mode. Just simply go to the commands tab and find the GSrC command.

    Thank you,
    Eric

  • Hey Eric,

    Still no luck I'm afraid :( I've tried as you suggest, but there is no change to the negotiated power contract.

    FYI I'm using the boot configuration of BP_NoWait & Configuration 3, which is meant to enable 20V / 3A sink.

    This seems to be working fine when I check the initial sink capabilities:

    And the initial config looks as I would expect too, i.e. the PP set to sink mode:

    But for some reason, it just doesn't negotiate for 20V (or for 12V if I change this default from 20V to 12V).

    I just can't see what I'm missing - do you have any other suggestions? I must have missed something super obvious somewhere?

    If the device is booting up in config mode 3, I don't understand what the issue could be here? Pulling my hair out now!

    Thanks again,

    Iain.

  • Hi Iain,

    I would recommend setting the second Sink Capability to a Variable Sink from 5V to 20V. This would ensure that the TPS65987D selects the highest capability offered from the Power Source. If you just have a Fixed 5V and fixed 20V sink capability, you will revert to 5V if the source does not advertise exactly 20V/3A.

    Thank you,
    Eric

  • Hey Eric,

    Thanks for the recommendation... unfortunately this still does not make a difference though :( I've tried various variable (and fixed) profiles that cover the exact source capabilities, but still no joy.

    I have also tried several different USB-C chargers, each with differenct source profiles. But no matter what, the TPS65987D will only ever negotiate the 5V PDO - though it does request advertised current at 5V, so I know the negotiation is working correctly, even if only for the lowest PDO.

    What else could the issue be? I feel that there must be another way of "forcing" a re-negotiation? Re-querying the source capabilities as you suggested before doesn't seem to cause a renegotiation at all.

    Do you have any other ideas? Is there a way of soft-resetting the software, without losing the RAM settings I've applied? Because of course I can't do a POR since this would cause the settings in RAM to be lost.

    Thanks a lot, getting pretty desperate for a solution now.

    Iain.

  • Hi Iain,

    When changing the settings you have in the Sink Capabilities register to include the variable sink, the source should renegotiate after you send the Get Source Capabilities 4CC Command. It would be helpful if you have a PD analyzer to see why this message is not being processed correctly by the attached source. You can also check the settings in the Auto Negotiate Sink Register (0x37) to ensure you have it set to select the Highest Power offered. The USB-C-PD-DUO-EVM sink board uses this same logic when changing the Sink Capabilities and sending the Get Source Capabilities command when a button is pressed.

    Thank you,
    Eric

  • Hey Eric,

    A-ha! That's done it, thanks very much.

    The issue was that the "Autonegotiate Sink" register (0x37) was not visible to me, because the project profile I had created was for "standard" TPS65987D UFP - when I choose "advanced", I get more registers available, 0x37 being one of them.

    It's strange though that the Autonegotiate Sink Enable flag in this register is not enabled by default for the boot Configuration 3 (UFP with 20V PDO), since this means it will never negotiate up the selected PDO.

    Anyhow, this all looks good now, and it behaves as expected, great stuff.

    Thanks again,
    Iain.