I2C always falls into HAL_I2C_ERROR_AF

[Thiago Cavalcanti]

Posted on December 20, 2017 at 13:04

Hi, everyone.

I2C peripheral has been initialized with STM32CubeMX according to the picture bellow:

I am using I2C1, pins B9 (data) and B8 (clock) in STM32F4 - Discovery. The device�s address is 0x60 (Says the datasheet). I am using pull-up (8 KOhm) and conflict protection resistors

(1.2 KOhm)

.I can neither read nor write to the slave device. I�ve tried the two following ways:

1)

uint8_t outputData = 0;

HAL_I2C_Mem_Read(&hi2c1, 0x60, 0x0A, I2C_MEMADD_SIZE_8BIT, &outputData, 1, HAL_MAX_DELAY);

2)

uint8_t outputData = 0;

HAL_StatusTypeDef returnValue = 0;returnValue = HAL_I2C_Master_Transmit(&hi2c1, 0x60, (uint8_t*)0x0A, 1, HAL_MAX_DELAY);if(returnValue != HAL_OK) return returnValue;returnValue = HAL_I2C_Master_Receive(&hi2c1, 0x60, &outputData, 1, HAL_MAX_DELAY);

These functions always falls into the following �if� block:

/* Send Slave Address and Memory Address */

if(I2C_RequestMemoryRead(hi2c, DevAddress, MemAddress, MemAddSize, Timeout, tickstart) != HAL_OK){if(hi2c->ErrorCode == HAL_I2C_ERROR_AF){/* Process Unlocked */__HAL_UNLOCK(hi2c);return HAL_ERROR;}

The next picture shows the activity in the I2C bus:

#i2c-addressing

[AvaTar]

Posted on December 20, 2017 at 14:21

Never tried HAL/Cube functions for I2C.

The device‘s address is 0x60 (Says the datasheet).

Does this 'include' the left-shift ?

The LSB of the I2C address is made up of the R/W bit, thus it's called a '7-bit address'.

[waclawek.jan]

Posted on December 20, 2017 at 15:21

What's your device?

Try to 'talk' to some 'known good' device, e.g. a 24Cxx EEPROM, first.

PB9 is connected on the DISCOF4 to CS43L22 SDA , although theoretically that should make no harm as long as you keep PB6 at a steady level. There's also already a 4k7 pullup on it, which you should take into account, especially since you have a relatively high serial resistor (I'd consider decreasing it). You may want to use oscilloscope to monitor the I2C lines.

JW

[Thiago Cavalcanti]

Posted on December 20, 2017 at 14:33

Yes. I've already tried to input the address shifted to the left, as in (0x60 << 1), but the result was the same.

[AvaTar]

Posted on December 20, 2017 at 15:02

If I remember correctly, you need to shift an 8-bit address right (>>1) before writing to the config register, your address makes up bit 7 to 1.

[Thiago Cavalcanti]

Posted on December 20, 2017 at 15:22

I Just checked it. No success. Same outcome.

[AvaTar]

Posted on December 20, 2017 at 15:36

Using a scope, do you see the proper address on the bus ?

[Thiago Cavalcanti]

Posted on December 20, 2017 at 15:38

I am using an OV9655 camera module. I'll give a try with an EEPROM and I'll also consider changing to other pins. Thanks. 

[Thiago Cavalcanti]

Posted on December 20, 2017 at 16:08

According to the image I attached, the address seems to be transmitted correctly: [start condition - 0110000 (address) - 0 (read operation) - 1 (Not Acknowledge) - stop condition]. But at the last clock pulse, data is high, what stands for a Not Acknowledge.

[Tesla DeLorean · Accepted solution]

Posted on December 20, 2017 at 16:30

The lack of an ACK indicates nothing on the bus recognizes the address. Triple check the wiring and power for the slave peripheral you expect to respond. Check the address selection bits on devices that support that. Make sure the pins are in OD mode.