- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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
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
