BQ27530-G1: Query on GG_CHGRCTL_ENABLE command

Hi Mythili,

Looping in a Chargers expert for their input on what could be causing this change in Vsys. 

Regards,

Anthony Baldino

Hi Anthony,

Hope we will be getting earlier response from charger experts

Warm Regards,

Mythili B

Hey Mythili,

Today's a federal holiday so no one is in the office. We will get back to you tomorrow.

Regards,
Nick Richards

Hi Mythili, 

Thank you for your patience as our response was delayed due to the holiday. Please see my comments regarding BQ24161B charger below. 

The difference between using IN input path and USB input path is the input current limit. As the datasheet mentions on page 1 USB input is rated up to 1.5A whereas IN input is rated up to 2.5A. When operating from USB input the status of PSEL pin will determine if input current limit is 500mA or 1.5A. 

For your situation what is likely occurring is the output load current is sometimes a value which causes the input current limit to be reached when operating from USB input, but not IN pin input.

As I am not the gauge expert I am not sure exactly what charger IC register settings are being modified when CMD_NOT_REQ is set, but my best guess based off the current information is that input current limit for USB input is being reduced. This then results in VSYS dip when load current is too high relative to the input current limit. 

Best Regards,

Garrett 

Hi Garrett/ Anthony,

Thanks for your response

Since our load is not taking more current I feel this could not be because of input current limit issue. So, for clarification I have connected resistive load to the SYS terminal.

Here are few observations,

Note : Observations are made without connecting battery

1) When CMD_NOT_REQ  bit is set & given 5V,500mA(from RPS) in USB path, observed voltage dip till 2.4V in VSYS for 270mA resistive load(~12E), because of this dip our product is going to reset state.

2)  When CMD_NOT_REQ  bit is set & given 5V,500mA(from RPS) in IN path, observed no major dip in VSYS path when applied same load. Our product is working fine

3) Without setting CMD_NOT_REQ bit and GG_CHGRCTL_ENABLE option & given 5V,500mA(from RPS) in USB path observed no major dip in VSYS path when applied the load(~12E)

4)Without setting CMD_NOT_REQ bit & given 5V,500mA(from RPS) in USB path and applied load to SYS terminal then given GG_CHGRCTL_ENABLE option , observed voltage dip till 2.16V in VSYS

As per the above observation, when Fuel Gauge acts as a host for Battery charger, VSYS voltage dips when USB path is used.

Please let us know what could be the reason for this issue, Also attaching the .gg file for your reference

Data_flash.gg.csv

Warm Regards,

Mythili B

Hi Garrett,

Sorry, by mistake "This resolved my issue" was given. Actually the issue still persists

1) Charger register details without enabling fuel gauge as a host for the battery charger(refer the below image)

2) Charger register details when fuel gauge acts as a host for the battery charger(refer the below image)

Warm Regards,

Mythili B

Hi Mythili, 

Thank you for providing the register details for both scenarios. 

I have reviewed and cannot determine a clear reason for the difference in behavior based on the configuration differences. I am going to conduct some additional lab tests and will provide an update early next week. 

In the mean time do you happen to have a current probe or an alternate way to measure current? I am interested in seeing a waveform showing USB voltage, input current, and VSYS for the scenario where VSYS voltage dips. 

Best Regards,

Garrett 

Hi Garrett,

I don't have current probe for current measurement, so I could not able to send you the required waveform

It would be helpful if you send in your response as early as possible

Warm Regards,

Mythili B

Hi Mythili, 

Mythili Balakrishnan said:

I don't have current probe for current measureme

Okay understood. Please see my recommended next step based on additional research below. 

A difference in configuration when the fuel gauge acts as host is in REG02. The screen capture of the GUI shows charge termination and charge are disabled ( bit 2 TE = 0 & bit 1 CE = 1). In my lab tests attempting to replicate your setup of USB input with no battery I can observe SYS with an approx. 270mA load drop if charge termination is disabled while charge is still enabled. 

My recommendation is to try having the host write to REG02 in two messages rather than 1 to ensure bit 1 setting CE = 1 ( charge disable) before setting bit 2 TE = 0. Alternatively, you can try only disabling charge and leaving bit 2 TE at default setting (TE = 1). 

Please let me know if this software/configuration change resolves the VSYS drop behavior. On my board when charge is disabled first I never observe the VSYS drop behavior. 

Best Regards,

Garrett 

Hi Garrett,

Thanks for your reply.

Actually we are trying to implement Fuel Gauge and battery charger to work in standalone mode , so mostly we will be setting CMD_NOT_REQ bit(Fuel Gauge will act as a host for the battery charger)

In BQSTUDIO application for REG02, bit 1 and bit 0 is mentioned as reserved(refer the below image)

Even though we have given the default value should be 0x2C(charge enabled & termination enabled) for Reg02, it is updating to 0x2A(charging disabled & termination disabled) when battery is not present

So how can we make sure to disable charge first then to give termination disable through register settings without any control to the fuel gauge

Warm Regards,

Mythili B

Hi Mythili,

We would typically recommend not to alter bits that are reserved within the gauge data flash. I believe the charge current termination bit is controlled by the fuel gauge charging algorithm which could be why it resorted back to being cleared when the battery was not present. The charger enable be able to be changed using the CHG_ENABLE and CHG_DISABLE commands.

Regards,

Anthony Baldino 

Hi Anthony,

Is there any way to avoid  VSYS dip by without giving CHG_ENABLE and CHARGE_DISABLE command externally

Because when we were using USB path without battery, our processor will go to reset state, so we cannot give CHG_ENABLE and CHG_DISABLE command externally from processor(which is already in reset state)

Please let us know how can we proceed on this

Warm Regards,

Mythili B

Hi Mythili,

We believe an option that could be implemented is to alter the host control of the gauge before the cell is removed from the system. When the cell is removed, it is not possible to communicate with the gauge, and for the gauge to send out instructions to the charger.

If the cell is going to be removed, the host control of the gauge can be disabled using the GG_CHGRCTL_DISABLE command and reenabled using the GG_CHGRCTL_ENABLE command once the cell has been reinserted. If this option is implemented, please be sure to clear the CMD_NOT_REQ bit since this is a prerequisite for these commands to be used.

Regards,

Anthony Baldino