• State Resolved
  • Locked Locked
  • Replies 23 replies
  • Subscribers 64 subscribers
  • Views 2821 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

How to configure/write to Data Memory of BQ27531-G1? Is my understanding of the process correct?

mrausol
Intellectual 690 points
Other Parts Discussed in Thread: BQSTUDIO, BQ27531EVM, BQ27531-G1, BQ24192, EV2400

Hi,

I am working on a consumer electronics product that will be using BQ27531-G1 and BQ24192 ICs for battery fuel gauge and charger. I am doing the development/debug on the BQ27531EVM demo board and BQStudio software.

I'd like to clarify some things with regard to the BQ27531-G1 IC configuration and calibration.

As far as I've understood, this IC needs to be calibrated/configured once. We plan to do this using an application code programmed to our product's MCU via I2C.

The calibration/configuration data will be coming from the exported DFFS golden image file from the BQSTUDIO Software (reference app note SLUA541A). The plan is to calibrate 20 to 30 boards using this software and then average the results for the final calibration/configuration data.

This means that the DFFS data will also be programmed in the STM32 since the MCU will handle the transfer of this data to the BQ27531-G1 IC when our product first boot-ups in end-user application.

Please let me know if my understanding of the process is correct, and please let me know what you think….

More questions for the details,

- Does TI have sample codes or tools that we can use in parsing the DFFS data? Like I said, we plan to have our MCU to handle the configuration. Our MCU app code is in C language.
- How to create a golden image file with the averaged values using the BQSTUDIO software? I only know how to export golden image file after calibrating one board using the BQSTUDIO, but I’m not sure how to enter the final averaged values and export the golden file.

Thanks,

  • 0
    TI__Guru 61206 points

    We'll release an applications note this month with example code to parse flash stream files and program the gauge.

    You will have to calculate the average values manually and write them to the data memory with bqStudio.

    Calibration values are the Board Offset and CC Gain. The Gas Gauging value to update is Qmax Cell x.

     

  • 0 in reply to Dominik Hartl11
    Intellectual 690 points
    Thanks.

    I calibrated CC offset, Pack voltage, and board offset. I also configured Design Capacity, Q max cell and the chemistry according to the batt manufacturer's datasheet.
    Aside from these parameters, did I miss anything needed to be configured?
    And also, is it enough that I use the .df.fs file (and not the .srec or .bq.fs) in programming the gauge?
    Since our MCU will be the one to handle this, we want the config/calib data to be small and just contain what just needed to be configured.
  • 0 in reply to mrausol
    TI__Guru 61206 points
    You also need to set the charge termination information (taper current/rate, taper voltage) and the termination voltage (minimum voltage when your system shuts down).

    Please use the .df.fs file to avoid problems with firmware updates.
  • 0 in reply to Dominik Hartl11
    Intellectual 690 points
    Hi,

    May I know when is your target date release?

    Is it also possible to send us a draft/preview while we wait for the full version? It would really be helpful!

    Thanks!
  • 0 in reply to mrausol
    TI__Guru 61206 points
    It's in the release process and should be on line in the next two weeks.
  • 0
    Intellectual 690 points
    Hi,

    Is it required to perform learning cycle for the batter if using this charger and gauge? Do we have an app note on how to do it using bqstudio?
  • 0 in reply to mrausol
    TI__Guru 61206 points
    A learning cycle will improve accuracy. The gauge will automatically adjust to the cell over time if the cell goes through discharge and charge cycles. You can also perform a learning cycle manually - see www.ti.com/.../slua597.pdf
  • 0 in reply to Dominik Hartl11
    Intellectual 690 points

    Thanks!

    I have another question.

    I've been trying to set the INLIM bits via host commands but it gets reset after the watchdog timer expires (I think).

    I'd like our firmware to be able to override the default INLIM settings (derived from PSEL and OTG states) so that it will adjust to different USB-type/power source. We'd like the firmware to handle this, but it gets reset always.

    Our board's PSEL is tied to the power rail so it defaults to 500mA (with OTG=1). Is there anyway to set this bits via host?

  • 0 in reply to mrausol
    TI__Guru 61206 points
    There's no direct way to override the settings after a reset. Your FW has to set this after a charger reset.
  • 0 in reply to Dominik Hartl11
    Intellectual 690 points

    Hi Dominik,

    I see. So the firmware has to set the INLIM every after 40s (WDT expiration).Is this correct?

    Also, how critical it is to do the learning cycle of the battery on bq27531evm demo board instead on our actual board? I'm planning to do the learning cycle, calibration and configuration on TI's board via bqstudio, extract the golden file, then program it to the ICs on the actual board. Do you think this will work? Or do you strongly recommend to do these on our board via our MCU which will take time due to added development effort for the calibration code since we can only do it via MCU on our actual board.

    Thanks,

  • 0 in reply to mrausol
    TI__Guru 61206 points
    The gauge will reset the watchdog timer every 15 seconds. This is well below the 40 (or 80 or 160) seconds limit of the watchdog timer (WATCHDOG[1:0] in Reg5). Therefore the watchdog timer should not reset the charger every 40 (or 80 or 160) seconds and you should not have to reprogram INLIM.

    You don't have to do the learning cycle on your system. TI recommends using the EVM and bqStudio and export a golden image which you can program into the gauge with bqStudio and an EV2x00 connected to the gauge in your system.
  • 0 in reply to Dominik Hartl11
    Intellectual 690 points
    Thanks for this info.

    I had to send GG_CHGCTRL_ENABLE command to make it work. It was disabled before so that's the reason why whenever I set the INLIM, it will go back to its default value after 40s, because I wasn't in host mode.

    Also, what is the recommendation of TI when it comes to the method of configuring the gauge and charger IC?

    We are initially planning to do it via MCU upon boot up of our board. The MCU will flash the .df.fs file content to the gauge and charger ICs in our board via i2c. To do this, we will embed the .df.fs data to the MCU flash memory but it eats up at least 4kB memory space. Is this usually the method, or is it usually done in assembly during production?

    Also, since I'm not using the default chem_id, it's not recommended to just configure specific registers and not the entire .df.fs file, isn't it?

    Thanks,
  • 0 in reply to mrausol
    TI__Guru 61206 points
    I recommend to use the .df.fs file and program the gauge (the .df.fs file includes charger settings) with TI production tools (bqStudio will work) during production. If you expose SCL, SDA and GND on test points you can hook up an EV2x00 to your board during production and flash the gauge. This is what our customers typically do for mass production with flash gauges.

    The recommended flow is:
    * tune gauge + charger using TI EVM and your battery
    * export .df.fs file
    * program each unit during production with bqStudio and EV2x00 connected to I2C bus
  • 0 in reply to Dominik Hartl11
    Intellectual 690 points
    Hi Dominik,

    Thanks for your timely answer as always.

    I'm trying to convert the voltage reading I get via i2C using command 0x08 and 0x09. 0x08 would read 0xDD and 0x09 would read 0F. I concatenated these values into 0x0FDD.

    What is the formula in translating this to the actual voltage value shown in bqstudio which is 4062mV? I used the formula, (code) x (6000mV/ (2^ 16 bits) - 1) but the result isn't anywhere close to 4062mV. Anything I'm missing out here?
  • 0 in reply to mrausol
    TI__Guru 61206 points

    The parameter is a 2's complement signed integer. It's a direct conversion from hex to decimal: 0x0FDD = 4061 (decimal).

  • 0 in reply to Dominik Hartl11
    Intellectual 690 points

    Hi,

    First of all, thank you again. I'd like clarify again the steps in using the gauge and charger in our system. I've put together the processes and some questions that I have. 

    Could you please comment on the following process and clarify some things?

    Pre-production

    1. Obtain golden image file using BQSTUDIO and EVM board with the battery. This file contains calibration, configuration, and learning cycle data. The output file is in .df.fs.

    2. Parse the .df.fs file into a series of i2c instructions for the MCU. These instructions will be programmed to the MCU.

    (We will take into consideration the method you mentioned above (program the golden file using bqstudio in assembly). But, Is it okay if we approach it as indicated above as an alternative way?

    In production

    3. When the battery is attached to (our) system, it will power up the MCU and the MCU will configure the gauge once.

    4. When I connect/disconnect a battery in the EVM, I noticed that GG_CHGCTRL_ENABLE bit gits reset so I always had to send the command to enable it. Does this mean that along with the configuration, I also have to send this command via MCU at the start? Will this assure that the GG_CHGCTRL_ENABLE will remain set for as long as the battery is connected, even if it discharges to terminate voltage? Our battery is non-removable.

    5. When does the charger have to operate in host mode (GG_CHGCTRL_ENABLE is set)? Since we want to set the INLIM values via MCU (to adjust it depending on the power source connected), I'm thinking of setting Host mode only during charging to make sure the INLIM values get retained, and Normal mode during discharge, since we want to use the AtRate() and AtRateTimeToEmpty(). What do you think of this process?

    6. How to properly use the AtRate() and AtRateTimeToEmpty()? Right now, during discharge, what I'm doing is I'm writing the AverageCurrent() value to AtRate() register every 1 second. And then use the AtRateTimeToEmpty() value to get the predicted time to empty. Is this the correct way of using it?

    6. What happens if the battery is discharged to terminate voltage? Will the configurations be erased and will need to re-configure the gauge again? 

    7. What are the circumstances that will make the configurations be erased? (Disconnecting the battery, sending RESET command, are there any others?)

    8. When discharging, the AtRateTimeToEmpty, SOC, Remaining Capacity are not accurate compared to when charging. Why do you think is this? Is it because I haven’t completed the learning cycle yet?

    9. I have read somewhere here in E2E, that the gauge will eventually update the configuration after many cycles of charging and discharging. Could you confirm this info? Does this mean that the learning cycle is just an “option” for this gauge?

    Thanks,

  • 0 in reply to mrausol
    TI__Guru 61206 points

    Your pre-production method, using a host uC to parse the FlashStream file and program the gauge, is a valid alternative to using bqStudio.

    In production:

    #4: You can set the CMD_NOT_REQ bit in Charger Options, see 3.3 in the TRM. If this bit is set then you do not have to send the GG_CHGCNTRL_ENABLE command.

    If this bit is not set then you will have to send the GG_CHGCNTRL_ENABLE command every time the gauge is reset. This is not the same as discharging the battery to termination voltage. The gauge will stay operational until Vregin drops below 2.45V. So if you stop discharging at let's say 3V then you will not have to send the GG_CHGCNTRL_ENABLE command because the gauge will not go through a power on reset sequence.

    #5: You don't have to disable charger control during discharge. The AtRate functions will still work. The disclaimer in the TRM refers to NORMAL mode as in power mode. This is not related to host mode. Host mode charger control and NORMAL power mode are not exclusive.

    #6a: You don't have to update AtRate every second. The update rate depends on how often you want to update this value in your product (e.g. your user interface). Once every second seems unnecessary? The one second delay that the TRM mentions is the time it takes for the gauge to update the AtRateTimeToEmpty value after you set a new AtRate value. So if your load current is fairly constant, it is not necessary to update AtRate that often.

    #6b: If the Terminate Voltage is above 2.45V, the gauge will simply report 0% SOC at VTerm. If the voltage on Vregin drops below 2.45V (and rises again during charging) then the gauge will go through a power on reset. In either case you do not have to reprogram the gauge (except for commands like charger control enable)because it keeps its configuration in internal flash memory.

    #7: The configuration will not be erased as long as your system doesn't violate the absolute maximum specs (if these are violated, then the gauge may be permanently damaged).

    #8: This could be due to incompatible chemistry (did you obtain a ChemID match from GPC?) or wrong configuration of basic gauging parameters (design capacity, design energy, terminate voltage, charge termination). Accurate SOC will also depend on at least one learning cycle so that the gauge can update the impedance tables and chemical capacity of the actual cell.

    #9: Correct. The algorithm (Impedance Tracking) is designed to automatically update the impedance tables (during each discharge) and the chemical capacity (after qualifying charge and discharge, with minimum relaxation). A Learning Cycle is just a well controlled charge/discharge cycle. Regular use in applications that go through discharge/charge cycles will update this data automatically.

  • 0 in reply to Dominik Hartl11
    Intellectual 690 points

    Hi,

    Thank you for answering my queries.

    I obtained the ChemID in bqstudio database. My battery is Panasonic NCR18500A (1900mah).This is 2040 in the database. Do I still have to do ChemID matching?

  • 0 in reply to Dominik Hartl11
    Prodigy 190 points
    Hi Dominik, i was wondering if you have published the mentioned document already or if it is still in progress. I'm assuming that the described code is applicable to multiple gas gauges or just the bq27531? Thanks in advance!
  • 0 in reply to Johannes Ferch
    TI__Guru 61206 points

    The app note is not officially released but it's in the signoff process so should be on-line any day now. The info is applicable to many gauges, not just the bq27531.

  • 0 in reply to Dominik Hartl11
    TI__Guru 61206 points

    The app note is available now:SLUA801.pdf

  • 0 in reply to mrausol
    TI__Guru 61206 points
    You may not have to do ChemID matching if the cell was identified by name in the database. The only way to know if your cell is indeed compatible with ChemID 2040 is to check with GPC.
  • 0
    Intellectual 690 points

    Hi,

    We are now leaning towards programming the golden file data in production using the EV2400 and BQstudio.

    Is there way to easily verify that the .dffs data were successfully programmed (like a checksum) in the gauge IC data flash via the BQStudio software? What is your recommended production way of doing this? Right now, during development, I'm just doing an eyeball check of the programmed parameters or diff the gg cvs file.

    Thanks,