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.

BQ78Z100 reset on continuous I2C register refresh while charging/discharging

Other Parts Discussed in Thread: BQ78Z100

Hi,


we have severe problems while refreshing the registers of the BQ78Z100 via I2C. We observed that the BQ frequently stops charging/discharging by deactivating both of its FETs. The effect first seems to be randomly happening, but we managed to produce an environment which can reproduce the error:

System Configuration

  • BQ78Z100EVM  (alternative our own Battery Module based on the BQ78Z100EVM)
  • MCU connected to the BQ I2C interface (I2C running at 100 kHz)
  • 2x 450 mAh LiPo cells connected to the BQ78Z100EVM
  • 8.5 V power supply connected to PACK+ / PACK - on EVM board for charging
  • Test SW on the MCU which runs only a single test applicatoion:
const uint32_t TestDly = 250;
	
void getGaugeStatus () {

	int16_t voltage = 0;
	int16_t current=0;
	int16_t remaining=0;
	int16_t full=0;
	int16_t soc=0;

	I2CRegRead (BQ_I2C_SLAVEADDRESS, VOLT, 2, (uint8_t *) &voltage);
	delayUs(TestDly);
	I2CRegRead (BQ_I2C_SLAVEADDRESS, INSTCURR, 2, (uint8_t *) &current);
	delayUs(TestDly);
	I2CRegRead (BQ_I2C_SLAVEADDRESS, RM, 2, (uint8_t *) &remaining);
	delayUs(TestDly);
	I2CRegRead (BQ_I2C_SLAVEADDRESS, FCC, 2, (uint8_t *) &full);
	delayUs(TestDly);
	I2CRegRead (BQ_I2C_SLAVEADDRESS, SOC, 2, (uint8_t *) &soc);
	delayUs(TestDly);

	return;
}

void chargeBatteryTest () {

	deactivateDsgFET ();
	deactivateChgFET ();
	for (int i=0; i< 100; i++) {
		getGaugeStatus ();
	}
	activateDsgFET ();
	activateChgFET ();
	for (int i=0; i< 100; i++) {
		getGaugeStatus ();
	}

	while (1) {
		getGaugeStatus ();
		delayUs(TestDly);
		uint32_t safetyStatus = readStatusReg(SAFETY_STATUS);
		delayUs(TestDly);
		uint32_t safetyAlert = readStatusReg(SAFETY_ALERT);
		delayUs(TestDly);
		uint32_t pfStatus = readStatusReg(PF_STATUS);
		delayUs(TestDly);
		uint32_t pfAlert = readStatusReg(PF_ALERT);
		delayUs(TestDly);

		while( (safetyStatus != 0) && (safetyAlert != 0) && (pfStatus != 0) && (pfAlert != 0) ) {
			getGaugeStatus();
		}
	}
}

Test Procedure

  1. Power supply off
  2. Start MCU
    • read BQ status registers
    • activate charge/discharge FETs
    • continuously read the BQ status registers via I2C
  3. Wait ~ 30 seconds ==> OK
    • no errors occured
    • read status registers works fine
    • battery voltage present @ PACK+/PACK- contacts due to active FETs --> OK
  4. Activate Power supply providing 8.5 V 200 mA charge supply
  5. Wait 1 - 10 seconds ==> ERROR

Error Behavior

  • After the above testing procedure the BQ does not respond on the I2C bus anymore
    • no action on SDA lane (neither ACK nor data transfer): SDA lane stays high due to pull-up whenever BQ has SDA control
    • no attempt to hold SCL lane low to throttle bus speed
    • non responding BQ may appear at any stage
      • within transfering a read byte from BQ to MCU
      • after a successful completion of a read/write bus transfer
      • while writing the register address to the BQ
  • BQ deactivates the charge & discharge FETs
  • After a certain time (not further evaluated at this point) the BQ continous to respond normally to any I2C requests
  • The charge & discharge FETs stay disabled
  • The FETs can be re-activated via I2C again

Error Analysis

  • Increasing the delay (TestDly) between 2 consecutive I2C register reads reduces the probability of this error
    • When I run the Test with the Battery Management Studio & the EV2300 adapter I could not reproduce the error (but I noticed a delay of ~14ms between 2 reads)
    • However I have not found any hint in any datasheet about any delay requirements except the "bus free time between stop and start" of 1.3 us (which we do meet of course)
  • The error was never observed when no charging current was provided
  • I have captured the activity on the I2C bus during the error:
    • normal i2c read
    • I2C Bus behavior during error

  • I personally have the following theory:
    • There is a watchdog present on the BQ
    • Is it possible that due to continous I2C read request the keep the BQ so busy that it violates the watchdog reset interval which in turn causes a full reset causing all FETs to get deactivated?

My collegue Philipp Schmidbauer already has asked for a service request at your stand at the Electronica in Munich 2 weeks ago, but never received any answer.


I would highly appreciate any help on this topic as it is a absolut kill criteria for our application, i.e. you can't build a UPS which accidently resets itself and thus turning the full system off. That's not what I would commonly call a "uninterruptable power supply"!

  • Hi Fabian,

    Sorry for delay - most of our team is out on holiday this week, we'll try to follow up when back in office.

    Thanks,

    Terry
  • Hi,

    any news on this topic?

    best regards,
    Fabian
  • Hey Terry,

    we still have no sollution for this problem. Since this chip is a fixed part in two of our systems this problem represents a big blocker for us! We would appreciate any help.

    Best regards,
    Philipp.
  • Hi Terry,

    it is now more than 1 month since I started this topic and I haven't got any responce from your side or from any other TI Employee.

    Is there anybody working on this topic? Do you need any further information?

    I mean this is a serious problem having a battery gauge which accidently performs a reset.
    I would have expected at least a minimum amount of intereset from TI to solve that issue.

    I'm looking forward to any responses

    best regards
    Fabian
  • We apologize for the delayed response to this. It appears this fell through the cracks due to the holiday period.

    Your theory on the watchdog reset is correct. you should not try to continuously access the gauge as most updates within the gauge occur every 1s at a minimum.

    I recommend you introduce a delay of  atleast 100ms between transactions and atleast 66uS between two byte writes. Our other i2C

    gauges have this section included in the TRM, but it appears the 78z100 is missing that.

  • Thanks for the answer!

    I could verify this. After adding the delay of 66 us after each I2C transaction on the BQ I haven't seen any problems anymore.

    Onyx Ahiakwo said:

    I recommend you introduce a delay of  atleast 100ms between transactions and atleast 66uS between two byte writes.

    What do you mean with you recommend at least 100ms ?

    Is it just because the status registers only get updated every 1s? Or are there any known issues with a delay of only 66us after transactions?

    Thanks

    Fabian

  • Yes, registers only get updated every 1s. For some customers due to the frequency of their clocks of their i2c engine, 66uS doesn't always work. In cases like that increasing that 66uS typically works.

    thanks

    Onyx

  • How does it behave with incremental read of Standard command registers?

    The extract of the datasheet you posted is a bit unclear to me:

    Onyx Ahiakwo said:

    but the host must not issue any standard command more than two times per second. Otherwise, the gauge could result in a reset issue due to the expiration of the watchdog timer.


    Does this mean:

    1. The same command must not be issued more than 2 times per second
    2. Not more than 2 different (and/or the same) standard commands must be issued per second
    3. Not more than 2 read transactions must be issued per second, i.e. incremantal reads are OK?

    Which brings me to my question:

    Is it possible to read the full set of Standard commands (SLUUB63A Table 12-1) within a single incremental read without causing the watchdog to trigger?

    What is the limit of a incremental read on standard command address without causing the watchdog to trigger?

    Kind regards

    Fabian

  • the same command must not be issued more than 2 times per second because the gauge does updates just once per second so it is redundant trying to read back the same command twice.

    Is it possible to read the full set of Standard commands (SLUUB63A Table 12-1) within a single incremental read without causing the watchdog to trigger?
    Yes it is possible to read back the full set of standard commands in one second. introduce a delay of 66us between commands though to ensure you get correct readings.

    there is no limit...just ensure you have delays between commands.


    thanks
    Onyx