2018-04-30 01:52 AM
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 0x021And 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 #max172052018-04-30 04:02 AM
Correction: 12C2 bus
2018-04-30 06:19 AM
I'm right shifting the slave address before I call the I2C read function
Try not to.
JW
2018-04-30 07:38 AM
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
2018-04-30 12:03 PM
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
2018-05-01 07:17 AM
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
2018-05-01 09:20 AM
,
,
I have set the CONFIG2 register like so:
♯ define MAX17205_CONFIG2_REG , , , , , , , , , 0xBB
2018-05-01 10:50 AM
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
2018-05-02 03:21 AM
No worries, thanks for your help. I've contacted Maxim directly so should get the issue resolved.
Tony
2018-05-02 03:41 AM
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 ?