Bq27510 communications problem

Ken,

Let's talk about the packet sequence:  If you are issuing the DEVICE_TYPE command (0x0001), then you will use the following I2C Sequence:

START; 0xAA (write); 0x00; 0x01; 0x00; STOP      (write 0x0001 to address 0x00, byte reversed)

START: 0xAA (write); 0x00; START; 0xAB (read); XX; YY  STOP   (read 2 bytes XX and YY from address 0x00 and 0x01)

The gauge will return with 2 bytes: which for you will be the following

XX: 0x00

YY: 0x05

When combined (byte reversed), they form 0x0500 (the "500" in bq27500)

Let me know if this makes sense.

Thanks,

Charles

Thanks for the Quick response Charles!

Yes this makes sense and is the sequence I'm sending, yet I get back something like 0xDF, 0xFF as a return. Are there any delays required in this sequence? This is connected to a Jennic 5148 module, the I2C only has a polled mode and it's a little squirelly, so I'm not sure the timing is exactly I2C. I have tried this I2C with 4 other parts and it does seem to work, but the command sequences were all like the BQ's simple commands, 1 cmd byte, 2 return bytes. This subcommand index seems be where the problem is. This I2C does not have an explicit 'restart' bit control, so on the START to read, it is a new start bit.

Thanks

Ken

Ken,

There should be at least a 66uS delay between packets.  This is documented, but it is buried somewhere.  I have copied in the relevant data:

I2C TIME OUT
The I2C engine releases both SDA and SCL if the I2C bus is held low for about 2 seconds. If the bq27500
was holding the lines, releasing them frees the master to drive the lines. If an external condition is holding
either of the lines low, the I2C engine enters the low-power sleep mode.

I2C COMMAND WAITING TIME

To make sure the correct results of a command with the 400-kHz I2C operation, a proper waiting time should be added between issuing the command and reading results. For subcommands, the following diagram shows the waiting time required between issuing the subcommand and reading the results, with the exception of checksum and OCV commands. A 100-ms waiting time is required between the checksum command and reading the result. For read-write standard commands, a minimum of 2 seconds
is required to get the result updated. For read-only standard commands, there is no waiting time required, but the host should not issue all standard commands more than two times per second. Otherwise, the gauge could result in a reset issue due to the expiration of the watchdog timer.  If the Operation Configuration [I2C_NACK] bit is not set, the I2C clock stretch could happen in a typical application. A maximum 80-ms clock stretch could be observed during the flash updates.

Let me know if this helps,

Charles

I saw this but somehow missed the 66usec bit.... I'll code this up in awhile and let you know if it works.

I did observe the 2 second poll restriction and this works ok on the major commands.

Thanks

ken

Charles,

Coded up the delays and it worked just fine.. My notes show I did try this, but put the delay in only one place, clearly not enough..

Thanks again for the help. Hope I can repay the favor in the future

Regards

Ken Tait

Charles

I have an additional question on the BQ27510.

On the first page of the data sheet it says it needs a sense resistor of 10m ohm or less.

Later on it says 5-20m ohms..Which is right?

I do not see any register to set the value of this resistor and i can't seem to find an explanation of this in the data sheet. Why is there no section explaining this critical item?

Is this value set only with a calibration procedure when making the golden file?

Right now I used a 25m ohm value, that came from using a previous part data sheet as an intial reference. Is this value out of range for this part?

Current draw in this app will be 200ma or less at all times, is there a 'sweet' spot in which the value results in a more acurate reading?

Thanks

Ken

Ken,

I am using bq27510-G2 in my application. I have used it in by board, i.e. system side solution.

When I give I2C Read command, I am getting 0xFF, 0xFF for battery voltage register at address 0x08 and 0x09.

I am using slau467a.pdf as reference.

Command sequence I use for Read are

START, 0xAA, 0x08, START, 0xAB, Data[0], Data[1],STOP.

I gone through conversation between you and charles , but I am not clear about 66usec delay. I am not even able find it in document I have.

Please provide your suggestion.

Khodidas

Hi Khodidas,

the timing requirements are not specified in the document you are looking at.

You can find them in the BQ27510-G1 data sheet in 2 places. It is NOT in the G2 data sheet although they are actually the same parts with different firmware.

Page 31 has "I2C command Waiting Time" which describes the issue.

Page 6 has the I2C timing specs. Look at the bottom, 'Bus free time between start & stop'. this is where the 66us comes from.

I have implemented this and communcations is fine at 400khz, however not quite right at 100khz. Notice there is no spec at other I2C rates...so I don't know what's up with this.

The part has a CPU in it and the delay is required for it to extract the data and put it into the ouput registers, that is why it is needed. This is OK, but it means that you need special I2C read/write routines to handle this part. Generic routines will not work.

Be extremely careful when trying to program a battery profile using the TI software. I managed to brick my first part doing this.

While uploading the profile, the process just froze. I had no choice but to kill the program. When i tried to restart and talk to the part, it refuses all communication.

Multiple request to TI and corporate have resulted in NO further info as to why this is happening, so be careful here.

The TI software is based on VB6 and it is very flaky on some machines. Had to move it twice just to get it to work the first time. There does not seem to be a mechanism to 'force program'  the part or reload the firmware in this type of total failure situation, at least not that I can find. This is of great concern, especially on the manufacturing floor...

Good Luck

Ken

2870.System Side Battery Gauge Solution.pdf

#include "doorlock.h"

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Constnat Definition for Battery Gauge IC (I2C)
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#define WRITE_ADD 0xAA
#define READ_ADD 0xAB

#define NACK1 0
#define ACK1  1


//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Proto Definition
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Write(unsigned char *ucram_add,unsigned char i2c_add,char count);
void I2C_Read(unsigned char *ucram_add,unsigned char i2c_add,char count);
void I2C_Start(void);
void I2C_Stop(void);
void I2C_Delay(void);
void I2C_Clock(void);
void I2C_WrDly(void);
unsigned char I2C_Xmit(unsigned char data);
unsigned char I2C_Rcv(unsigned char ack);

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Varriable Definition
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
char i2c; 

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Extern Proto Definition
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Extern Varriable Definition
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++


//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Write I2C from @RAM location
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Write(unsigned char *ucram_add,unsigned char i2c_add,char count)
{
      char temp;	
      for(i2c=0;i2c<count;i2c++)
      {
	  I2C_Start();    		
	  I2C_Xmit(WRITE_ADD);		  	// TRANSMIT 8 BITS SERIALLY [ADDRESS/DATA]
	  I2C_Xmit(i2c_add);
		
	  temp=*ucram_add;
	  I2C_Xmit(temp);
	  I2C_Stop();
          
	  I2C_WrDly();
	
	  i2c_add++;
	  *ucram_add++;
      }
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Read I2C and store @RAM location
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Read(unsigned char *ucram_add,unsigned char i2c_add,char count)
{
    for(i2c=0;i2c<count;i2c++)
    {
        I2C_Start();
        I2C_Xmit(WRITE_ADD);			// TRANSMIT 8 BITS SERIALLY [ADDRESS/DATA]
        I2C_Xmit(i2c_add);
    
        I2C_Start();				// Repeat start CONDITION - 1 TO 0
        I2C_Xmit(READ_ADD);			// TRANSMIT 8 BITS SERIALLY [ADDRESS/DATA]
        

        if(i2c == (count - 1))
        {
            *ucram_add=I2C_Rcv(NACK1);           // Read last 8-bit data with no ACK
        }
        else
        {
            *ucram_add=I2C_Rcv(ACK1);            // Read 8-bit data & then send ACK   
        }
        I2C_Stop();
        
        i2c_add++;
        *ucram_add++;
    }
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// I2C Start
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Start(void)
{
      // START CONDITION - 1 TO 0
      I2C_MASTER_OUT |= I2C_MASTER_SDA;           // SDA=1
      I2C_Delay();
      I2C_MASTER_OUT |= I2C_MASTER_SCL;           // SCL=1
      I2C_Delay();
      I2C_MASTER_OUT &= ~I2C_MASTER_SDA;          // SDA=0
      I2C_Delay();
      I2C_MASTER_OUT &= ~I2C_MASTER_SCL;	  // SCL=0;
      I2C_Delay();	
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// I2C Stop
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Stop(void)
{
      // STOP CONDITION - 0 TO 1
      I2C_MASTER_OUT &= ~I2C_MASTER_SDA;        // SDA=0
      I2C_Delay();	
      I2C_MASTER_OUT |= I2C_MASTER_SCL;	        // SCL=1
      I2C_Delay();
      I2C_MASTER_OUT |= I2C_MASTER_SDA;         // SDA=1
      I2C_Delay();
	
      I2C_MASTER_DIR |= (I2C_MASTER_SCL + I2C_MASTER_SDA);	//I2C line OUTPUT	
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// I2C Delay 
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Delay(void)
{
      _NOP();
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// I2C Clock
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_Clock(void)
{
      I2C_Delay();
      I2C_MASTER_OUT |= I2C_MASTER_SCL;	            // SCL=1
      while(!(I2C_MASTER_IN & I2C_MASTER_SCL));     // Wait for any SCL clock stretching
      I2C_Delay();
      I2C_MASTER_OUT &= ~I2C_MASTER_SCL;            // SCL=0
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Write Delay Time for I2C
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void I2C_WrDly(void)
{
      /*
      ;-------- LONG DELAY -------- 	
      ;i2c1           i2c2             TIME
      ;-------       -------         ----
      ;20             250            2.5mSec @8MHz
      ;40             250            5.0mSec @8MHz
      ;80             250            10.0mSec @8MHz
      */

      unsigned char i2c1,i2c2;

      for(i2c1=80;i2c1!=0;i2c1--)
      {
	  for(i2c2=250;i2c2!=0;i2c2--);
      }
}
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// I2C X'mission of Data
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
unsigned char I2C_Xmit(unsigned char data)
{
      char i2ck;
      unsigned char ack;

      I2C_MASTER_OUT &= ~I2C_MASTER_SCL;              // SCL=0;
      
      for(i2ck=0;i2ck<8;i2ck++)
      {
	  if(data & 0x80)
          {                  
	      I2C_MASTER_OUT |= I2C_MASTER_SDA;       // SDA=1
          }                        
	  else
          {                 
	      I2C_MASTER_OUT &= ~I2C_MASTER_SDA;      // SDA=0
          }                        
	  I2C_Clock();
	  data= data << 1;		
      }
      I2C_Delay();
      // 9th Clock for ACK
      I2C_MASTER_OUT |= I2C_MASTER_SDA;               // SDA=1
      I2C_MASTER_OUT |= I2C_MASTER_SCL;               // SCL=1
      while(!(I2C_MASTER_IN & I2C_MASTER_SCL));       // Wait for any SCL clock stretching
      I2C_Delay();
      ack = (I2C_MASTER_IN & I2C_MASTER_SDA);         // Read ACK state from Slave
      I2C_MASTER_OUT &= ~I2C_MASTER_SCL;              // SCL=0;
      if(ack)                                         // Return ACK state to calling app
          return (1);
      else
          return (0);
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Receive Character on I2C
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
unsigned char I2C_Rcv(unsigned char ack)
{
    char data=0;
    char i2ck;
    I2C_MASTER_DIR &= ~I2C_MASTER_SDA;                     // SDA is configured as INPUT

    for(i2ck=0;i2ck<8;i2ck++)
    {
	I2C_MASTER_OUT |= I2C_MASTER_SCL;                  // SCL=1
        while(!(I2C_MASTER_IN & I2C_MASTER_SCL));          // Wait for any SCL clock stretching
	I2C_Delay();

        data = data << 1;				    // Shift the bit over
	if(I2C_MASTER_IN & I2C_MASTER_SDA)
	{
	    data |= 0x01;
	}		
	I2C_Delay();
	I2C_MASTER_OUT &= ~I2C_MASTER_SCL;            // SCL=0
	I2C_Delay();
    }
    
    I2C_MASTER_DIR |= I2C_MASTER_SDA;	              // SDA is configured as OUTPUT
    if(ack)                                           // Need to send ACK to Slave?
    {
        I2C_MASTER_OUT &= ~I2C_MASTER_SDA;             // Yes, so pull SDA low
    }
    else
    {
        I2C_MASTER_OUT |= I2C_MASTER_SDA;             // No, so keep SDA high
    }
    I2C_MASTER_OUT |= I2C_MASTER_SCL;                 // SCL=1;
    I2C_Delay();                                      // Equivalent to sending N(ACK)
    I2C_MASTER_OUT &= ~I2C_MASTER_SCL;                // SCL=0;
    I2C_MASTER_OUT |= I2C_MASTER_SDA;                 // SDA=1
    return data;                                      // Return 8 bit data
}

Ken,

Thanks for your reply.

I think as per bq27510-G1 data sheet,  between read and write command, 66usec delay is required.

I have attached my code here along with schematic. I am not using any TI tool to read gauge.

Only way i am accessing gauage is by I2C master using MSP430F5310.

At present I am only executing, Read command for voltage, but I am getting 0xFF for that. I2C clock is of 8usec i.e. 125KHz.

Is clock frequency can be issue? I am operating MSP @8MHz and using "bitbang" for I2C.

I have not written any command in gauge? Do I need to write anything to make it active?

Below is routine, which read voltage register @every 4 second.

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Read Battery Data
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void battery_read(void)
{
I2C_Read(BatRxData,bq27510CMD_VOLT_LSB,1);
Delay();
// voltage = transBytes2Int(BatRxData[1], BatRxData[0]);
//I2C_Read(BatRxData,bq27510CMD_DNAME,7);
}

Do you see anything wrong in mycode? If you have working I2C routine, can you provide that?

Regards,

Khodidas

Khodidas,

Have you checked the sample MSP430 code in this app note?

http://focus.ti.com/analog/docs/litabsmultiplefilelist.tsp?literatureNumber=slva413a&docCategoryId=1&familyId=412

There are two links on that page.

The PDF describes the projects and the ZIP file contains the code.  It shows both bit-banging and I2C bus communication.

Khodidas

First, the 125khz speed should not be an issue, it's close enough

There are 3 reasons to get 0xffs back on the I2c.

Either the chip address is wrong,(part never heard you), the sequence of events is wrong,(possible bus collision),  or for this part the delay is wrong or in the wrong place,(you missed the message).

Make sure your pullup resistors are in the range..10k for 125khz should be fine, may need 2.2-4.7k for 400khz depending upon what else is on bus.

the chip addess is 0xAA, now that is an 8 bit address, only 7 bits make it to the bus. The lower bit is read/write, so be sure your code or the I2C hardware if there is any, is not shifting this improperly. Many code libraries require this to be 'pre-shifted' by (1 bit>>=1).

You said you are bit banging the port? I don't see this in the code snippet. I'm not too familiar with the msp430 peripherals, so I will have to take a look here to see if indeed it is bit banged or there is a real I2C hardware interface.

Do you know if the I2c code works on any other parts? A serial eeprom is pretty straightforward to test with to make sure the basics are working as expected.

Let's take one command at a time, say read voltage which should always work, oh by the way make SURE you have a battery connected to the chip and it is powered or nothing will work....when you first connect one, the chip locks you out for about 30 sec or so while it takes some initial readings, so wait...

Use this legend W=wait for transfer, S=start bit, STP=stop bit,D(66)=delay 66 usec

Reading voltage here(0x08) Concentrate on this first until you get the I2C to work.

send this sequence: S, 0xAA,W,0x08,W,S,0xAB,W..read byte 0, read byte 1,STP

In this sequence, normal commands, no delays are required since the registers asked for are immediately available.

For a control command, it's a little more involved. You have to set this up first, wait for the part to switch internally before reading.

Reading CSTAT register here.(0x0000)

S,0xAA,W,0x00,W,0x00,W,0x00,W,STP,D(66),S,)0xAA,W,0x00,W,S,0xAB,W, read byte 0, read byte 1,STP

Bear in mind that you also cannot sit in a loop and continuosly read the gauge. There is another delay, time between commands that's not mentioned much. I think it is 2 seconds??

this has to do with some internal power down timer. I have not seen a credible explanation about this yet. this kind of delay makes it harder for the software to service the gauge.

My gut feeling is that the main problem is your I2C low level code. For a part like this it is very difficult to 'bit bang' it on a port pin. the timing is critical and it's easy to miss a bit transistion and respond quick enough. this part can also stretch the clock for certain operations, so if you are trying to program the profile in system, this may be a real problem with a non hardware controlled I2C port.

My working code is for a part that has a real I2C hardware controller with state machine, so it would be of no benefit to you.

I have worked with many embedded I2C ports. They are ALL different. Not all work under all conditions correctly. Some do not support things like clock stretching. My advice would be to first make sure this works as expected with a known part you are familiar with. The fact that ANY delays are required in the TI part is really non standard to the I2C spec, so you must make some changes to any library code to get it to work.The only legitimate delay is clock stretching and there are limits on this too. Things like this make it difficult to build mission critical code. You really need to build in timeouts on transfers to make sure things don't hang up on you. while() loops are NOT the way to go here. Don't expect every transaction to be perfect, all kinds of outside influences can break this, you must defend against it in your code.

Hope these suggestions help

Ken

Just a quick P.S.

Looked at your schematic and I don't think this is correct.

The REGIN pin is connected to batt, not a good idea. This can load the battery reading and does not provide a reliable source for the 2.5v regualtor..I would think up another way to do this.

also, the current sense filter is missing?? Why did you do this?

Where does BAT_INSERT_I/P_TO_HOST go?? if this is dragging down the regualtor, then the chip is off.....

GND is on the wrong side of the resistor to the op amp???...Reference is TO the BQ27510, not the load.

is the op amp characterized to work at 8volts??? check this...

Ken

dMax,

Thanks for your reply.

Yes I have checked code given in slva413a.zip  In fact I have modified by original bit bang which was working ok with EEPROM, as per the code given in this zip

file for bq275001651.I2C_GPIO_GAUGE.rar.

I have separated bitbang part, and code is attached here in ZIP.

 One thing I am not clear here is the way this code provides delay...

  __delay_cycles(GPIODELAYCYCLES); // Quick delay

Other point is it keeps I2C lines low at power up.

If you can comment on this(delay aprt) I will try to use same code, as I am using 8MHZ clock while this code is using 1MHz clock.

Insted   of this I am providing delay by _NOP(); instruction.

Thanks,

Khodidas

Ken,

(1) is the op amp characterized to work at 8volts???  

Ans1:

First of all I have two cell each of 3.6V in my system, hence total is 7.2V.

bq27510-G2 is single cell IC, Hence I have used  SLUA387, link given below as reference.

http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slua387&fileType=pdf

As per this i used divider by resistor and voltage follower with opam to convert 7.2V to 3.6V. Opam I used TLV2241 can work with supply from 2.5V to 12V.

(2) The REGIN pin is connected to batt, not a good idea. This can load the battery reading and does not provide a reliable source for the 2.5v regualtor..I would think up another way to do this.

Ans2: 

Now as per datasheet of bq27510DRZ, page 32, reference schematic,

PACK+ voltage (3.6V for single cell) going into REGIN and BAT pin of gauge IC. In my case PACK+ is output of voltage regulator.

Let me know if this is understanding based on reference schematic is wrong.

(3) GND is on the wrong side of the resistor to the op amp???...Reference is TO the BQ27510, not the load 

Ans3:

Again this as per datasheet of bq27510DRZ, page 32, reference schematic.

(4) Where does BAT_INSERT_I/P_TO_HOST go?? if this is dragging down the regualtor, then the chip is off..... 

 Ans4:

This is open drain I/O. I apologies as bcz in final schematic I added 1.8M pullup as per refrence schematic which is not in schematic I sent to you.

Schematic with that change is attached here.1057.gauge.pdf

This pin is going in I/O pin of MSP430.

(5) also, the current sense filter is missing?? Why did you do this? 

 Ans5:

Yes, I agree with you. I missed it, but as I know it's filter. So its will make affect on result, but will it make IC non functional?

 This is how I designed it. I had also some QA session during schematic design , below is link of it.

http://e2e.ti.com/support/power_management/battery_management/f/180/p/111349/396311.aspx#396311

Let me know if still there is any thing wrong in my understanding.

Thanks,

Khodidas

Ken,

[Q] Make sure your pullup resistors are in the range..10k for 125khz should be fine, may need 2.2-4.7k for 400khz depending upon what else is on bus.

[A]  I am using 4.7K as pull up for both line. There is no other device on this line. It's single master, single slave config.

[Q] Do you know if the I2c code works on any other parts? A serial eeprom is pretty straightforward to test with to make sure the basics are working as expected.

 [A] Yes, I have same code working fine with EEPROM and LIGHT sensor, which works on I2C. It is bitbang only.

[Q] when you first connect one, the chip locks you out for about 30 sec or so while it takes some initial readings, so wait.

[A]  I see this and other time as issue. I will try again as per suggestion and let you inform.

Thanks for quick response.

Regards,

Khodidas

Khodidas,

I don't know what level hardware/software guy you are, so my questions are desinged to ellicit this so I can help you on the right level, please don't read more into it.

Don't always trust reference schematics and app notes as being 100% correct. they are meant as a general idea and omit alot of details in most cases. I've been burned by this many times.

I'm familiar with the app note you used, be aware of the fact that it doesn't add any protection from the charger 'overvoltaging' the battery...This can happen depending upon it's source

for charging voltage. I doubt TI actually built this circuit and tried it.

As long as the BAT_Insert pin is configured as an input on the MSP430 and is high along with a valid 2.5 volts on the regout pin, then there is no reason the chip should not talk to you unless there is a hardware issue?? Short, open bad solder job....

That being said if this IS NOT THE CASE, the problem is probably all software.

delay routines in libraries usually use a #define somewhere to tell them what your clock frequency is. Something like # define CPU_CLK 16000000L or similar.

Sometimes this is passed on the command line by the build environment. If this is not set or wrong then your delays are way off.

Using NOPs as delays is a bad idea in general. I see lots of programmers do this and it bites you in the ass quickly..

The reason is that most modern compilers, even when optimization is turned off can optimize these out, so they are not there in the final code. Most debuggers won't put a breakpoint on them either. Library delay routines use a short assembler routine where the actual clock cycles to execute are a known quantitiy, so they are good over 5 us, anything smaller usually gets rounded up.

The best way to do this is to dedicate a hardware timer to it. That way it will always be correct and the compiler can't change the timing on you if you need accurate timings.

Have you put a scope on the I2C_SCK pin and verified you have a valid clock around 100khz? I know you said its about 125khz, but did you scope this?

Can you capture the I2C_SDA line and see if the chip attempts to send anything back or is the line dead or held?

You have to be meticulous to solve this problem, don't assume since you checked something a few days ago, that it's still the same.

This is about the only way I know of to figure out where the problem in timing is, and I would say that is the issue.

I'll look at your software if I get a chance.

Ken

Ken,

I was able to read bq27510 with inbuilt I2C engine of MSP430F5310. Right now I am using EVM of bq27510 and My card as I2C Master.

thanks for all your support.

Regards,

khodidas