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.

BQ27500 "chemistry select cycling"

Other Parts Discussed in Thread: BQ27500, BQEVSW, BQ27500-V100

Background: We havn't programmed the bq27500 previously in production, and I'm about to generate our golden file. Calibration values have been collected from a number of production boards, and its time for "Chemistry select cycling", and the "Learning cycle".

1) Before performing chemistry Select Cycling, and in the learning cycles, would it be important to charge the battery until we are very close to C/100 taper current?

The charger in our product performs constant current charging until we reach 4.20V, and then it supplies 4.20V for 4 hours before stopping. If needed, I could measure the current to the battery after hooking it up to a 4.200V supply to see if the charge current is below C/100.

2) While "Relaxing" the pack, would the current drawn from the battery need to be below 1mA (it's a single cell 2260mAh pack). In that case, we might need to do the chemistry selection cycle and learning cycles on your EVM board instead, or patch a production board to remove all power consumers.

3) Do you have C code examples for programming the golden file (I found the VisualBasic one in slua440.pdf. We actually intended to program the gas gauge using the EV2300 to begin with, but if there is tried and tested code, I could motivate directly putting the golden file programming into our final production test SW.

BR
Simon Gustafsson

  • Simon,

    1) No, you have programmed a taper current during step 2 of the bqEASY steps.  As long as you charge PAST this taper current, you should be OK. If your charger stays on for 4 hours, it will probably be just fine. There is one "gotcha" here though.  Make sure that the charger current is above the "quit current" as defined in the Data Flash->Gas Gauging->Current Thresholds section of the data flash. 

    If it is not, then the gauge will exit the "charge" state and enter the "relax" state and try to measure the battery's open circuit voltage.  If it does this before the charger turns off, then the gauge will measure the charger voltage as the battery voltage.  This can be bad, because the gauge will measure an artificially high battery voltage.  However, in practice, the charger must be attached and running for a VERY long time (on the order of 12 hours) before the supply voltage stablizes enough for the gauge to interpret it as a battery voltage and read it.  Given that your charger cuts off after four hours, it will probably be OK regardless.

    2) We recommend having no current (or very low current) passing through the battery during the relaxation phase.  This value is also really determined by the "quit current" parameter mentioned above.  This determines when the gauge transitions from "charge"/"discharge" states into the "relax" state.  Given the size of your battery, you could probably set this guy to the order of magnitude of C/100 (probably between about 10mA and 50mA to be on the safe side).  Anything below this current will be detected and counted, but the gauge will be in the "relax" state, and capable of measuring OCV's.

    3) We currently have some alpha code put together that might be able to help:  The application note is: SLUA54: Updating bq275xx Firmware at Production

    This app note references the "flashstream" program. This is still in a fairly alpha state, and has not been posted online, but I can send it to you directly.  I also have some example code that uses an Aardvark platform to program the script generated by the "flashstream" program over an I2C bus if you are interested. 

    Let me know if this helps,
    Charles

  • Thanks Charles,

    I would be interrested in both the flashstream program, and the example code you mentioned for aardvark. My email adress is simon.gustafsson@tobii.com

     

    Now, I'm facing a new problem with BQeasy (BqEVSW revision 0.9.59):

    I'm about to generate the golden file for a bq27500 battery gauge.

    I'm at step 3F in bqeasy, and would like to update the "data flash" to set average values gathered from calibration of several boards/batteries.

    When I’m in the “Data Flash” part of the application, I get the same kind of error message for all calibration fields when I enter a new value and press the enter key:

    "The value entered is out of limits. Please enter a value between 4.71 and 0.012 mohm” (that was for CC Gain, where I wanted to set 10.466)

    "The value entered is out of limits. Please enter a value between 0.019 and 0 mohm” (for CC Delta, where I wanted to set 10.423)

    "The value entered is out of limits. Please enter a value between -2.411 and 2.411 mV” (for CC offset, which I wanted to set to -0.099)

    I’ve tried using both “.” And “,” for the decimal place, neither helped (I'm in sweden, thought that might be the problem)

    I was somehow able to change Ext temp offset to 0.9, and if I entered 0,9 (comma instead of dot) in that field I got a message of “Run-time error ‘13’: type mismatch” and then the application kills itself.

    BR

    Simon

     

    Update jan 13 - 2011: Thought I was smart, exported the flash content, changed calibration data in that human readable file, and imported it again (that way I was able to get the right values in the field of the application, even though I had to mix commas and dots in different fields. Unfortunately, the calibration values was not possible to write anyway. (Register "Control" is 0x0004 if that gives any more information)

  • I'm seeing different limits on input restrictions on my end when I change the calibration values.  This is likely due to a difference in the interpretation of internal software strings as numbers by your OS seeing '.' as ',' and ',' as '.' 

    I'm honestly not sure whether you should use ',' vs. '.' as your delimiter when you enter data into the screen, as I haven't checked to see which entries are passed to the OS for interpretation.  However, I've modified the EVSW configuration in such a way that it SHOULD give proper limits on the inputs that will allow you to at least write the information (Note that it will NOT work on a computer that interprets '.' as the decimal delimiter).  Copy this into the Root directory of the EVSW.  It should replace a file.  (back that file up beforehand).

    http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/180/7587.bq27500_5F00_1_5F00_30.encr

    Let me know if this helps,

    Charles

     

  • Hi,

    The gas gauges on our boards actually reports that they have the 1.08 firmware on them, and  (what you call bq27500-V100
    ), so I guess I can't use your file directly, just tried but will try anyway. Would you recommend upgrading to the 1.30 firmware at the same time that we burn the calibration in production? (saw some nice improvements in the change lists, but nothing I would interpret as crucial).

    Simon

  • Consider all questiones in this thread resolved. Just posting some more info in case this helps anybody else

    Did upgrade the gas gauge FW to 1.30 (we might want this anyway, to be sure that the data flash image is interpreted correctly by the chip, and to gain improvements in the new FW. Our beta units did actually have different gas gauge firmwares then our current production units.

    Also reinstalled the evaluation software, still couldn't update the data flash values directly, but exporting, changing values by hand (using "," instead of "." for CC Gain & Delta),  importing, and programming now updates all necessary fields.

    One of the fields I was trying to set previously to an average value from several calibrated boards was the CC offset field, which we probably was not supposed to set in the data flash image. In our product, the criterias for the bq27500 to autocalibrate that field is fulfilled whenever our unit is turned off...

  • I had the same problem and resolved changing the "Regional and Language options" to English.

  • Dear all,

    Even though this topic is considered answered I just want to add on that this applies also for regional settings like Norwegian. I have been informed by TI that the bqEVSW does not support regional settings other than English.

    I think that this is important to be aware of.

    Regards

    Kjell