Other Parts Discussed in Thread: MSP430F5338, BQ34Z100
We are using the MSP430F5338 to communicate with the bq34z100 over I2C via the UCB0 port, and we are running into interesting behavior that I am hoping you might be able to assist me with.
What we are looking to accomplish is to find out more information about the battery to confirm which power state the battery is in (e.g. charging or discharging). Our current methodology of this approach is to send two write commands, followed by two read commands using the Flags data command. We are using 0xAA as the address (giving the address register 0x55 however as it is shifted according to the user guide) and providing subsequent data as: 0x0E, 0x00 followed by the next write command as 0x0F, 0x00. On rare occasion the fuel gauge will return with a NACK.
For the read commands, we are beginning the same way as the write commands: 0xAA address followed by data 0x0E for the first read command. Following this we do a repeated start followed by 0xAB. This is where the behavior changes to something unexpected. The SDA line stays low, until the fuel gauge responds with some sort of data. While the data appears on the line, it appears as though the clock continues to be driven continuously as though the master is still expecting to see the data. This appears to be corrupting the second read command by not executing properly.
The same issue is seen while requesting the second byte, with one additional caveat. It appears as though the software does not recognize the clearing of the UCTXSTT bit. While it is not being cleared, the SDA line is held high and the SCL line is held low.
My main questions for you are, what would a possible reason for a NACK being sent by the fuel gauge occasionally? Do you have an idea of why the MSP430 does not recognize the data being returned from the Fuel gauge and continues to drive the clock?