BQ25185: Pin control of BATFET turn on/off

What is the definition of Ship Mode? I need to be able to disconnect the load from the battery using a logic signal that pulls to ground when in OFF mode. I would also want the battery charging IC to draw almost no power from the battery, i.e. IQ should be less than 1uA ideally. 

What is the current draw in Ship Mode for BQ25185? The datasheet has IBAT_FACT for factory mode, but I don't think this is the same thing since the current is even higher than IQ_IN. Can an open-drain FET implementation work for the TS/MR pin work like shown for the SYSOFF pin in Figure 1-2?

Alec, please see the simplified diagram of how the battery power system works. The secondary battery (Lithium Cobalt Oxide coin cell) powers a few low power components when it is on in states S2 and S3. The secondary battery should also charge itself from the primary battery in those states but not in the off state S1. Because the Primary battery is always there (unlike a wall charger that gets unplugged when charging is complete) its presence cannot trigger the battery charger to turn on, i.e. the ENABLE signal takes precedence and the battery charger is not charging in S1 and BATFET is OFF. Also, because the charging source is itself a battery, low power draw on these components is critical: if the primary battery is removed in S2 or S3 the battery charger cannot put too much of a load on the Secondary battery, ideally this would be no more than 3.2uA. Based on what I have described, what would be the ideal battery charger and fuel gauge for this application? Can both the Fuel Guage/Protection IC and the Battery charger share the thermistor? I am not sure if that is how its commonly done, but obviously they both need battery temperature information. 

Hi Kevin,

Thanks for sharing the block diagram of your system. Here's my understanding and comments:

The primary battery is the only input source to the battery charger. In S1, the battery charger should be in ship/shutdown mode to minimize quiescent current draw from the secondary battery.

• If the primary battery (i.e. input source) is always connected, the charger won't be able to enter ship/shutdown mode until the input is removed. You may want to add a load switch or eFuse to disconnect the primary battery from the charger's input. For example, you could control this switch with a signal that also puts the charger into ship/shutdown mode.

In S2 and S3, the charger should charge the secondary battery, which powers low-power components.

• With power path, the input source can simultaneously power the low-power components while the secondary battery charges.
• If the primary battery is removed, then the secondary battery will directly power the low-power components. In that case, the current draw from your battery will mostly depend on the load from these components.
• Depending on the voltage of your primary battery, it may be more efficient to use a switching charger rather than a linear charger. For example, if your primary battery is 12V and your secondary battery is 4.2V, I'd recommend a buck charger.

Can the fuel gauge and battery charger share a thermistor?

• If possible, I'd recommend not sharing the thermistor between the charger and the fuel gauge. The TS pins on each device will likely conflict with each other (e.g. both trying to bias the thermistor) and throw off the TS voltage.

Let me know if you have any other requirements for the battery charger, or if you think a switching charger makes more sense based on your primary battery voltage. That will help narrow down part recommendations, and from there I can loop in the fuel gauge team for a recommendation as well.

Best regards,

Alec

Yes you understand the requirements correctly. I am not opposed to using a switching charger, but RC-Settable is preferred still. In the last design I used BQ25628, but I ran into the same problem of not being able to shut it down in S1 and there is no microcontroller that is always running that can program it via I2C to shut off (catch-22 condition). Maybe the TS/MR pin open-drain shutdown and and load switch on the input could fix that? I also had an issue with the QOn pin. Since it was tied to the FPGA, when the FPGA would boot (i.e pins go from 0V to high-Z) it would cause the BQ25628 to reset and cut power to the device it was powering. This never made sense because the datasheet stated that a change on QOn had to be at least 10s long in order for rest to occur - which it wasn't. I had to end up cutting the trace to disconnect QOn. Regarding the TS pins, if it cant be shared then I need to know what TI recommends doing because both the Fuel gauge/Protection circuit and the charger both want access to the thermistor for different reasons - the Protection circuit needs to protect against normal load discharge at high or low temps and the charger needs to protect against charging at high or low temps. 

Was an input source connected while this was happening? I believe it was connected to a battery. 

Regarding the Fuel Gauge, if you take a second look at the block diagram, I posted there is an I2C path drawn from the MCU to the Fuel Guage which it could communicate with while the MCU is powered on. I even drew an option connection to an I2C battery charger if I needed to do so. The main thing I do not understand is why TI did not put Non-Volatile memory in these battery chargers so that you do not constantly have to rely on having to power on the MCU and then reprogram the charger.

Are there specific features of a fuel gauge that you'd like to have in your design? Battery undervoltage, overvoltage, short circuit, overcurrent, Thermal protection for charging and discharging, i.e. our product could see temperatures above 60C and below 20C and needs to know to disable the load from the battery in these instances. 

Hi Kevin,

Thank you for clarifying that you are open to using an MCU. I was thinking that you might prefer a standalone solution, so please let me know if that remains an option you want to explore.

Kevin San Diego said:

The main thing I do not understand is why TI did not put Non-Volatile memory in these battery chargers so that you do not constantly have to rely on having to power on the MCU and then reprogram the charger.

There are several reasons for this, but it ultimately comes down to cost and practicality. In most battery charger applications, the host MCU configures the charger via I2C, which means adding non-volatile memory would only drive up cost and complexity without delivering significant benefits. It's a great question, and while the decision involves multiple technical factors, the primary tradeoff is between cost and functionality.

Kevin San Diego said:

Battery undervoltage, overvoltage, short circuit, overcurrent, Thermal protection for charging and discharging, i.e. our product could see temperatures above 60C and below 20C and needs to know to disable the load from the battery in these instances. 

We have several chargers which integrate many of these protections. However, battery overvoltage is typically handled by the battery protector IC, although we have some parts which integrate it.

Best regards,

Alec

I thought TI had Fuel Gauges that also serve as battery protection ICs, so ideally that chip would use the thermistor and provide both functions. Keep in mind I am using a standalone rechargeable Lithium Cobalt Oxide coin cell so I need to provide all protection functions. 

Hello Kevin,

This question has been assigned and is being reviewed.

Thank you,
Alan

Alan, any update on suggesting part numbers for a battery protection IC and fuel gauge paired with battery charger that can meet my requirements? 

Hello Kevin,

Can you summarize what requirements you need for your fuel gauge to better help you on your search.

Thank you,
Alan