BQ34Z100 vs. BQ34110

Hi Mark,

Do you have a log from the gauge capturing the charge, discharge and rest periods? If not please run the cycles with bqStudio logging enabled.  We will be better able to assist you once we have the details from the log. What chemID you're using for the cells? Most times OCV measurement isn't taken if the dV/dt > 4uV/s. What is the flash update  OK cell voltage set to? Can you export a gg.csv file for us to review your gauge settings?

Most likely the bqStudio PB_RESTART is correct. I'm checking on the functionality of the bit.

Do you have a smart charger that can communicate with the gauge? The charge parameters are for providing cell info to the smart charger when the charger is connected. I can provide more details on these parameters, if you're interested and it's applicable to your application.

bq34110 can be used as a CEDV gauge for frequently cycled applications. It also has a feature for determining End of Service for rarely discharged applications.

Thanks for the prompt reply, Damian,

I have set the discharge rate at ~C/8, attached is the last D/C log.  The log records every 4 sec but you will notice an idiosyncrasy in the file; every other entry generated an error and is probably not reliable (attached file).  The error log has an "No acknowledge from device" entry every 8 sec.

Attached also is a .gg file.

I left the FlashUpdate at the default of 2.8V, I will drop it to below the Cell Term Voltage (1.7V) to say 1.5V; thanks very much for catching that.

I will change the FlashUpdate value and run both a D/C followed by a Chg but this will take a couple of days.  Please note that Learned Status (4) did not change, UpdateStatus =4 and the Max Error remains at 100% but the gauge seems to be working.

I appreciate the update on the bq34110, any ideas about release date and EVM?

It would probably be valuable to the community to put in the bqStudio documentation a notice that if it is NOT "run as administrator" all sorts of irritating problems arise (like not being able to read the flash) at least on my system: Win 10, bqStudio 1.3.52.

Thanks again,

m

Hi Mark,

The log and gg files weren't attached. Setting the Flash Update OK voltage to 1.5V/cell, since you have 6s cells. Always ensure REGIN voltage is above 2.7V  for flash writes. If it falls  between 2.7V and 2.45V, flash writes will be prohibited.

Thanks for the info on Win10 issue with bqStudio.

bq34110 should be released at the end of this month and EVMs will be available the same time.

Sorry Damien, I was a file attaching klutz.  I hope I got it this time.

I am using the EVM so the Voltage on the part is about 4V and the divider is set for 16V.

I am now a little confused about Flash Update OK Voltage.  If I do the arithmetic from the data sheet:

Flash Update OK Cell Volt = 1700mV * 6 * 5000 / 16000 = 3187mV which is above 2800mV so shouldn't I be OK?

Thanks for the help,

m

Nov 8.log

Hi Mark,

I will review your log file in detail tomorrow. I'm assuming you did a calibration and since you're in the 16V range setting the divider voltage should be around 19200mV, not 16000mV as you used in your calculation above, which is 2684mV. You can get the voltage divider value the gauge is using from bqStudio >> Data Memory >> Calibration.

Thanks for the catch, Damian.

I think that this part may have one of the steepest learning curves ever.  I ran a complete dsg/chg cycle that I can send you with really the same results Update Status didn't bump and Max Error is 100%.

I have had bqStudio melt down and need to be reinstalled twice, I saved the log files (C:\ti\BatteryManagementStudio\workspace\.metadata) if anyone there wants them.

Hi Mark,

I know it seems very challenging now, but we will work through it and get you on your way to being the expert. Send me your latest log.

Good Morning Damian,Nov 10.log

Attached is the discharge followed by charge log file.  Thanks for helping me through this.

Hi Mark,

There's something wrong with the latest log file Nov10.log. The column labels are missing. I'm unable to track the sequence of the voltage and current data. Do you have another log file like Nov8.log?

Sorry Damian,

Likely a screw-up on my end.  I opened this file her with Excel and it looked OK (at least from a format perspective).  I will attach it again and hope for the best.  Yesterday, the uploading seemed odd sending it from home.  I will also start another cycle now.

m7024.Nov 10.log

Hi Mark,

Here's what's needed in the log file.

1. Turn on logging
2. Charge battery to full (max cell charge voltage) with C/2 rate
3. Relax battery for 2hrs or OCVTAKEN bit is set (need to setup quit current parameter in DF for Relax mode)
4. Discharge with C/20 rate to empty (cells discharge termination voltage)
5. Relax battery for 5hrs or OCVTAKEN bit is set 
6. Charge battery to full (max cell charge voltage) with C/2 rate
7. Relax battery for 2hrs or OCVTAKEN bit is set
8. Turn off logging 

Hi Mark,

Have you tried plotting the current/voltage vs elapsed time? The data seems still screwed up. 

Hi Damian,

Thanks for the valuable input.

I am starting over.  I discovered that bqStudio must be installed in the "program files" directory on Win 10 (64bit).  It appears to work on other directories but not reliably.  You may want to tell the tool guys along with the "run as administrator".  It seems as though it can't find its plugins.

I have a new EVM that I am about to put into service and will record a complete cycle with a hopefully well behaved bqStudio.  I have gone through every parameter from scratch.  I still don't know what to do with PB_RESTART bit in Pack Config.  I am checking through things carefully before starting.

By doing the C/20 rate it will take a couple of days to record.   I have done C/8 before, is that OK?

So expect new logs in a bit.  I appreciate your hanging in with me.  Would it be better to email than post here?

m

Hi Mark,

We are aware of Win10 requirement to run as Admin. Most people don't change the default install directory, so may not have encountered this problem. I guess we should remove the option.

C/8 should be ok, but C/20 is better.

You're welcome and my hope is to get all your concerns resolved and well on the way to being more an expert on bq34z100-G1. Let's continue to post here and if the info start getting confidential, we can use email.

Hi Damian,

I am stuck now. I had an error in my current calibration (I scaled by 4 instead of 2) so I attempted to change it and I get this error:
Calibration – failed to enter calibration mode with command 0x2D

I can issue the CAL_ENABLE command on the commands sidebar without errors but the CALEN does not set.

I then tried to change some flash for test purposes and got the dreaded:
A read of data written failed comparison
Reading works.

So my guess is that these problems are related and have to do with not being able to write flash. My battery Voltage is way above where I would get into trouble with:
Flash Update Cell OK Volt = 2656,
so with Voltage Divider = 18386, I figure that the battery would need to be < 9.7V (6 cells) to cause problems. Just to be compulsive I powered the EVM from a bench supply at 15V, still no joy. It is not sealed SS and FAS are cleared.

I did the following:

1. Reinstalled bqStudio
2. Power cycled EVM
3. Tried command RESET
4. Switched from the EV2300 to my host: the flags and data I read were the same as bqStudio. I tried to enable CAL_ENABLE from the host (writing to 0x2d) but the flags did not change.

So I think that the tool chain is OK and the target itself is unhappy. Any ideas?

I have seen chatter about these problems in this forum but didn't find anything that would fix it.  Thanks for all the help,

m

Hi Mark,

• Set Flash Update Cell OK Volt to low value, 500mV for Voltage calibration in Data Memory >> Configurations
• Setup the number of cells e.g. 6 in Data Memory >> Configurations
• Setup cell voltages in Data Memory >> Configurations
• Set VOLTSEL to 1 in Data Memory >> Configurations >> Pack Configuration for use of external voltage divider and select write to data memory 
• Send RESET command
• Set Voltage divider in Data Memory >> Calibrations to 19000, if using EVM 16V setting or close estimate of your PCB voltage divider
• Run voltage calibration
• Remamber to set Flash Update Cell OK Volt to previous value 2656mV in Data Memory >> Configurations
• Continue with calibration

Hi Damian,

Your proposal is just what I should have done.  Flash Update Cell OK Volt should be first thing to write to a low value and the last thing (if ever) to be written to an operative value.   But I cannot now write anything though I should be just fine with the battery voltage.  The gauge is running, I can cycle and see OCVTAKEN set/clear.

At this point my conclusion is that there either a bug in the Flash Update Cell OK Volt algorithm (it would be a nice feature to have it set a flag when it is not allowing writes) or I trashed the chip on the EVM.  I believe that this is probably a bug because I have another EVM that behaves exactly the same way.

I would like to send this one to you for your evaluation.  I have another one on order.

Thanks for the continued assistance,

m

Hi Mark,

Are you using an EV2300 or EV2400? What version? You can send me the exported SREC and GG.CSV files, so I can evaluate you conditions. Is your gauge reporting correct voltage? I agree with you that there's a bug in the Flash Update Cell OK Volt algorithm, but it's a chicken or the egg scenario.

Let's continue working to resolve these challenges.

Hi Damian,

I am using an EV2300 ver. 3.1c. I am writing a little test code for my Linux host to try to set the MSb of Flash Update Cell OK Volt to 0x00 to completely remove the tool chain from the equation, my bet is that it won't work but I'll let you know. If you search the forum for "A read of data written failed comparison" you will notice a strong association between setting the VOLTSEL bit and the flash freezing up. My guess it that #cells is the culprit.

Oops forgot to hit replay (next day)

I finished the script to write Flash Update Cell OK Volt to 0x0000 from my host over i2c bus. It behaves exactly like the bqStudio when I read back to compute the new checksum, it looks like it wrote but when I put the new checksum into BlockDataChecksum to actually cause the flash to write it does not change. This script is per p.21-22 of the datasheet.

This freezing of the flash also explains the problems I originally wrote you about.

I am plenty happy to send this EVM to you if it is helpful to have it.

Best Regards,

m

Hi Mark,

The gg.csv and srec will suffice for now. I will try to reproduce the issue and give you some more guidance on Monday.

Hi Damian,

I hope that you are finding your way through our dilemmas.  I have now two new EVMs and three "bricked" ones.  I would be more inclined to experiment if I knew of a way to recover the EVMs from the flash freeze up problem; short of replacing the ICs.  Would it work to have an image with the Voltage checking for writing flash disabled that I could reprogram the parts with?  I am not certain that it is possible to reprogram when they are in this state but seems worth a try.

Thanks and have a great holiday

m

Hi Damian,

Have you been able to gather some additional advice on this problem?  Can I supply you with any other information?

Thanks,

m

Hi Mark,

Sorry I haven't been able to work on your issue lately. I should have some feedback next week.

Hi Damian,

I have some new bq34z100 EVM.  I wanted to see exactly how I might have bricked the ones I have.  I set one for 16V and put it on my nominal 12V system.  So with the divider network the input to the BAT pin should see about 700mV when the battery is at 13.4V.  Now start BQStudio look at  the default screen (below).  You will notice that contrary to the TRM (says the default is 0)  CAL_EN bit is set.  This is very fortunate because you will notice that the Voltage is ~600mV which is odd, seems as though with the internal 5:1 we would get about 140mV.  Either way, we are in trouble with the Flash Update OK default of 2800mV.  So if the CAL_EN bit gets cleared, however it happens, the part becomes non-functional because the CAL_EN bit itself is in flash (also unfortunate).

My conclusion is that the very first thing that one should do is set the Flash Update OK to 0mV.  But we know from earlier discussions that the Flash Update OK algorithm seems to have a bug.  What do you think of this approach?  I got into trouble before because the first thing I did was calibrate, put in the other constants, and then cleared the CAL_EN bit (the TRM is very vague about this bit) to make it operational.  Oops, I discovered that I had an error in the calibration and I could not change the flash.  When you are finished testing and actually want the part to do Flash Update OK testing the set appropriately;  (in some cases -mine- REGIN has marginal relation to BAT) you want it disabled.

I have not tried this yet because I am not clear on how the algorithm would respond; the TRM says 0 is OK.

I think that a way to rescue these parts would be great; I am certain I am not the only one who has bricked some of these.  I also vote for putting CAL_EN somewhere else (RAM) in the next release.

After a conversation with Yevgen Barsukov, I have decided that this part is better for my app than the bq34110.

Thanks for your help,

m