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.

BQ27427EVM: misbehaving StateOfCharge()

Part Number: BQ27427EVM
Other Parts Discussed in Thread: BQ27427, BQSTUDIO, BQ27426

I am evaluating the BQ27427 EVM connected to a test rig which charges and discharges the battery.
While Temperature() and Voltage() commands work as expected, the reported StateOfCharge() looks wrong: it decreases while the battery is charging and increases while discharging, at some point it stays at 99% or jumps randomly.
What could be the reason for this?

Investigating this, I noticed that AverageCurrent() shows a positive value while discharging and a negative value while discharging - is this by design? Could this be the reason for misbehaving StateOfCharge()?
I triple-checked the wiring on the EVM:
- PACK- of the BQ27427 is connected to LiPo cell's negative terminal, PACK+ to the positive
- LOAD+ and CHARGER+ of the BQ27427 are connected to our battery-test-rig's positive terminal, LOAD- and CHARGER- to the negative
- J10 connects with the I2C interface of our microcontroller board (GND, SDA, SCL)

  • Please change the sign of the CC Gain parameter. It must be positive.

  • Thanks for the information. I am still running a test cycle, but so far it does look promising: soc [%] now rises during charging and the current is positive.


    However, I am testing this using bqStudio BQ27426G1 (which feels hacked, since it is not really my chip model, but it works) and this parameter is not documented in the TRM (SLUUCD5) for the BQ27427 Disappointed

    Since we want to control the bq27427 with a microcontroller, how can I access this parameter in firmware? What is the subclass ID and offset?
    Is it safe to assume this parameter address will not change in future (aka. safe to use in production)?

  • We'll release a bqStudio version asap that has the bq27427 plug-in. The bq27427 runs the same firmware as the bq27426 on the same silicon except with an internal sense resistor, hence it's ok to use the bq27426 plug-in (but of course we'll update bqStudio).

    You can change the sign of CC Gain with the following process (prerequisite: unseal gauge:

    1. Send command SET_CFGUPDATE (sub-command 0x0013): write 0x13 0x00 to I2C command/register 0x00
    2. Poll Flags() until the CFGUPMODE bit 4 is set
    3. Write 0x69 0x00 to I2C command/register 0x3E (this selects sub-class Calibration)
    4. Read one byte from register 0x45 (this is the byte from CC_Gain that holds the sign in bit 7)
    5. Read one byte from register 0x60 (this is the check-sum)
    6. Flip bit 7 from the byte read in step 4 and write it to register 0x45
    7. Flip bit 7 from the byte read in step 5 and write it to register 0x60
    8. Send command SOFT_RESET (sub-command 0x0042): write 0x42 0x00 to I2C command/register 0x00

    Example:

  • Ok, trying this in bqStudio works! Thanks for the detailed instructions and individual i2c byte transfer explanation, it helps a lot.

    Since I want to implement this in firmware and verify/observe the CC_Gain value, how could I read the whole float, opposed to just one byte which holds the sign? The subclass is 0x69, but what is the offset? How do I need to interpret the bytes in order to get a float?

    I tried reading 4 bytes at subclass 0x69, offset 0x04 and interpreting them as a float, but the result does not make sense. I tried reversing the byte order, but it did not help.
    There is no other (documented) four-byte floating point number in the dataflash @TRM which would allow me to figure this out on my own.

  • This gauge uses a non-standard floating point format from Xemics. The floating point format conversion is documented in https://www.ti.com/lit/an/slva148a/slva148a.pdf, Appendix A.

    You can find offset info for all parameters in bqStudio, if you select Window->Preferences->Show Advanced Views.

    CC_Gain is in class 0x69, block 0, offset 4, 4 bytes in big endian. 

  • Ok, I see now. Thanks a lot!