• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 65 subscribers
  • Views 666 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.

Original question:

TPS25750: Charger negotiation voltage

TPS25750: How to clear dead battery flag

Zack Sheffield
Prodigy 50 points
Part Number: TPS25750

I have my circuit configured as indicated in the related question here: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1130178/tps25750-charger-negotiation-voltage/4202856?tisearch=e2e-sitesearch. The only difference is I've configured ADCINx for AlwaysEnableSink.

There are situations when the dead battery flag is asserted and MODE=PTCH, but I am unable to load a patch or clear the dead battery flag.

Here's a register dump of the state I'm in, I highlighted the register fields of interest.

0x03 (MODE): [0x50 0x54 0x43 0x48]
  0x50 ('P')
  0x54 ('T')
  0x43 ('C')
  0x48 ('H')
0x14 (INT_EVENT1): [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02]
  PlugEarlyNotification: 0x0
  ErrorPowerEventOccurred: 0x0
  NewContractAsCons: 0x0
  UsbHostPresent: 0x0
  PatchLoaded: 0x0
  ErrorCanProvideVoltageOrCurrentLater: 0x0
  ErrorUnableToSource: 0x0
  PDHardReset: 0x0
  PPswitchingChanges: 0x0
  NewContractAsProv: 0x0
  PDStatusUpdate: 0x0
  PRSwapComplete: 0x0
  PlugInsertOrRemoval: 0x0
  CMDComplete: 0x0
  PowerStatusUpdate: 0x0
  DRSwapComplete: 0x0
  PRSwapRequested: 0x0
  UsbHostPresentNoLonger: 0x0
  ReadyForPatch: 0x1
  ErrorMissingGetCapMessage: 0x0
  I2CMasterNACKed: 0x0
  TxMemBufferEmpty: 0x0
  SourceCapMsgRcvd: 0x0
  ErrorMessageData: 0x0
  ErrorProtocolError: 0x0
  ErrorDeviceIncompatible: 0x0
  DRSwapRequested: 0x0
  ErrorCannotProvideVoltageOrCurrent: 0x0
  SnkTransitionComplete: 0x0
  StatusUpdate: 0x0
0x2D (BOOT_STATUS): [0x34 0x03 0x62 0x02 0xA1]
  PatchheaderErr: 0x0
  DeadBatteryFlag: 0x1
  PatchConfigSource: 0x0
  MasterTSD: 0x0
  patchdownloaderr: 0x0
  I2cEepromPresent: 0x0
  REV_ID: 0xA1

I'm not sure why the I2cEepromPresent is set to 0, since it is powered from LDO_3V3 which is regulated from VBUS_IN. But oh well here we are.

So when I try to execute the DBfg task, I get a "Task Rejected" return code. The MODE, INT_EVENT1, and BOOT_STATUS register contents are the same.

When I try to load a patch, After I write PBMs to the CMD1 register, I read it back and get a 0x40 byte with a NAK. Not sure what's going on. 

I have attached the .json file I've used to generate the low region and full binary (and this is what is loaded on the EEPROM). I also attached the logic analyzer captures from the DBfg and PBMs tasks so you can see the raw i2c transactions.

Any thoughts on how I can clear the dead battery flag?

Thank you!

/cfs-file/__key/communityserver-discussions-components-files/196/DBfg.csv.txt

/cfs-file/__key/communityserver-discussions-components-files/196/23010600.json.txt

/cfs-file/__key/communityserver-discussions-components-files/196/PBMs.csv.txt

  • 0
    TI__Genius 17905 points

    Hi Zack,

    Thanks for reaching out on E2E!

    We will get back to you early this week!

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 50 points

    Kevin,

    Can you get back to me early this week instead?

  • 0 in reply to Zack Sheffield
    TI__Genius 17905 points

    Hi Zack,

    Apologies for the delay here!

    Unfortunately we cannot clear the dead battery flag until the device is out of PATCH mode and enters APP mode.

    I don't have a clear idea of what the issue is as of now, but we will figure it out!

    I have some follow up questions here:

    Are you loading the FW from the EC or are you using an external EEPROM?

    Also are you having this occur only when booting from dead battery?

    Can you confirm what the voltage and current is being supplied to your board when booting from dead battery?

    Looking forward to hearing back!

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 50 points

    Are you loading eh FW from the EC or are you using an external EEPROM?

    EEPROM. Not sure what EC means.

    Are you having this occur only when booting from a dead battery?

    It occurs when there is a dead battery condition. 1) When I plug in USB power with and no battery attached (expected) 2) When I unplug the battery while it's functioning as expected.

    Can you confirm what the voltage and current is being supplied to your board when booting from dead battery?

    Voltage is at 5V. It depends on the load of the board, but the current is anywhere from a few mA to 3A (maxed out). I need over 60W with a full load, thus the need for a 20V/5A/100W PDO.  

    Unfortunately we cannot clear the dead battery flag until the device is out of PATCH mode and enters APP mode.

    Then clearly I need to figure out how to successfully patch it.

    The only thing I can think of is that When reading some of the registers, my I2C driver does a 32-byte transaction (when only e.g. 4 bytes are needed). You can see this on the original files I provided, there's a bunch of extra zeroed bytes in some of the transactions. Maybe this is borking things? I will try to reduce the spurious clock cycles and maybe this will solve the issue.

  • 0 in reply to Zack Sheffield
    TI__Genius 17905 points

    Hi Zack,

    Thank you for your follow up answers!

    Zack Sheffield said:

    Are you loading eh FW from the EC or are you using an external EEPROM?

    EEPROM. Not sure what EC means.

    Thanks for clarifying here! I wanted to know if you were loading your FW from the EEPROM or an external controller.

    I took a look at the schematic from the previous thread. Have the ADCIN resistors changed from that thread?

    It looks like you have a 422k pull up and 100k pull down in this case for both resistive divider . That corresponds to a decoded value of 3 and 3. In the data sheet this corresponds to the NegotiateHighVoltage dead battery configuration, which cannot be used when loading the FW from an EEPROM.

    I think changing the dead battery configuration to be in the AlwaysEnableSink configuration should hopefully solve this issue.

    Let me know if you have any further questions!

    Thank you,

    Kevin

  • 0 in reply to Kevin Kosta
    Prodigy 50 points

    Kevin,

    as indicated in the description of this problem, I indeed changed the ADCINx configuration for AlwaysEnableSink.

    in the previous thread (where your screenshot came from), I had the opposite problem, where it would negotiate the correct voltage as long as there was a dead battery condition, but I couldn’t get it to negotiate correctly under other circumstances. 

    which is why I started a new thread. New thread, new problem!

    thanks

  • 0 in reply to Zack Sheffield
    TI__Mastermind 37855 points

    Hi Zack,

    Sorry for the confusion, but Kevin is busy this week and wanted some team members to look at this thread.

    I have a couple questions about this thread.

    1. Are you entering Patch mode yourself and attempting to update the patch, or is Patch mode being entered during the boot process?
    2. Why are you attempting to clear the dead battery flag? Is the device being powered from the USB-C connector or from an internal source in this case?

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 50 points
    1. No I am not entering patch mode intentionally, it appears to be happening during boot.
    2. When I plug in the USB-C connector and there is an internal source already applied, the dead battery flag is not asserted and the system is functioning as expected (charger enumerates to 20V). However, when I remove internal power (i.e., unplug the battery), I can see my USB power meter/charger "reset" and it comes back up at 5V, with the TPS25750 dead battery flag asserted.
  • 0 in reply to Zack Sheffield
    TI__Genius 15275 points

    Hi Zack,

    Can you attach updated and populated schematic please.

    Very Respectfully,

    Brandon Beader

  • 0 in reply to Zack Sheffield
    TI__Mastermind 37855 points

    Thanks Zack,

    Because the device is being powered off of VBUS, it is not surprising that the Dead battery flag is being raised. Let us check internally to see if this should cause any issues with the boot loading sequence. It seems unlikely because the PD should be able to load a configuration from a dead battery condition.

    Thanks and Regards,

    Chris

  • +1 in reply to Christopher Lim1
    TI__Mastermind 37855 points

    Hi Zack,

    Apologies for the delay. I was able to speak with one of our engineers more familiar with the boot loading process and EEPROM.

    The dead battery flag being raised should not cause patch mode to fail.

    The device will get stuck in patch when the PD controller is not able to properly load a patch from and EEPROM or from a Host EC(Depending on what option you are using). The failure can happen for a couple reasons.

    Zack Sheffield said:
    I'm not sure why the I2cEepromPresent is set to 0, since it is powered from LDO_3V3 which is regulated from VBUS_IN. But oh well here we are.

    This bit indicates that the EEPROM failed to load, and could be de-asserted for a couple reasons.

    1. Issues with EEPROM connection
      1. It appears that the EEPROM is working properly when internally powered(powered from Vin3V#, not from VBUS), so it does not seem like a hardware connection issue
    2. Invalid Patch (Patch fails verification)
      1. Similar to before, the patch (binary file on the EEPROM) worked properly when the device was internally powered.

    This indicates possible issues with the EEPROM and boot loading sequence.

    Zack Sheffield said:
    When I plug in the USB-C connector and there is an internal source already applied, the dead battery flag is not asserted and the system is functioning as expected (charger enumerates to 20V). However, when I remove internal power (i.e., unplug the battery), I can see my USB power meter/charger "reset" and it comes back up at 5V, with the TPS25750 dead battery flag asserted.

    I had a couple questions about your use case and your expected behavior.

    Is this the steps you are taking to achieve the current behavior?

    1. Device has internal battery connected and PD controller is powered.
    2. Connect an external device to the type-C port
      1. PD contract negotioated
    3. Remove internal battery
      1. PD controller reboots and gets stuck in patch

    If that is the case, can you try disconnecting and reconnecting the external device to allow the PD to power off, and see if it boots properly again?

    You could also try writing a "GAID" 4CC command to reset the PD controller.

    During the failing event, can you probe LDO 3V3 (primarily by the EEPROM) and see if it drops below the EEPROMs minimum VIN voltage?

    What is the power role for the two devices? Is the TI PD controller a source or a sink and is there a power role swap?

    Do you expect the PD controller to be in the same power role when the battery is disconnected vs. when it is connected?

    My current thought is that when the battery is removed, the PD controller must change the power source from Vin3V3 to VBUS, which is causing the PD to lose power temporarily and reset. During the reset, it attempts to load the patch again, but the EEPROM may not have enough power to be recognized properly.

    Thanks and Regards,

    Chris

  • 0 in reply to Christopher Lim1
    Prodigy 50 points

    GAID did the trick for me. I see there are some obscure macros in the TRM that mention GAID, but certainly no clear explanation of what it is or even that it is a 4CC command.

    To answer your questions:

    Disconnecting and reconnecting the external device to allow PD to power off - it still enumerates to 5V when reconnecting. The only way it enumerates to 20V is if it's powered internally and can read the EEPROM.

    Skipping the probing now, as I don't think this will add any value at the moment.

    It's configured as dual role PD with a preference of source. At least that's what's in the EEPROM (the .json for the configuration tool is attached in the original post).

    If the battery is disconnected, the controller should sink power from the USB port. 

    I'm also thinking there's an issue when it switches from Vin3V3 to VBUS for power, but the fact that I can reset everything with GAID and have it re-read the EEPROM is what I was looking for in the first place.