Problem reading MAX17205 Fuel Gauge over I2C

[Tony Blake]

Posted on April 30, 2018 at 10:52

Hi,

I have a MAX17205 Fuel Gauge connected to an STM32373C-EVAL board over I2C. I'm trying to read the DEVNAME register on the MAX17205 as a communication test but am getting a NACK error. I've checked the I2C signals on a scope and taken a screen grab which is attached.

I've set the following parameters in the firmware as specified in the MAX17205  datasheet:

&sharpdefine MAX17205_ADDRESS                     0x6C

&sharpdefine MAX17205_DEVNAME_REG            0x021

And I'm right shifting the slave address before I call the I2C read function, as specified in the HAL I2C driver:

HAL_I2C_Mem_Read_DMA(&I2cHandle , (uint16_t)MAX17205_ADDRESS >> 1, (uint16_t)MAX17205_DEVNAME_REG, I2C_MEMADD_SIZE_16BIT, (uint8_t*)aRxBuffer, RXBUFFERSIZE);

I am using the I2C_EEPROM example from the STM32CubeF3 SDK and can successfully read from/write to the EEPROM on the STM32373C-EVAL board over the same I2C bus (I2C1) and same I2C pins (PA9/PA10). I've double checked the connections to the MAX17205 and they seem fine.

Anyone have any suggestions? Would appreciate your help.

Cheers,

Tony

#stm32f373-eval #read-i2c #max17205

[Tony Blake]

Posted on April 30, 2018 at 13:02

Correction: 12C2 bus

[waclawek.jan]

Posted on April 30, 2018 at 13:19

I'm right shifting the slave address before I call the I2C read function

Try not to.

JW

[Tony Blake]

Posted on April 30, 2018 at 16:38

Hi Jan,

I've omitted the right shift from the slave address before the read operation and it looks like I am now getting the correct signals on the I2C bus, i.e. a correct SDA read signal with START command, slave address etc. For some reason, I am only receiving garbage from the MAX17205 when I read the DEVNAME register.

Could you suggest why this might be happening?

Also, the HAL I2C driver does say that the 7 bit slave address needs to be right shifted before doing a read operation. Can you explain why the right shift is not needed?

Cheers,

Tony

[waclawek.jan]

Posted on April 30, 2018 at 19:03

Also, the HAL I2C driver does say that the 7 bit slave address needs to be right shifted before doing a read operation. Can you explain why the right shift is not needed?

It's the 8-bit slave address given by manufacturer, which has to be right shifted to get the needed 7-bit address.

But some manufacturers give 7-bit address which then does not need to be right shifted.

I looked into the MAX17205  DS and found no clear indication whether the given address(es) is(are) 8-bit or 7-bit, so simply told you to do what's needed for the other possible option.

I am only receiving garbage from the MAX17205 when I read the DEVNAME register.

What exactly is that 'garbage'? Is it consistent (i.e. the same every time you try)? Is what you see in the memory the same what you see coming in through SDA on the scope/LA?

JW

[Tony Blake]

Posted on May 01, 2018 at 16:17

Hi Jan,

It's hard to tell from the scope what exactly is going on. I've carried out a better test to check the communication:

1) I've reset the MAX17205 by writing 0x01 to the CONFIG2 register:

 MAX17205_write_result = HAL_I2C_Mem_Write_DMA(&I2cHandle , (uint16_t)MAX17205_ADDRESS, (uint16_t)MAX17205_CONFIG2_REG, I2C_MEMADD_SIZE_16BIT, (uint8_t*)MAX17205_TX_BUFF, sizeof(MAX17205_TX_BUFF));    if(MAX17205_write_result != HAL_OK){        Error_Handler();

}    

 /* Wait for the end of the transfer */ 

while (HAL_I2C_GetState(&I2cHandle) != HAL_I2C_STATE_READY)

{}

2) I've then read back the CONFIG2 register immediately after the write operation:

MAX17205_read_result = HAL_I2C_Mem_Read_DMA(&I2cHandle , (uint16_t)MAX17205_ADDRESS, (uint16_t)MAX17205_CONFIG2_REG, I2C_MEMADD_SIZE_16BIT, (uint8_t*)MAX17205_RX_BUFF, sizeof(MAX17205_RX_BUFF));        

          if(MAX17205_read_result != HAL_OK){          Error_Handler();}        /* Wait for the end of the transfer */while (HAL_I2C_GetState(&I2cHandle) != HAL_I2C_STATE_READY){}

In both cases I receive a HAL_OK condition but I can see that the TX/RX buffers (single byte arrays) do not contain the same data after:

MAX17205_TX_BUFF contains 0x01

MAX17205_RX_BUFF contains 0xB9

Would you agree that there is something wrong with the communication here? What action would you recommend taking?

Cheers,

Tony

[Tony Blake]

Posted on May 01, 2018 at 16:20

 ,

 ,

I have set the CONFIG2 register like so:

♯ define MAX17205_CONFIG2_REG , ,  , , ,  , , ,  , 0xBB

[waclawek.jan]

Posted on May 01, 2018 at 19:50

It's hard to tell from the scope what exactly is going on.

Yes, maybe, but that's the truth, you should stick to it.

I don't Cube and I am not going to delve into the MAX chip workings, sorry. You are mostly on your own here.

JW

[Tony Blake]

Posted on May 02, 2018 at 10:21

No worries, thanks for your help. I've contacted Maxim directly so should get the issue resolved.

Tony

[AvaTar]

Posted on May 02, 2018 at 10:41

I've contacted Maxim directly so should get the issue resolved.

That's not use to be the way it works.

The problem is almost certainly in your code.

The time resolution of your scope image is not quite good.

Does the slave set the ACK ?