BQ25122: I2C Unstable Operation and SDA Latch Phenomenon below BATUVLO (BQ25122)

As additional information,
even when the battery voltage (VBAT) falls below BATUVLO (approximately 3.0V), if 5V is applied to the charging IC, the physical I2C waveforms can still be observed using analyzers such as Analog Discovery.
However, under these conditions, I2C decoding fails or becomes unstable.

Additionally, when VBAT is around 2.9V and 5V is applied to the IN pin, the I2C SDA line sometimes becomes latched at High or Low and stops responding.
This latch is released when the battery voltage is increased by approximately 200mV.

As additional information, the I2C SDA and SCL lines are pulled up not to the battery voltage but to the microcontroller's power supply voltage used for communication with the charging IC.

Hi Hiroto,

Can you please share waveforms of the I2C communications when they begin to fail? In this waveform can you please include PMID, SYS, or LDO voltage (Whichever may power your Microcontroller's power supply)?

VBAT crossing the BATUVLO threshold causes the Battery Discharge FET to be disabled, which would remove power to the SYS, PMID, and LDO rails. This might be having an impact on any devices that pull power from these rails. We should be able to better narrow down the behavior with the I2C + Rail waveforms.

Best Regards,

Juan Ospina

Thank you for your response.

Regarding your suggestion about the SYS, PMID, and LDO rails: in our circuit, the I2C-related components (such as the microcontroller and pull-up voltage for I2C) are not connected to these rails, so we believe there is no direct influence from these lines.

In fact, the microcontroller's power supply voltage remains stable even as the battery voltage drops, and the power for the I2C bus and the microcontroller does not become unstable. Therefore, for the upcoming waveform sharing, I will provide only the I2C signals (SDA/SCL).

If there are any other signals you would like me to monitor or share, please let me know.

Hi Hiroto,

Thanks for the additional information, we will review and update you probably tomorrow.

Hiroto Yasui said:

When the battery voltage (VBAT) falls below BATUVLO (approx. 3.0V), the physical I2C waveforms can still be observed using an analyzer such as Analog Discovery, but I2C decoding fails or becomes unstable.

I can see from the waveforms you provided there still seems to be I2C communication. For clarification, is your Microcontroller still able to read from the battery charger's register values? Is the issue the I2C decoding of the analyzer only, or is the MCU also unable to communicate?

Hiroto Yasui said:

Additionally, when VBAT is around 2.9V and 5V is applied to the IN pin, the I2C SDA line sometimes becomes latched at High or Low and does not respond.

Can you please provide a waveform of this taking place? I'd like to understand what the I2C Communication lines look like at the point of latching.

Best Regards,

Juan Ospina

Hi,

Thank you for your response and questions.

Regarding the first point:
When using an ST microcontroller with I2C set to 100kbps and the analog filter disabled, I2C errors occur and the MCU cannot read register values when VBAT is in the 2.3V to 2.9V range and 5V is applied to the IN pin. However, if VBAT is lowered from above 3V down to around 2.3V, communication is possible.
Additionally, since there is no CRC, even if the MCU can read data, I consider the data unreliable when Analog Discovery shows unstable decoding.

Furthermore, when I set I2C to 400kbps and enable the analog filter, I no longer experience I2C errors and readings are stable; however, even in this case, Analog Discovery still shows unstable decoding.

Regarding the second point:
As you requested, when starting up at a low battery voltage (around 2.9V), the SDA line appears to latch.
I will provide waveform captures showing:

• A close-up of the latching point
• A close-up when 5V is applied
• The overall startup waveform

Upon re-examination, I found that the actual issue is not that the SDA line is latched high or low, but rather that the charger IC is not returning an ACK.
Previously, I captured a waveform where the SDA line remained low, which led me to describe the phenomenon as a latch.
If the pull-up at 3.0V causes the line to stay low for an extended period, a latch condition could theoretically occur, but in my recent tests, the main issue appears to be the lack of ACK from the charger IC.

I will also submit the previous waveform image where the SDA stayed low.

If you need any additional information or specific waveforms, please let me know.

Best regards,
Hiroto

The battery voltage when SDA enters the latch state (ACK is not returned) varies depending on the device. In other ICs, the voltage may drop to 2.9V or rise to 2.95V.
The figure below shows an image when the battery voltage is 2.9V and SDA is latched to Low. This image was taken in the past, and it is the only image available.

Hi Hiroto,

Thank you for the context. For a bit more clarity:

Hiroto Yasui said:

I2C errors occur and the MCU cannot read register values when VBAT is in the 2.3V to 2.9V range and 5V is applied to the IN pin

The I2C Errors occur only when the 5V VIN is applied and before there is no I2C issues? I would like to try to recreate this behavior, can you please share any register values that may have been configured on the BQ25122 aside from default register values? I will try to see what happens in this scenario. Additionally, can you please share the BQ schematic so I can ensure my hardware set up matches yours?

Hiroto Yasui said:

Additionally, since there is no CRC, even if the MCU can read data, I consider the data unreliable when Analog Discovery shows unstable decoding.

Furthermore, when I set I2C to 400kbps and enable the analog filter, I no longer experience I2C errors and readings are stable; however, even in this case, Analog Discovery still shows unstable decoding.

In this scenario it is difficult to say that the Analog Discovery board's difficulty in decoding indicates that the BQ has unstable communications since it does seem to talk to the MCU. Is there a Logic level setting for the AD board's I2C sniffer?

Hiroto Yasui said:

The figure below shows an image when the battery voltage is 2.9V and SDA is latched to Low. This image was taken in the past, and it is the only image available.

Is there a zoomed in version of this capture available where we can observe individual clock cycles? Also, is there a duration for how long the SDA latch lasts?

Hiroto Yasui said:

Upon re-examination, I found that the actual issue is not that the SDA line is latched high or low, but rather that the charger IC is not returning an ACK.

I agree, there doesn't appear to be ACKs in the capture. Can you please share SYS voltage, and /CD voltage at this time? The device relies on the SYS voltage in order to be able to communicate via I2C.

Thank you,

Juan Ospina

Dear Juan,

Thank you for your questions and comments.

Regarding the I2C errors:
The I2C errors occur only when 5V is applied to the IN pin while VBAT is in the range of 2.3V to 2.9V. No errors occur before this condition.
All register settings of the BQ25122 remain at default values; no modifications have been made.
I will share the BQ25122 schematic separately. Please wait for it.

Regarding the Analog Discovery I2C logic level settings:
I will investigate this and get back to you.

Regarding the zoomed-in image and duration of the SDA latch:
Currently, I do not have a zoomed-in image. If I can reproduce the issue, I will capture and share the waveform showing individual clock cycles and latch duration.

Regarding SYS voltage and /CD voltage:
I will measure and report the SYS and /CD voltages at the timing of the SDA latch (when ACK is missing).

Please let me know if you have any other requests or need additional information.

Best regards,
Hiroto

Hi Hiroto,

Thank you for the added context. I'll attempt to recreate this behavior on bench.

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your questions and comments.

Regarding the first point:
During BatUV conditions, I understand that any register modifications cannot be retained, so the settings revert to their default values each time. Therefore, I will refrain from providing register data. I have attached an image of the schematic.

Regarding the second point:
It appears that the AD (Analog Discovery) hardware and WaveForms software do not have a user-configurable logic level (threshold) setting. The device is basically designed for 3.3V logic signals. However, as shown in the attached waveform, the SYS voltage returns to 1.2V after about 1 second, and I believe that I2C communication is restored to a normal state. Therefore, I do not think that I2C becomes unstable when the battery voltage is below 3.0V. That said, I do notice differences in decoding around 3.0V on the Analog Discovery, so there are still some concerns.

Regarding the third point:
I have not been able to capture a waveform showing the SDA line latched low, so I do not have a close-up or information about the latch duration. However, I was able to capture waveforms including the SYS and CD voltages in the case where ACK is not returned, or when I2C does not work at startup with a battery voltage between 2.3V and 2.9V, so I am attaching those.
In the case where ACK is not returned, the SYS voltage drops from 1.2V to about 400mV before I2C communication, which I believe is the reason why I2C does not work correctly.
In the case where I2C does not work at startup with a battery voltage between 2.3V and 2.9V, the SYS voltage does not drop as much as in the no-ACK case, but it gradually decreases and returns to 1.2V by the end of the initial I2C communication. After that, 1.2V is maintained, and I interpret this as the system returning to a state where I2C can operate normally.

Please note that we have discussed these matters internally, and our reply was delayed due to measurements and holidays.
Additionally, we do not yet fully understand why SYS behaves in this manner.

If you have any questions or need additional information, please let me know.

Best regards,
Hiroto

Hi Hiroto,

I believe the observed behavior is due to the low voltage on VSYS. The SYS rail is used to power some level-shifters inside the BQ25122's I2C engine. Because of it, the I2C is dependent on a SYS good signal that is high when VSYS is within a certain voltage of the configured VSYS regulated voltage. 

It is a bit strange that VSYS is going low when VIN is asserted. I haven't yet been able to recreate that behavior but I'll try to match the waveforms you've provided. Can you share a waveform like the one provided where VSYS goes low after VIN assertion, but please also include VPMID and SW in the waveform? I'd like to confirm those nodes are operating as expected as well.

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your feedback.

Regarding the PMID pin you requested, it is currently set as NC (not connected) in our board design, so unfortunately it is not possible to measure its waveform with an oscilloscope. Therefore, only the SW pin can be measured. Would it be acceptable if I attach a waveform image with only the SW pin added?

Additionally, in our circuit, there are several other pins left unconnected (NC) besides PMID: PG, PMID, RESET, MR, IPRETERM, ISET, and ILIM. If any of these unconnected pins could be related to the observed drop in SYS voltage, your advice would be greatly appreciated.

Thank you for your confirmation and support.

Best regards,
Hiroto

Hi Hiroto,

The SW should provide some context. Ideally the PMID voltage is used to determine at which point in the power path the power failure is present. SW can provide some helpful context as well, but if a PMID waveform is possible it could still provide useful. 

Hiroto Yasui said:

Regarding the PMID pin you requested, it is currently set as NC (not connected) in our board design

Can you confirm that in this scenario there is still a capacitor connected to this pin?

I've been trying to recreate the behavior you've observed without success. I've made note of the following:

- When VIN is asserted, SYS comes up and stays at the default configured regulation voltage regardless of battery voltage.

- I2C communications are still available.

Hiroto Yasui said:

Additionally, in our circuit, there are several other pins left unconnected (NC) besides PMID: PG, PMID, RESET, MR, IPRETERM, ISET, and ILIM. If any of these unconnected pins could be related to the observed drop in SYS voltage, your advice would be greatly appreciated.

These should not be an issue, the only thing I think it might impact is setting ILIM to the default register value of 50mA. Is there a load present on SYS, and how much current is expected to be pulled from that load?

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your reply.

As you pointed out, the PMID pin is not routed out on our board, so it is not possible to measure its waveform. Therefore, I have attached a waveform image with only the SW pin added.

Also, I would like to confirm that we are conducting these tests without any load connected to the SYS and LS/LDO pins.

In addition, no capacitor is connected to the PMID pin.

Thank you for your confirmation.

Best regards,
Hiroto

As additional information, I would like to share the following:

Regarding the phenomenon where the charging IC does not return an ACK on the SDA line when the battery voltage is around 2.9V, we have confirmed that there are individual differences between ICs. In our testing, some ICs stopped returning ACK at 2.95V, while others stopped at 2.93V. Therefore, we are currently increasing the voltage from 2.9V in 0.01V increments to check the behavior.
In some cases, there were ICs where the SDA did not return ACK even when the voltage exceeded 3.0V.

Please note that performing this procedure does not guarantee that the IC will always stop returning ACK.

Hi Hiroto,

Thanks for the added context.

Hiroto Yasui said:

Please note that performing this procedure does not guarantee that the IC will always stop returning ACK.

Can you provide information on the number of units out of the total units tested you are seeing this behavior, and how many attempts need to be attempted in order to recreate the behavior?

There's a couple other item's I would like to discard as well:

- If you have applied a higher voltage / current power source for VIN, are you able to recreate the 2.8V, 2.95V VBAT behavior?

- Can you please provide this waveform at a more zoomed in time resolution, around the initial pulses on VSW? I may be able to use that to determine voltage on PMID at this point.

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your reply.

I would like to provide some additional information regarding your questions:

• This phenomenon occurs on all of the 5 boards we have built (100% occurrence rate).
• If the voltage condition for the phenomenon is met, it happens on the first attempt every time.
• It will take some time to perform the measurement with a higher voltage/current power source for the IN pin of the charging IC, but I will share the results as soon as they are available.
• I have attached a waveform image zoomed in around the initial pulses on VSW as requested.

Thank you for your confirmation and support.

Best regards,
Hiroto

Dear Juan,

This is Hiroto.

I am currently using the BQ25122EVM to check whether the phenomenon we have been experiencing can be reproduced on your evaluation board.

During this process, I have encountered several questions and would appreciate your feedback.

Regarding SYS behavior at startup:
When I apply 5V to the IN pin, VPMID rises to 5V and then immediately drops to 1.2V.
Based on this, I believe that SYS is supplied by the battery voltage immediately after startup. Is this understanding correct?

Regarding the behavior after I2C communication:
After reading register values via I2C communication, VPMID returns to 5V, and SYS voltage also returns to 1.2V.
Can I interpret this as the power supply switching to IN (5V) as a result of the I2C communication?

Regarding SYS voltage drop at startup:
If I leave the board without performing I2C communication, the SYS voltage gradually decreases and drops to 0V after about 13 seconds.
Is this expected behavior when the battery voltage is at BATUV (under-voltage), causing SYS to gradually decrease?

About my hypothesis:
Based on the above, I am considering that performing even a dummy I2C communication when SYS voltage is around 1.2V at startup may switch the supply to IN (5V), allowing stable I2C communication.
I have not tested this method yet, but I plan to modify the firmware and try it.
If this is effective, it may also help avoid the issue where SDA does not return ACK when the battery voltage is 2.95V.

I would appreciate your feedback and confirmation regarding the above points.

Best regards,
Hiroto

Hi Hiroto,

Thanks for confirming this behavior on an EVM. This looks like unexpected behavior to me, unfortunately I haven't had success in recreating it. Can you share some details for the EVM set up including:

- VIN voltage and current limitations.

- VBAT current limitations

- Any load current present on VSYS or VPMID, and how much load current is being pulled there.

PMID going low after a VIN assertion is indeed unexpected. To address some of your questions:

Hiroto Yasui said:

Based on this, I believe that SYS is supplied by the battery voltage immediately after startup. Is this understanding correct?

SYS is supplied from VPMID. In this scenario, I believe it is expected that VPMID should be supplied by VIN. Can you capture this waveform and include the /PG pin to ensure that the device registers VIN as a valid source?

Hiroto Yasui said:

Can I interpret this as the power supply switching to IN (5V) as a result of the I2C communication?

I don't think is necessarily the case. I2C communication shouldn't necessarily cause a switch to VIN. One thing that does take place upon the first I2C communication is a switch from "READY" mode to "HOST MODE". The main difference between these two modes is an ISET / ILIM / IPRETERM reliance on external resistors vs register values. Are these Resistors the default EVM populated resistors in your EVM testing, or have they been altered?

Hiroto Yasui said:

Is this expected behavior when the battery voltage is at BATUV (under-voltage), causing SYS to gradually decrease?

If VIN is present to power the board, and is not limited by VINDPM or some other safety feature then this is not necessarily expected. 

Hiroto Yasui said:

Based on the above, I am considering that performing even a dummy I2C communication when SYS voltage is around 1.2V at startup may switch the supply to IN (5V), allowing stable I2C communication.

Based on your observations, this presently looks like a viable workaround.

I did notice from your waveform captures that the procedure seems to be a BAT assertion at 2.95V followed by a VIN assertion about 2 seconds later. I don't expect this would make a difference but I'll continue to try to recreate the behavior in lab. I have swept VBAT from 2-3.5V at 5 mV steps with VIN assertion / deassertion cycles on a couple boards now without any luck. Please let me know if any modifications or jumper configurations have been made to the EVM.

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your response. Please find below the requested information regarding our setup:

• VIN voltage and current limitation: 5V, 1A limit (configured via power supply)
• VBAT current limitation: 20mA limit (configured via power supply)
• Both VSYS and VPMID are connected only to an oscilloscope and are otherwise unloaded (no additional load).
• Regarding your request to capture the waveform including the /PG pin to confirm that VIN is recognized as a valid power source: currently, the /PG pin is NC (not connected). Could you please advise what it should be connected to for this measurement?
• The ISET / ILIM / IPRETERM pins on the EVM are also NC (open), set this way to match the condition of our custom board for direct comparison.
• The only modifications made to the EVM are that the /PG, ISET, ILIM, and IPRETERM pins are left NC.

Please let me know if you need any further information or have specific instructions.

Best regards,
Hiroto

Hi Hiroto,

Hiroto Yasui said:

The ISET / ILIM / IPRETERM pins on the EVM are also NC (open), set this way to match the condition of our custom board for direct comparison.

Thank you for this context. Given the dependance on I2C transaction, I believe this might be related to the cause of the behavior we're observing. I'll modify my board and try to recreate the behavior as described.

Hiroto Yasui said:

currently, the /PG pin is NC (not connected). Could you please advise what it should be connected to for this measurement?

This pin should be available on the BQ25122EVM. A pin on the J6 jumper is available so that it can be externally biased via pull-up resistor R9:

Best Regards,

Juan Ospina

Dear Juan,

Thank you for your response.

Based on your advice, I tested the evaluation board with the ILIM, ISET, and IPRETERM pins connected to GND, and as a result, the voltage drop issue on PMID and SYS did not occur.

Interestingly, even when only one of these pins, such as ISET, was connected to GND (with the others left open), the issue did not occur either.

Since your previous reply indicated that the limitation of the ILIM pin is the main cause, I would have expected the issue to persist unless ILIM was connected to GND. However, it seems that connecting only one of the pins to GND also resolves the issue. If you have any insights as to why this might be, I would greatly appreciate your advice.

Thank you for your continued support.

Best regards,
Hiroto

Hi Hiroto,

I believe this might be related to the way the charger detects GND shorts on the ILIM/ISET/IPRETERM pins. The ILIM is just the primary theory since it seem to be the most likely to cause this behavior, but I can look into why the other pins might have an impact. Ultimately, it is advised that these pins are either populated with a known value resistor or shorted to GND for default register value configuration, it's not advised to leave them floating.

Best Regards,

Juan Ospina