BQ76930: I2C becomes unresponsive

Hi Nicolas,
You should figure out what is happening and prevent it. Looking at the condition of the I2C bus, ALERT, and regulator outputs may give some indication also.
If the filter caps are too small or the load to large for your cells you can pull the part into the VSHUT region which is undesired. If the part shuts down you should be able to boot it.
If the I2C bus is noisy you can get extra clocks and have the slave hold the bus. The standard I2C method to clear the bus is to have the host send up to 9 clocks until the slave releases the bus.
If you have transients exceeding Abs Max, prevent them.
In the lab you can short across the CAP1 cap, then re-boot, but it is not a reset.

Hello, thanks for the response. We were trying to implement the i2c bus reset, but as soon as we reset the MCU for flashing it, the i2c started to work again. We will try to test your solution if we find the issue again.

However, in another battery that presented this issue 2 times before and the cells were disconnected and reconnected again to reset it, and a couple of times we also noticed that the BQ76930 was succesfully responding to the i2c command for getting the temperature and cell voltages, however, the values of the temperatures were wrong, and also the values of some cells had been stuck within some old range (we saw the reported values changing over time, but the voltage was way off from the reality) , again after disconnecting the cells and reconnecting them again, the temperatures and cell voltage reported fine.

Finally, yesterday, we were charging that battery and suddenly started to burn itself until all 10 cells caught fire and destroyed.

We suspect that one cell went to short circuit and its temperature started to rise while charging, however we didn't get any i2c error, nor over voltage or over temperature, since we didn't get any i2c error, the MCU we believe that the BQ76930 got the temperature and cell voltages stuck again and therefore the BMS believed that everything was normal even when the temperature was rising to the point of ignition.

Can you comment on this, what could be the cause of the internal ADCs of the BQ76930 got stuck like that?

We've observed in another battery with the cell voltages stucks the ADC_EN bit on register SYS_CTRL1 cleared himself. we don't have anything in the firmware on the MCU that could clear the ADC_EN bit, also it seems unlikely that an i2c noisy line could change this since all the i2c communication has a CRC.

What could be the reason why this ADC_EN bit is cleared?

Hi Nicolas,
That must have been quite dramatic. You really must find out what is going wrong.
If the ADC is turned off it will not collect new voltage and temperature. If the part gets an XREADY fault it will not report new voltages in the registers although ADC_EN may be set. If the Temp_Sel bit is cleared it will report the IC temperature voltage rather than the thermistor voltage.
The part does not turn off ADC_EN unless it loses power. XREADY can also be set due to loss of power. Normally the FETs are turned off with XREADY so there can be no charge or discharge when the voltages are not known. If the host turns off the ADC it can turn on FETs. Of course the FET controls may not be used in the system design.
If power is lost and the part is re-booted the ADC_EN is set by default. The host must turn it off.

While you have nothing intended in the firmware which turns off the ADC, the host is in control. Find out what communication is being set to the bq76930. You should also check power to the part in system operation. Sys_Ctrl_1 register also has the TEMP_SEL bit which enables the thermistor measurements. If either bit is set low the thermistor will not be enabled. Pulses are every 2 seconds. If you see the thermistor pulses stop you know something has changed. It is infrequent, but it is an observable signal.

Thanks for the response.

We checked the XREADY fault and it wasn't reporting any fault. Also, we always have the TEMP_SEL set to measure the external termistor.

Is there a voltage band where the ADC_EN is cleared but the XREADY is not set? In the last battery we saw the ADC_EN cleared, I don't think the part has lose  power.

We've checked all the i2c commands sent from the MCU and we haven't find anything that indicates that the MCU could have cleared the ADC_EN.

However we might have found a mistake in the schematic that could introduce some transient voltage outside the absolute recommended for the cells. For booting the circuit when the cells are deeply depleted (when the voltage of the cells is not enough to turn on the BQ76930) we added a path from the charger to the BAT pin similar to the path from the VC10 to BAT pin, and also for the VC5x. (See the attached picture).

Before the charger is connected the layers are off disconnecting the cells from the charger port, the voltage in teh BAT is the voltage on the VC10 and the voltage in VC5x is the voltage of VC5, as soon as the charger is connected, the charger will put 42V in BAT and 21V in VC5x (this voltage drops due to some resistor paths connected through VC5B and the cells 5) until the BQ76930 can produce the 3.3V to the MCU which is going to turn on the layers allowing the charger start charging the cells, at this moment the charger will adjust its voltage to charge the cells with 2 or 3 amps (depending on the charger). However, while the MCU is OFF and the charger is connected, the VC5x pin could have a voltage higher to the VC6 (and possibly also VCn where n=7,8,9 and 10), meaning that the voltage VC6-VC5x could be less than the absolute minimum which is -0.3V. We know already this is a mistake and we have already changed the design to prevent this situation, however we would like to know if this could be the cause of the ADC_EN clearing himself?

We will implement a firmware mechanism in the MCU to check the ADC_EN to see if it is cleared and reactivate it again, but we would like to know if there's anything else we should consider.

Also, can you please clarify this sentence: "If either bit is set low the thermistor will not be enabled. Pulses are every 2 seconds. If you see the thermistor pulses stop you know something has changed. It is infrequent, but it is an observable signal."

Which bit are you refering? ADC_EN and TEMP_SEL?

Thanks

Hi Nicolas,
Thanks for the insight from the schematic.
If you exceed abs max it may have no effect, may reset, may malfunction, or may be damaged. Reset would set ADC_EN, so you would seem to be getting a malfunction.
The bq76930 was designed with the concept that cells with an extreme discharge should not be re-charged. If the cell voltage is too low to boot the part won't work. Perhaps your MCU will use the bq76930 as a sensor when voltage is adequate. I'm sure you will find a good solution.
"Which bit are you refering? ADC_EN and TEMP_SEL?" Yes, either one low will stop the temperature sampling on the TSx pins. If TEMP_SEL is low the external pins are not sampled, the internal temperature voltage is sampled instead if TEMP_SEL is low and there is no indication. If the ADC_EN is low while TEMP_SEL is high the part knows it does not need to measure the external temperature and the pin does not go high. If looking for the temperature samples remember the amplitude will vary with the temperature.