I2C problem, not getting the ACK bit

[esovo1]

Posted on January 06, 2015 at 17:35

Hello,

I am trying to communicate with the Barometric sensor MS5611, using the I2C protocol. My micro is STM32f3discovery. The address of the sensor is send, but not the command. The code is stucked in the while loop waiting for TXIE bit to be set. The reason why TXIE is not ''one'', is because the acknowledge bit from the MS5611 is not showing up. Also the I2C status register is setting the NACK (not acknowledge), STOPF (stop flag) bit.

The address of the MS5611 sensor is 11101 This can be seen in the datasheet on the page In my case the value of CSB is zero.

http://www.meas-spec.com/downloads/MS5611-01BApdf

But the O-scope shows me different a picture:

http://s1photobucket.com/user/esovo/media/Newfile1_zps0461710c.jpeg.html

here is the code for reseting the sensor:

#define ADDR_W 0xEC // device address + write mode
void Alti_reset( uint8_t ComandAddr)
{
/* Test on BUSY Flag */
while(I2C_GetFlagStatus(I2C1, I2C_ISR_BUSY) != RESET);
/* Configure slave address, nbytes, reload, end mode and start or stop generation */ 
I2C_TransferHandling(I2C1, ADDR_W, 1, I2C_AutoEnd_Mode, I2C_CR2_START); // I2C_Reload_Mode
/* Wait until TXIS flag is set */ 
while(I2C_GetFlagStatus(I2C1, I2C_ISR_TXIS) == RESET); // I2C_ISR_TXE)
/* Send Register address */
I2C_SendData(I2C1, (uint8_t) ComandAddr);
/* Wait until STOPF flag is set */
while(I2C_GetFlagStatus(LSM303DLHC_I2C, I2C_ISR_STOPF) == RESET);
/* Clear STOPF flag */
I2C_ClearFlag(I2C1, I2C_ICR_STOPCF); 
}

So, What I am missing? ... TNX #i2c-stm32-ms5611

[esovo1]

Posted on January 10, 2015 at 21:28

Hei,

I am bit confused. I don't know which one is it to blaim... Is that of the microcontroller, because he was interupted or reset in the middle of its communication with the I2C slave and the micro has forgotten where it was. That's is why the bus is stuck. The info is from the datasheet AN-6 Or is it the I2C slave fault, because he wrongly detected the start condition and can not properly act on a STOP condition. However, the solution is to implemant an I2C reset. I just have to connect the power supply of the sensor with GPIO pin of the microcontroller. I have come up with a pseudo code:

i = 0;
time_out = 0;
set address and send start condition;
while(ACK received == FALSE)
{
Delay_us(time_out);
if( NACK is received == TRUE)
{
send start condition;
i++;
if(i == 4)
{
GPIO_pin low and POR for I2C slave;
Delay_us(5);
GPIO_pin high power up I2C slave,
i = 0;
send start condition;
}
}
time_out= 100us;
}

the cycle: The code is stuck unless an ACK is received from the slave. On very transition the the code is delayed for 100 microseconds. On the forth transition the I2C slave goes power on reset. Driving a pin low for 5 microseconds. Power up and sending the start condition. Is this the right way?

[stm322399]

Posted on January 11, 2015 at 16:33

Hard to say which way is the best to make your sensor to work.

If I were you, I would focus on getting the ACK from the sensor, with I2C, or in extreme case, by directly bit-banging the I2C protocol. The AM-686 helped me in the case the I2C device stucked the SDA line to zero. That was easy to detect and fixed by manually issuing afew SCL cycles until the slave release the SDA. But it is not likely to be the same issue than you are facing.

[esovo1]

Posted on January 31, 2015 at 18:45 Hei Laurent, In case you want to know. The communication is now working. The reason why didn't worked was because I didn't solder the pads X) I feel so... anyway thanks for helping me. peace out, Cheers