BQ34Z100-G1: Battery Disconnect / BQ Reset Detection

Andrew Jowsey1

Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQ34Z100-R2, BQ34Z100, GPCCHEM, EV2400, BQSTUDIO, BQ34Z100EVM, BQ40Z50

Hello,

I have a fleet of devices using the BQ34, and I suspect we are having battery issues because we detect a reset on our microcontrollers, and the BQ's coulomb counter almost seems to be reset because after the real SOC of 20% shoots up to the incorrect SOC of 100%. For the next 24 hours, the BQ will report a declining SOC of 100 -> 92%, and at the exact 24-hour mark, it shoots back down to ~20% as expected and stays there.

Are there any registers that I could use to detect that a power cycle of the whole device has occurred? I am assuming that the non-persistent algorithm used to determine SOC is being cleared, which causes a really rough estimate for the next 24 hours. To detect a reset, checking things like charge cycles or discharge cycles doesn't feel very reliable. Also, I thought maybe the CF flag would help, but it doesn't seem to change when I power cycle my desk device.

Thanks,

over 1 year ago

0 Diego over 1 year ago

TI__Mastermind 27555 points

Hi AJ,

In the TRM linked below, I believe "Data_Reset" (2.1.1.5) is what you're looking for.

BQ34Z100-G1 Technical Reference Manual (Rev. A) (ti.com)

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Hey Evan,

I tried this too but the value is stuck at count 49.

Regardless if I power cycle the device. Code is here just in case.

int BatteryMonitor::resetData()
{
   uint8_t Reset_cmd[3] = {0x00, 0x05, 0x00};  // soft reset the order of the bytes is reversed
   Wire.beginTransmission(BQ34Z100_ADDR);
   Wire.write(Reset_cmd[0]);
   delay(10);
   Wire.write(Reset_cmd[1]);
   delay(10);
   Wire.write(Reset_cmd[2]);
   Wire.endTransmission();
   Wire.requestFrom(BQ34Z100_ADDR, 1);
 
   int resetDataByte = Wire.read();
 
   return resetDataByte;
}

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

Can you send me your log file so I may look into this further.

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Sorry a log file of what?

Line 15 just returns decimal 49 continuously

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

I meant the .gg file, sorry for the confusion.

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago

Prodigy 20 points

Diego

I was able to make the firmware work and get the reset count we will see if that helps.

Regarding the 24 hours of bad data, does the remainingCapacity() improve or change anything in the algorithm at the same interval?

Here is my fixed code:

int BatteryMonitor::readResetCount()
{
   uint8_t Reset_cmd[3] = {0x00, 0x05, 0x00};  // soft reset the order of the bytes is reversed
   Wire.beginTransmission(BQ34Z100_ADDR);
   Wire.write(Reset_cmd[0]);
   delay(10);
   Wire.write(Reset_cmd[1]);
   delay(10);
   Wire.write(Reset_cmd[2]);
   Wire.endTransmission();

   delay(30);

   Wire.beginTransmission(BQ34Z100_ADDR);
   Wire.write(0x00);
   Wire.endTransmission();

   Wire.requestFrom(BQ34Z100_ADDR, 1);
   int resetDataByte = Wire.read();

   return resetDataByte;
}

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi Andrew,

I will have to consult the firmware team about this question please allow me some time.

Regards,

Evan

0 Diego over 1 year ago in reply to Diego

TI__Mastermind 27555 points

Hi Andrew,

Can you share your .srec files with me?

Please expect a delay in responses due to US holidays.

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Please find attached :)

https://drive.google.com/file/d/15oBQY_CrN2xlWDIoXUBiKZzCp62dQUCu/view?usp=drive_link

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi Andrew,

The problem you are having is similar to a bug on the BQ34z100-R2 FW. Can you confirm the -G1 FW is uploaded to the gauge.

On the G1 FW there are no parameter that resets every 24 hours.

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Hey Evan,

Every device I've checked says it's on 0.16 and that version is from 2015.

Are we potentially effected then? Which bug/errata are you thinking of? Im assuming one of the changes in the release notes between 0.16 and .20

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi Andrew,

You are using the correct (-G1) FW.

FW changes are listed here. bq34z100_v2.02.00.31 Release Notes

Prior to having this problem did you use the GPCCHEM tool and complete a successful learning cycle?

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Hey Evan,

Yeah we have been doing our own training cycles etc for the past 4 years. Had to retrain per battery supplier change but it has been pretty rinse and repeat.

Not all devices experience this problem either it seems.

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi Andrew,

That is good to hear. When you say "not all devices" do you mean not all BQ34z100s tested or not all TI gauges tested?

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

I just mean not all devices with the same .srec and firmware have gigantic jumps in SOC for 24 hours. Lots of devices correctly get SOC continually.

- AJ

0 Andrew Jowsey1 over 1 year ago in reply to Andrew Jowsey1

Prodigy 20 points

In addition, is there a way for flash newer firmware via i2c on a remote IOT device?

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

How may devices have you seen this problem occur on? Is it possible the unit you are testing on may have been damaged?

Yes, more information in the document provided Gauge Communication

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

This document is exactly what I wanted <3

We have had up to 50 devices with issue. We currently trying to see if a battery batch is related but it seems incredibly random

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

Please let me know if you find anything related to the batter batch.

In the meantime, I will consult my team about your issue.

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Sounds good Evan. For your information, I am gonna prioritize the feature development of updating our bq fw for these failing remote devices. To see if they improve. Let me know if you think upgrading the fw is a moonshot idea.

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Hey Evan,

I tried downloading the latest and greatest bq.fs file but it doesnt seem to be included in the exe from this link: https://www.ti.com/tool/download/BQ34Z100-DEVICE-FW/2.02.31

Im assuming I need a bq.fs to update the firmware based on this from your gauge communication application note:

0 Andrew Jowsey1 over 1 year ago in reply to Andrew Jowsey1

Prodigy 20 points

I also tried using the srec from the exe but it didnt change the fw_version from x16 to anything

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

Can you send us the 24+ hour log file of the SOC jump error occurring.

This FAQ may help.

(+) [FAQ] BQSTUDIO: What is the TI BMS Flashstream file format? - Power management forum - Power management - TI E2E support forums

Regards,

Evan

0 Andrew Jowsey1 over 1 year ago in reply to Diego

Prodigy 20 points

Hey Evan,

I mean I tried flashing the new firmware using BQStudio and the Ev2400 to a normal device using the .srec from that exe since thats the only usable flash file in it.

But after clicking flash in the "programming" part of BQStudio, it ran for 2 seconds and said it was flashed but the FW_VERSION command in the UI still returns 0x16.

I am trying this with the EV2400 and BqStudio for the time being to see if we can validate the improvement before developing a remote application which would be parsing and applying the file stream contents over i2c.

RE: LOG

I can get you a log remotely using a random non standard format us using remote i2c captures, or I can take some to have a customer return a device and get the bq studio captured log. Either okay?

Thanks a ton for the fast response :)

0 Diego over 1 year ago in reply to Andrew Jowsey1

TI__Mastermind 27555 points

Hi AJ,

It sounds like your gauge may be in ROM mode and did not execute the FW.

Here's a trick to verify,

First connect the SMBus port on the EV2400 to the i2c port on the BQ34z100EVM.

Then select bq40z50.bqz.

Then in read 0x02 from target address 16

If you receive a value greater than 100 you are in ROM mode

The bqstudio capture log from return device will be better.

Regards,

Evan