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.

ReadSMBusWord what is it doing

Other Parts Discussed in Thread: BQ3060

Hello,

  I am using the F28069 to try to communicate with the BQ3060.  In all the documentation I see code referencing ReadSMBusWord().  I am unable to find what the I2C receive should look like.  Does anyone know what this function should look like?

  Currently I am using the following and get a NACK on the I2C line after I try to send the device address and register number.

Here is my code:

  #define DEVICE_ADDRESS  0x16

  #define cc_voltage 0x09

  #define BUFF_LENGTH 2

  Unsigned char batter_com_buffer[BUFF_LENGTH];

Uint16 get_battery_voltage_register_value(void) {
  Uint16 register_value;
  if(i2ca_recv(DEVICE_ADDRESS, cc_voltage, 2, battery_com_buffer) != 0) {
    return(0);
  }
  register_value = ((Uint16)battery_com_buffer[0]) * 256;
  register_value += ((Uint16)battery_com_buffer[1]);
  return(register_value);
}
int i2ca_recv(Uint16 dev_addr, Uint16 reg_addr, Uint16 length,
  unsigned char* rx_buffer) {
	int i = 0;
	int return_value = 0;
	I2caRegs.I2CSTR.bit.NACK = 1;
	if(I2caRegs.I2CMDR.bit.STP == 1) {		//if not cleared
		return (1);							//error
	}
	//  setup the command to send the device address and the register address
	//    in master transmit mode
	I2caRegs.I2CMDR.all = 0x0620;  // send first bit without the stop bit
  // setup the device address
  I2caRegs.I2CSAR = dev_addr;
  // set the byte count
	I2caRegs.I2CCNT = 1;  // setup the number of register address bits
	// set the first(only) byte into the transmit register
	I2caRegs.I2CDXR = reg_addr;
	// set start bit (start transmitting)
  I2caRegs.I2CMDR.bit.STT = 1;
  // if we get a nack on the address
  if(I2caRegs.I2CSTR.bit.NACK == 1) {
	  I2caRegs.I2CMDR.bit.STP = 1; // stop transmission
	  return(1);
  }
  // wait until the I2C module is ready continue
  while(I2caRegs.I2CSTR.bit.ARDY == 0) {
    if((I2caRegs.I2CSTR.bit.ARBL == 1)) {
      return(2);
    }
  }
  // re-setup device address
  I2caRegs.I2CSAR = dev_addr;
  // set the transceive length
  I2caRegs.I2CCNT = length;
  // set to receive
  I2caRegs.I2CMDR.bit.TRX = 0;
  // send start command
  I2caRegs.I2CMDR.bit.STT = 1;
  //get the data from the line
  for(i = 0; i < length; ++i) {
    while(I2caRegs.I2CSTR.bit.RRDY == 0) {
      if(I2caRegs.I2CSTR.bit.NACK) {
        ++return_value;
        break;
      }
    }
    if(I2caRegs.I2CSTR.bit.NACK) {
      ++return_value;
      break;
    }
    rx_buffer[i] = I2caRegs.I2CDRR;
  }
	I2caRegs.I2CMDR.bit.STP = 1; // stop transmission
	return(return_value);
}
  • This document may help understand the SMBus protocol that we use. 

    SMBus made simple_v6.pdf
  • Thomas,

      Thank you for the quick reply and the reference document.  Some thing that I noted (which led to being able to start communicating).

      In the examples that show the read and write word for the SMBus the sent address was 0x16.  In using the TI piccolo series chips I2C module, this would then lead to a device address of 0x0B (which is just 0x16 shifted right one bit).

      This is because in the I2C module on the chip, the device address is automatically left justified (shifted one bit left) and the read/(!write) bit is appended to the address in the LSb position.  I am not sure how the rest of the TI chips work, or how a native SMBus module works, but this was the problem that I was running into.

      Also of note to those that read the document that was attached to the post, there is a diagram misrepresentation of the read/(!write) bit as the SMBus protocols are shown.  The "W" should have an over  line above it or some other indication to let you know that the write is set as a zero bit.  (Not sure how to show an over line in this text.)  This is clearly defined as you read the document and I know it is standard protocol, however, being unfamiliar with SMBus vs I2C, and in a hurry :P, this sent me down a small rabbit hole.

      Thanks again!

    John