I2C com to bq27425

Hello Richard,

Pls see attached app note that describes i2C communication for our single cell gauges. It should clarify your questions. i have also attached sample code which you can reference for communicating with our gauge. i hope this helps.

1856.FlashStream028_bundle (2).zip

slua467b[1]_using 2c communication with the bq275xx.pdf

thanks

Onyx

Onyx,

Thank you for your response to my question.  However, I have seen that bq275xx document before.  My understanding is that the 275xx uses commands that have one byte.  Whereas, the bq27425's commands are two bytes long.  That difference is part of my confusion on the structure of the read and write commands to the 27425 chip. 

For instance, it would be very helpful if you would detail the bit pattern for the following sequence of commands.

• Set Hibernate
• Report status
• Set Hibernate
• Report status

Thank you for your help,

Richard Brisk

Hello Richard,

Please check: https://github.com/aneeshv/linux-bq27xxx/blob/t-ambient-fix/drivers/power/bq27x00_battery.c

Let me know if this meets your requirement.

Thanks,

Kang Kang

Onyx,

I eventually did figure out how to send an Extended Data Command.  So, forget my earlier question regarding Extended Data Commands.

I do wish to communicate to TI, however, that I think the bq47245 specification is the most poorly written document of its kind I have ever read.  It takes the equivalent education and parsing of words worthy of a PhD in English literature to figure out what is being described.  It is that poor a description of the commands.  I would be glad to give examples of where it falls short of being even a reasonable explanation, but I doubt that TI would care or even listen.

But as for your help, I do thank you.

Best regards,

RABrisk

Forwarded from Richard :

Although I read and write to the “standard” register area of the bq27425 without any problems, I experience problems when reading and writing to the “Block Data” area. 

Looking for some documentation on this.

Hello Thomas,

What is your sequence when writing block data? Do you enter cfg update mode first?

Thanks,

Kang Kang

Kang,

Thank you for your email.  In response, I put a copy of my code below.

HAL_StatusTypeDef    ReadDataBlock (uint8_t CLASS, uint8_t OFFSET, uint8_t *u8ReadBuffer)
{
   HAL_StatusTypeDef      i2c_result = HAL_OK;
   uint8_t                            u8LocalWriteBuffer[10] = {BLOCKDATACONTROL, 0x00}; //set for 1st I2C Transmit

      //Send BLOCKDATACONTROL+0x00 (i.e., 0x61, 0x00) to enable BlockData() to access NVM and RAM
      if ((i2c_result = I2C_Master_Transmit(&hi2c1, 0xAAAA, u8LocalWriteBuffer, 2, BQ27425_TIMEOUT)) == HAL_OK)
      {
          //Put the Class and Offset, of the BlockData to be accessed, into  BlockData and BlockData+1
          u8LocalWriteBuffer[0] = DATACLASS;     //DATACLASS = 0x3E;
          u8LocalWriteBuffer[1] = CLASS;              //e.g., 0x52;
          u8LocalWriteBuffer[2] = DATABLOCK;    //BLOCK = 0x3F;
          u8LocalWriteBuffer[3] = (OFFSET / 32);  //BLOCK_#: 0, 1, 2, etc.;

           i2c_result = I2C_Master_Transmit(&hi2c1, 0xAAAA, u8LocalWriteBuffer, 2, BQ27425_TIMEOUT);
          i2c_result = I2C_Master_Transmit(&hi2c1, 0xAAAA, &u8LocalWriteBuffer[2], 2, BQ27425_TIMEOUT);
         
          i2c_result = I2C_Master_Receive (&hi2c1, 0xAAAB, u8ReadBuffer, 32, BQ27425_TIMEOUT);

Thanks for your help with the bq27425 communication.  As of now, I am all set.

Thanks again,

Richard Brisk

New Problem, not sure if it should have its own thread.

I2C locking up.

The problem is that there are times when the bq27425 “locks up.” The specifics of the lock up are that it first returns a BUSY to some I2C comm (reason unknown). Following that BUSY, it returns a TIMEOUT to all future I2C comms to read or write to the chip.

This is a major, major problem since the chip becomes totally unresponsive to all requests for information.

The problem is made severe because there does not seem to be a way to unlock the chip. At least, to date I have not found a way to unlock the chip. Even sending a Hard Reset does not bring it back to life. I urgently need a solution to the problem.

Is this a known issue? Is there a work-around?

Thanks!

I have some SHOW STOPPING ISSUES around the State Of Charge 0x1c/0x1d value I get when polling the bq27425 I am using.  I need good answers quickly.

Here are my concerns:

1) It takes 5 minutes to get a reading for the State Of Charge that is not 0%. 

Is that expected? 

Can anything be done to get results more quickly?

2)  When the State Of Charge 0x1c/0x1d value does appear it is always 100%.  That cannot be correct.  What is going on?

3)  The State Of Charge 0x1c/0x1d value never shows any value other than 0% if the battery is discharging (ie, average current and average power are both negative).  What is going on with that?  And, how can I correct that problem?

These are SHOW STOPPING ISSUES.  Please respond.

Kang,

Thank you for your prompt answer. 

With regard to your comment about the BAT_DET flag:  We have chosen to inform the bq that the battery is installed by sending a BAT_INSERT command to the chip.  We do this because our hardware does not implement the auto detect capability.

With regard to the 5 min problem:  I am still looking into this issue.  I will send you more information when I have something to send.

Thank you again,

Richard Brisk