BQ40Z60EVM - the charger voltage rises too high in the constant voltage region

Sergey,
I have been out of the office, but I will answer your questions in the next couple of days.
Tom

Thomas,

you have probably forgotten about my question? I couldn't resolve the problem myself so far.

Sergey

Sergey,

I have not forgotten you, but there were a lot of questions. We will need to adjust the Charging Voltage parameters to reduce the actual charging voltage. What is the charging voltage that you desire and I will help with the adjustments. 

• CHG_FET bit mentioned at p.63,68 is missing from FET Options table p.153, but shows in bqStudio

  [TEC]   The bqStudio is correct.

• CHGIN bit mentioned at p.68-69 is missing from both FET Options table p.153 and bqStudio

  
  [TEC]   The CHGIN feature was removed.

• No formulae for calculation nor definition of LCHG Current Resolution

  [TEC] The LCHGS and LCHGM features will increase the current measurement resolution and dynamically adjust the charging voltage as the current drops in pre-charge. The pre-charge feature will also work without these bits enabled, but the current resolution and dynamic adjustments will not be invoked. You should either enable both bits or disable both bits.

• PCHG_COMM bit mentioned at p.67 is not found elsewhere

  [TEC]  The PCHG_COMM bit was removed. Zero-voltage charging will start automatically, if the charger is enabled.

• ChargingConfiguration[LCHGM] function needs clarification

  [TEC]  see above

• PF Shutdown Voltage/Time at p.75 - no definition found

  [TEC]  It works the same as the Shutdown Time, but applies when a shutdown is associated with a PF Shutdown Voltage.

• IT Gauging 2 Configuration at p.153 - no definition found

  [TEC]  The is a hidden register.

• initially BTP_INT bit was stuck set despite of BTPCharge/DischargeSet() commads, but it changed at some point and now the commands have effect - what can keep the bit from clearing?

  [TEC]  I am not aware of a condition that would prevent it from clearing.

• does BTP pin reflect only configured BTPCharge/DischargeSet() events and no others? (I'm a bit confused with a pin name ALERT in datasheet.) Can a slight pull-up be switched off from the pin?

[TEC}  The Battery Trip Point (BTP) feature indicates when the Remaining State of Charge (RSOC) of a battery pack has depleted to a certain value set in a DF register. The BTP feature allows the host to program two capacity-based thresholds that govern the triggering of a BTP interrupt on the GPIO0 output pin. The BTP interrupt can be monitored on the ALERT test point.

Thomas,

many thanks for the comprehensive answer!

According to the batteries manufacturer specification I need the charging voltage to be limited to 4.200±0.02V per each of the two serially connected cells.

Evidently charge termination conditions description at p.26 of the datasheet slusaw3a "once the highest cell voltage reaches the value specified in the dataflash, the charger output voltage will no longer increase" is not quite correct and so the principle of pack/cell voltage regulation remains obscure. Could you please reveal these details so that it was possible to adjust the settings further if needed so.

Next, I report another bothersome phenomenon in the evaluation board. Often, during the charge, random temperature misreadings begin to occur, showing a periodic pattern of several seconds long and lasting until the charge is interrupted. These lead to undesired current/voltage range switching and even worse, to protection triggering. Misreadings affect all the sensors, including those unconfigured, and occasionally produce as large deviations as -50C at the room temperature. I must note though, that some of the charging cycles that I observed seemed to accomplish normally. Please let me know if it is a known problem, and if not, what additional data is needed to resolve it.

Thank you.

Sergey

 

Sergey,

I drafted the attached document to help setup the charger parameter when over voltage conditions occur.

Tom

bq40z60 Charging Voltage Compensation.pdf

Thomas,

thank you for for this detailed help. I'm sorry if it was me who made you to attend the work on this weekend, and I appreciate your effort.

Rounding you wrote about can account for no more than 256mV excess. In my case the difference was definitely more than 300mV. Nevertheless your information helped to get closer to the truth. I removed the pack and produced measurements of the charger feedback voltage at various target voltage settings under room temperature and no load. Two most important samples:

1. VFB = 629mV @ Charger Voltage Register = 0, this yields Minimum Voltage Output = 4349mV, rather then theoretical 4218mV I set it to
2. VFB = 1237mV @ Charger Voltage Register = 255, this yields Maximum Voltage Output = 8554mV and Voltage Resolution = 16.42mV which meanwhile is close to the theoretical 16.47mV

All the measurements were verified at the charger output so as to exclude possible test leads influence and resistive divider error. Internal voltage references specifications at p.11,12 of datasheet seem to disallow so large a room, but their connection to VFB is not obvious. Besides, the tables mention some trimming not described elsewhere.

I think that with the measured data accounted I can program the dataflash appropriately, but I would like you to give your comments first.

Regarding severe temperature misreadings mentioned in my previous post, I still wait for your comments too.

Regards,

Sergey

The temperature issue looks like a noise issue. Can you collect log data showing the results, so that I can try reproducing them?

Thomas,

the temperature issue seems to be connected to LED display. Please find attached the logs and dataflash contents.

8688.bq40z60.ZIP

Something to be considered:

• TS1 is detached from the board and placed onto the battery pack surface, it is the only sensor configured for cell temperature measurement; C31 (as per sluub71) is removed (see my first post on the topic for the reason)
• TS2 is replaced with a mere 10kOhm resistor (I have broken the sense resistor from TS1 position trying to desolder it (no thermal reliefs) and had to borrow it from TS2 position)
• internal sensor is configured as FET temperature sensor

• TS3 and TS4 are not calibrated

Samples of interest in the file Watch.log:

• 9:25:53 - the first signs, TS1 hits -56.4C (it seems to me that the issue tends to begin close to the charge end)
• 9:31:58 - I noticed the effect and set the sampling rate higher
• sporadic misreadings are seen at all the sensors, including internal one (though relatively small at the latter)
• 9:35:25 - I changed LED Configuration[LEDCHG] to 0
• sensors are quiet
• 9:38:45 - I restored LED Configuration[LEDCHG] to 1
• noise again

I tried to observe the temperature measurement pulses and noticed that during the noisy periods the pulses length (~16ms normally) would sometimes shorten up to ~2ms. Besides, rare pulses were noticed with low level hitting ground, what could yield extremely high temperature. And lastly, drops ~100mV of high level were noticed, which could be responsible for minor temperature deviations.

Unfortunately, I really need the LED function. Actually what I need is to have one LED blinking until the charge is complete. I hope that the issue can be fixed in firmware along with the rounding issue you wrote about.

Please let me know if the collected data is sufficient for analisis.

Please also give your comment regarding the severe VFB mimatch reported in my previous post. By the way, I tried to account for both rounding and referense offset effects and still have extra ~50mV at the pack:-( There must be something else...

Regards,

Sergey

Sergey,
Do the erroneous temperature readings occur when the LED is lit? The device was not designed to support thermistors and LEDs. The LEDs will affect the temperature measurement.

I will looks at the VFB question.

Tom

Thomas,

it doesn't matter if the LED is lit or not. It is stated in the chapter 6.2.6 of sluua04 "The LED support is available even if thermistors are used". And it really is the case: there are special provisions for isolation, including EVB schematic level, which do their job relatively well up to the moment where the stars don't wish it to go on.

Anyway, I must thank you again, since I noticed based on the data collected upon your request, that the whole trouble begins exactly as the third LED adds to the blinking string, even though it is not configured for measurement. Since I only need a single LED blinking I excluded all the others by shifting their thresholds to 100% RSOC, and it turned out to eliminate the trouble. By the way, the remaining blinking LED port is also the only input configured for temperature measurement. Let me know if you are interested in more detailed illustrations and I can send you diagrams based on the collected data. I still hope that the problem can be fixed in firmware, otherwise I would suggest adding a warning in the datasheet for other users.

Have you managed to find out something regarding the VFB mismatch? I can make charging controllable now in my sample of EVB under room conditions, but for production I need to know the garanteed limits of dispersion and temperature dependence.

And, hopefully, the last question. I'm going to use in my design the new LiPol batteries from EEMB, capable of discharging in the range -40...+45C. There is a chance that the battery will need a new chemistry to be defined, at least for a better support of the wider temperature range. I read chapter 19.3 of the document slua380, detailing the procedure of data collection. Regrettably, the procedure described can easily take a month or so. Can the procedure be simplified and how, considering a mere industrial application with no demand for cosmic precision? At which temperatures should the data be collected? And whom should I contact to apply for the new chemistry developement?

Regards,

Sergey

Thomas,

please let me know if my post dated Apr 23 is still awaiting in the queue.

Sorry for disturbing, regards,

Sergey

Sergey

Are you using real cells in your evaluation or a resistor divider? Using a resistor divider will affect the feedback voltage measurement. I checked the upper limit with cells and it looks okay. I need to discharge my cells to check the lower limit.

Tom

Thomas,

I'm using real cells in 2S1P configuration.

Series Cell Select Jumper is set to 2S position yielding Minimum Voltage Output = 610 * (1 + 332k / (26.1k + 9.53k + 20.5k)) = 4218mV and Voltage Resolution = MVO / 256 = 16.48mV.

But I have measured VFB = 629mV rather then 610mV (+3.1% error). The measurement was taken under the following conditions: no cells, no load, Charger Voltage Register = 0. This yields Minimum Voltage Output = 4349mV which I programmed into DataFlash.

Another measurement was taken with Charger Voltage Register = 255 and it produced VFB = 1237mV rather then 1220mV (+1.4% error). Accordingly Maximum Voltage Output = 8554mV and Voltage Resolution = (8554mV - 4349mV) / 256 = 16.43mV which i rounded down to 16mV and programmed into DataFlash.

My target end-of-charge voltage is 2 * 4200mV = 8400mV. This can be achieved as 4349mV + 246 * 16.43mV = 8391mV, since AFE uses unrounded resolution 16.43mV. Therefore I have to set the charging Voltage in the DataFlash to (4349mV + 246 * 16mV) / 2 = 4142mV. But in fact I had to further reduce the charging Voltage setting down to 4126mV (Charger Voltage Register = 244) to obtain the safer charging voltage.

With the above settings programmed the charging voltage at the pack terminals peaks at ~8425mV (see the attached log and diagrams), which is satisfactory, putting long term and temperature stability out of discussion for a while.

3288.bq40z60.ZIP

Though the described conditions of VFB measurement may be not quite correct, in my case they still produce results, which are in better correspondence with experimental data. Since you wrote that your measurement is Ok, I have to assume that something is wrong with my sample of EVM. I have no other EVM, therefore I have to wait until prototype boards are ready to check it up again.

Please review my calculations and the attached diagrams.

Please also review my question regarding low temperature cells in the post dated Apr 23.

Regards,

Sergey

 

Thomas,

I have received new batteries intended for our project. They are 6Ah LiPol with operating temperature range -40...+45C/discharging and 0...+45C/charging.

My new problem is that the chemistry selection tool (rev. 35 and 37) returnes bestchem and maxerr undefined for the batteries.

Please review the collected discharge data (time/s - col0, volt/V - col1, temp/C - col3, current/A - col2) and give your recommendations.

SimpleDischarge.zip

Regards,

Sergey

Thomas,

sorry for disturbing,

I noted wrong sign for the current, fixed it and obtained the result.

Anyway, let me ask now another question regarding the batteries. As I wrote before, they are of low temperature type (-40...+45C/discharging and 0...+45C/charging.) Are there additional checks that can be done early in the design timeline to provide for the good gauging performance in the whole operating temperature range with the selected chemID?

Regards,

Sergey

Sergey
The Mathcad program predicts that ChemID 1262 should be a good match for your cell.
Tom

Thomas,

thank you for the suggestion. Glad to hear from you again.

1262 is #26 on the list, that Mathcad produced for me. Do you mean that it is a better choice based on some other criteria, incl. low temp. capability?

Sergey

Thank you, it makes sense. I'm going to proceed with the tests soon to verify this choice.

Thomas,

alas! I need further assistance.

I have collected discharge data for my battery (LP8067100LC from EEMB) at different temperatures (-30, 0, +25 and +50C) and feeded it onto mathcad chemistry selection tool. Regrettably the tool's proposals are inconsistent and controversial even in conventional temperature range. As to -30C, there are no proposals with an acceptable DOD error.

Please find attached the discharge data. Columns order is as follows: time (s), voltage (V), current (A), temperature (C).

LP8067100LC_SimpleDischarge.ZIP

I hope your advice will as always be useful.

Regards,

Sergey.

Sergey
The tool is designed to use 25 degC data to provide the ChemID match and the gauge will adjust the parameters over the full temperature range. The Mathcad tool does provide a good list of ChemIDs for your 25 degC log file.

Tom

Thomas,

thank you.

My whole life's work is ruined (joking:-).

What would be your ChemID choice for the battery then, concidering tighter disqualified range, HF resistance and anything else you can consider?

Regards,

Sergey.

Sergey,
It looks like ChemID 3118 will be the best overall fit for your cells.
Tom

Thomas,

thanks a lot!

But is it still true despite of 4.35V? Mine is 4.2V.

Regards,

Sergey.

Sergey,
I did not realize that your cell was a 4.2V cell. I checked the other top choices that is look like ChemID 1296 will be a closer fit, especially at the top of the OCV table.
Tom

Thomas,

I just downloaded and installed the latest build of bqStudio, but 1296 ChemID is missing from there. Help->Update chemistry command returns "Automatic update failed. Please try updating using the given zip file."

What should be my next step?

Regards,

Sergey.

If the automatic upload fails, then you can unzip the file and copy the contents to this directory. You will then have to reopen bqStudio .

I guess the directory should be c:\TI\BatteryManagementStudio\chemistry\.

But where am I to find the zip file?

You download the zip file from the TI website. www.ti.com/.../GASGAUGECHEM-SW;tisearch=Search-EN-Everything

I just tried it and it looks like they have fixed the updater tool in bqStudio. Download the zip file from the Chemistry Updater website, rename it to add the .zip extension and then you can use the Help >> Update Chemistry option in bqStudio to update the chemistry files.

Thomas,

my prototype boards with BQ40Z60 are now ready, and there appeared more questions I would like to address to you.

1. Initial problem which gave a name to the thread still persists. Namely, my sample of EVM has Minimum Voltage Output (MVO) 4349mV rather then 4218mV (+3.2%), two prototype boards have similar MVOs 4342mV and 4326mV. There may be some systematic offset, not just the defective IC as I thought initially. Although these deviations can be accounted for by means of appropriate calibration procedure, I would be grateful for an explanation of such a huge mismatch with the procedure detailed in sluua04. My major concern in this regards is long term and temperature stability of the charging voltage.

2. Temperature sensing with an external NTC shows considerable errors, especially at lower temperatures: 247kOhm yields -40.3C rather then -45C, 1.27kOms yields 88.3C rather then 90C. Calibration has been done at 25C. More or less similar are the errors of the internal sensor.

3. ACFET remains permanently ON if the AC adapter is disconnected BEFORE the charger detects FC. This is definitely a bug. In my design this creates a path for battery discharge through the power indicator LED.

Let me know if any additional data is needed.

Regards,

Sergey

Can anyone help with the above?

Sergey

Sergey
I had not seen your post, so I will handle it.
Tom

Sergey

Do you have a data log showing the charging current and voltage? I will also try bench testing your gg file on Monday.

Tom

Thomas,

I will need some time to record data log since I didn't preserve the logs lately. Please let me know, do you mean data log of a regular charging cycle? If you don't mind the cycle to be interrupted, I can try to demonstrate ACFET staying on after the charger removal. By the way, ACFET behavior in fact proved to be more sofisticated than it seemed at first glance, sometimes it does switch off Ok, yet there seems to be much more chances for it to stay on. I can't believe this is an intended behavior, perhaps something is terribly wrong with my settings though.

As to gg file, please find it attached.

Optimized.gg.zip

Regards,

Sergey.

Sergey,

Yes, I need to see a log file for a charging cycle that shows the overcharge condition. Maybe it will provide a clue as to how to correct it.

Tom

Should it be REAL overcharge (i.e. > 4.2V)? I feel pity for my batteries since I have no spares. Maybe it would be enough to see that the charger develops considerably higher voltage than it is configured for?

Just show what is happening and safe. We do not want to damage the batteries.

Ok, I will record and send the log file tomorrow (my working day is over). Shall I also try to show ACFET behavior or let it be another step?

Thomas,

please find attached the log file taken from my prototype board.

LogFile.ZIP

Some footnotes:

1. Resistive divider is 332k upper and 56.2k lower.

2. There is a small initial discharge part in the log.

3. After the charge is complete (FC) the AC adapter is swithed off at 13603s and ACFET can be seen to follow Ok.

4. There is a small additional discharge part in the log, bringing the battery to 90% RSOC.

5. The final part demonstates three occasions with ACFET remaining ON after the AC adapter removal: at 14719s,  14828s and 14912s.

Hopefully this helps both of us.

Regards,

Sergey

Thomas,
probably I have found a clue to the bad ACFET' behavior in my design.
This is Vacp Hysteresis parameter which I have set to 512mV (default 0mV).
Setting this parameter to less than ~200mV seems to resolve the problem.
Evidently explanation for this parameter in chapter 4.2 of sluua04 should read BELOW rather than ABOVE.
Please clarify this parameter.
Regards,
Sergey

Sergey
I will check to see which is correct.
Tom

Sergey,

The VACP Hysteresis controls how much below pack voltage you can go before VACP is not detected. 

The ACFET flag should clear if, VACP <= BAT - VACP Hysteresis.

 Tom

Thomas,

thank you, I suspected so too.

I tried to set it to a negative value then, which is allowed and seems logical, but loss of connection followed (???) which could only be restored by unplugging EV2400 from host PC, plugging it in again and restarting bqStudio. I never observed such things before. Maybe just a coincidence, yet I gave up, ceased the investigation and set Vacp Hysteresis to 0. ACFET seems to switch off fine now.

Any news in log file analisys?

Regards,

Sergey

Thomas,

am I still in the queue?

Regards,

Sergey

Sergey

Did you see the application report on Charging Voltage Compensation on the bq40z60 website? There is limitation in the Voltage Resolution parameter that causes the charging voltage to exceed the programmed value. Is this the only problem that you have left? 

Tom

Regrettably this returns us back to my post dated August, 20.

The Application Report you mention is placed in this thread in your message dated April,19. I guess it was written for me then. I wrote in my answer that limited voltage resolution can not account for all voltage mismatch and there is Minimum Voltage Output offset by ~3% which is responcible for the remainder. I reported this question many times under different angles yet those posts were either never read or ignored. I'm sorry for failing to find a good way of communication to TI' support since I can see lots of helpful examples in neighbouring threads as well as in this one.

Anyway, TWO problems I have left are (copying from the Aug. 20 message, ACFET problem can be considered resolved):

1. Initial problem which gave a name to the thread still persists. Namely, my sample of EVM has Minimum Voltage Output (MVO) 4349mV rather then 4218mV (+3.2%), two prototype boards have similar MVOs 4342mV and 4326mV. There may be some systematic offset, not just the defective IC as I thought initially. Although these deviations can be accounted for by means of appropriate calibration procedure, I would be grateful for an explanation of such a huge mismatch with the procedure detailed in sluua04. My major concern in this regard is long term and temperature stability of the charging voltage.

2. Temperature sensing with an external NTC shows considerable errors, especially at lower temperatures: 247kOhm yields -40.3C rather then -45C, 1.27kOms yields 88.3C rather then 90C. Calibration has been done at 25C. More or less similar are the errors of the internal sensor.

Please dont leave me suspended, I would better chose to receive a refusal of support. 

Regards,

Sergey

Sergey,
Thank you for the concise description of these two issues. I think that part of the problem has been that the issues have been lost in the detailed explanations. I will load you parameter set into an EVM and check the accuracy of the minimum charging voltage and try to improve it. I do not recall seeing the temperature measurement issue before. Temperature measurements are degraded at temperature extremes with the best accuracy being between 0 and 50 degC, where the gauges are designed to perform. The error that you see may be realistic depending on the thermistors used and noise in the system. The bq40z60 charger introduces some noise into the system and can impact voltage, current and temperature measurement accuracy during charging.
Tom

Thomas,

with this you have put the hope back into my soul again.

I ask you to please consider the following:

1. Regarding MVO issue I expect an answer like these or so:

- the gauge will provide a stable charging voltage, though different from sluua04' interpretation

- there is a flaw in my settings which shoud be sought for then

2. Regarding temperature measurement issue

- my complaints refer to measuring ordinary 1% resistors (not NTCs) at the room temperature, with calibration being done with ordinary 10kOhm 1% resistor to eliminate possible NTC errors

- measurements have been held at still conditions (no charging), moreover, I tried to shunt the resistors with a 1nF capacitor which resulted in 0.3C error increase at -45C

- my design supposes controlled discharge and gauging at cold temperature, therefore I need temperature with less error.

Thank you,

waiting for the result of your check,

Sergey

Sergey

I have been working on trying to verify your Minimum Voltage Output issue, but it is difficult to check it precisely. One think that I have encountered is a CUV event. Are you certain that the error is not due to the DSG FET being off and resulting in a larger than normal drop across the FETs? Are you using batteries or a resistor simulator. I have found that batteries must be used for the charger to regulate properly. I will continue working with your setup.
Tom

Thomas,

thank you for yor effort.

I agree that direct MVO measuring is hardly possible, but I ask of explanation of too large a deviation from expected charging voltage. I consider the voltage to be ~MVO when Charger Voltage Register is forced to 0 by manipulations with parameters in Data Memory. I measure it at VSYS terminal with battery and load disconnected. Not quite correct a measurement, but this model corresponds much better with actual resulting charging voltage.

I use real batteries.

I reviewed the log file that I sent to you and indeed found CUVC event there. It started right after the first charge begining (???) and lasted for ~2 minutes. Despite of that DSG FET remained on during the whole charge. There are also charging fragments in the final part of the file not affected by CUVC. Actually I don't understand CUVC mechanism and it is probably poorly configured, but I'm afraid to overload you with more questions now so that you don't dissapear again.

Regards,

Sergey