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.

BQ25792: BQ25792 + TPS25750 + BQ40Z59-R2

Part Number: BQ25792
Other Parts Discussed in Thread: TPS25750, , BQ40Z50-R2, BQ40Z50

Hello,

Hopefully, someone can provide me with some useful info on this topic.

It is clear that the TPS25750, besides doing the USB-C PD stuff, is also capable of controlling a charger. For example the BQ25792 buck/boost charger, in terms of setting the charging voltage and current, for a given li-ion cell configuration. However, the web based programming interface does not provide more than that.

Next to the TPS25750, as a PD controller, and the BQ25792, as a charger, I am also targeting the BQ40Z50-R2 as a battery pack manager, handling protection, balancing, and gas gauging.

However, in such a setup it seems to be not possible to facilitate communication between the BQ40Z50-R2 and the BQ25792 or TPS25750, for example to support JEITA charging, unless one introduces a separate microcontroller to orchestrate the interplay between the BQ40Z50-R2 and  the BQ25792 / TPS25750, in accordance with the Smart Battery Specification.

However, I would rather not make the design unnecessarily complex if not absolutely required.

So now to my question. Is it in any way possible to program / implement a more sophisticated controller behavior in the TPS25750, such that the TPS25750 + BQ25792 would behave as a smart charger towards the BQ40Z50-R2. For example, the TPS25750 first polls the BQ40Z50-R2 in order to obtain the charging voltage and current, and subsequently programs the BQ25792, and does so repeatedly every minute, or so.

Alternatively, if there is a TI battery pack manager IC (*) that can act as a smart battery master, in accordance to the Smart Battery Specification, is there a possibility that such a smart battery would be able to dynamically provide the TPS25750 / BQ25792 with the charging current and voltage as required by the smart battery.

(*) I have not yet been able to find such an IC in IT’s catalog, so suggestions are welcome. Such an IC should provide protection, balancing and gas gauging (impedance track based), and support the Smart Battery Specification.

Thanks.

Regards

Dave

  • Dear Dave,

    If you use the TPS25750 I2Cm lines to drive the BQ25792 you cannot also use the BQ40Z50-R2 on the I2Cm lines of the TPS25750 to drive the BQ25792. This would cause two primaries to be on the bus and would cause bus collisions.

    However, you can make use of the TPS25750 I2Cs lines. Here, you use the 4CC commands as found in the TPS25750 Technical Reference Manual to send commands to the TPS25750 and also to the BQ25792 and the BQ40Z50-R2 using the pass-through mode. This will prevent bus collisions.

    Thanks,

    Mike Emanuel

    Please click "Resolved" if this answered your question.

  • Understood. But that would require a seperate host controller next to the TPS25750, BQ25792 and BQ40Z50-R2 (or equivalent). Right?

    Is there any TI battery manager (equivalent to the BQ40Z50), that you can suggest, that would allow to program some "intelligence" into it, such that it would function as a smart battery in the most basis sense.

    Or is a separate uController the (only) way to go.

    Thanks.

    -Dave

  • Dear Dave,

    Only one device can control the BQ25792 directly.

    In addition, the BQ40Z50-R2 is a SMBus charger and potentially can control the BQ25792 which is an I2C charger. Please see the attached <www.ti.com/.../sloa132.pdf> to control an I2C device with an SMBus host. However, even if this works, you cannot have two primaries on the line.

    The best solution I have for you is to use a MCU. The gauge would talk via SMBus to the MCU, which would then in turn talk to the TPS25750. The TPS25750 would pass through the commands to the BQ25792. This will ensure no bus collisions.

    Thanks,

    Mike Emanuel

    Please click "Resolved" if this answered your question.

  • Understood. A separate MCU/uC is the best approach.

    Thxs

    Regards

    Dave