• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 656 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: Strange I2C master output on dead battery boot

David Colatosti
Prodigy 120 points
Part Number: TPS65987D
Other Parts Discussed in Thread: BQ25703A, , TPS65987

Greetings -

We have an embedded PC system with touch screen and SOM.  It has an internal, smart, off-the-shelf rechargeable Li battery.  Our system runs off the battery and uses USB-C with PD for charging and data exchange. 

We are using the TPS65987D and the BQ25703A for the USB-C and PD functionality, and our design evolved from TIDA-01627.  ADCIN1 is set with a ratio of 0.9.

We based the I2C master configuration of TPS65987D firmware off of SLVAE-18 (Configuring I2C Master for BQ25703A Battery Management Controller)

Charging/Discharging/USB OTG all work as expected.   However, we have a problem with dead battery start up.

Whenever we would have our system start with a dead battery  (VBAT = 0 due to battery internal fet cutoff for cell low voltage protection) and plug in USB-C to charge, our system would only charge to about 2%.

I have been using TPS65987D-90EVM connected to BQ25703AEVM (in the same manner as our design) to develop TPS firmware and test.

Using the EVM modules and running Battery Management Studio connected to the BQ part and TIs BQ gas gauge software to monitor our battery I have watched the BQ registers and would see addresses 0x02/0x03 be reset to zero (which was the cause of charging to stop).  Further studying showed that rather than setting BQ addresses 0x00/0x01 to 0x820E, it was actually being set to 0xE20E.  The watchdog timer was being enabled (as is default at power up).

At dead battery power up, I monitored the I2C bus between the TPS65987 and the BQ and I found that several I2C commands from the TPS were getting truncated.  The register addresses and data were not present in the messages.  These are the initial commands sent out as discussed in SLVAE-18. See the scope capture.  None of the data elements are transmitted after the 0x6B address.

And then the first command that actually is sent correctly is some 300ms late setting the charging current:

Thus leaving the watch dog timer set and causing our system to stop charging.  At approximately 175 seconds, the battery would stop charging.  This behavior occurs on both the EVM setup and our system.  The truncated messages are also the same.  The above SLVAE-18 messages transmit correctly if we plug in a not-dead battery to a system (no USB-C power).

Issuing a cold reset to the TPS65987D from our SOM does fix the problem in that it reissues the POR commands to the BQ part.  But that is not a reasonable solution as it would require turning on the whole system.  A dead system should be able to be plugged in and charged with out some higher controller interactions, which I think is the intent of using the TPS/BQ parts.

The truncated messages seem like erroneous behavior on dead battery start-up.  I would appreciate any advice to get the BQ configuration to implement correctly on dead battery start-up.

Thanks,

Dave

  • 0
    Prodigy 120 points

    I missed the fact that it looks like those "truncated" transmissions do in fact have no ACK from the BQ.  I will look further into how the BQ part gets powered in dead battery mode that may cause it to miss the initial transmissions.

  • 0 in reply to David Colatosti
    TI__Mastermind 30000 points

    Hi David,

    Yes that was going to be my suggestion. The PD controller is sending a command to the charger once it powers up, but the battery charger is not powered on yet and NAK's the commands the PD controller is trying to send. I would double check with the charger team, but during a dead battery event, the battery charger will be powered from the VBUS pin. Assuming the trigger event is on power reset, you can also send these commands again once the PD controller closes the power path to the charger, supplying voltage to the VBUS pin on the BQ.

    Hope this helps solve your problem

  • 0 in reply to Adam Mc Gaffin
    Prodigy 120 points

    Thank you for your feedback Adam.

    I performed additional testing using the EVM boards.   As we suspected the BQ part does not appear to be powered on soon enough.  In the capture below: Blue=SDA, Yellow=SCL, maroon=Vbus from PP1

    As you suggested, I tried duplicating the POR I2C master events using "PP1 Switch On (closed)" as the trigger event.  So now I have 4 POR events (far left SDA/SCL activity), and an additional 4 events in the I2C traces (middle I2C activity).  PP1 switch is closed (on) when my USB-C is connected in dead battery mode (used debug mode in the App GUI tool to verify).  Note the maroon trace, it is the VBUS feed from the TPS to the BQ.  Note it doesn't began ramping up to 5V until ~17ms after the new PP1 closed I2C events.  

    It looks like the only event (right side SDA/SCL activity) that is successful is the PDO sink contract that gets negotiated some 300ms after the POR events.

    Based on the above, it looks like the BQ part really won't be active until well after the POR events and even PP1 closed event.  

    I do have "CHRG_OK" wired to a GPIO on the TPS and I could use that possibly as an I2C event trigger, but it is not clear to me how to do that as I don't see any trigger event pull down selections mentioning GPIO.

    The work around I am leaning to right now is to resend any critical configurations on PDO Sink negotiation.  For me these are the charge current set, no watchdog, and the correct charge voltage level.

    Dave

  • 0 in reply to David Colatosti
    Prodigy 120 points

    As I mentioned above, I implemented my work around which is reissuing the charge current, charge voltage, and disabled watchdog at any PDO Sink event.  This seemed to resolve my charging issues coming out of dead battery mode.