I am using an STM32F103 connected to an I2C device. I can see that the device is responding to 2 ranges of addresses, one mapped to registers, one mapped to an EEPROM address space. I can communicate with the device (writing to it and reading in memory mode) properly, but I get an ack failure when trying to read it.
I am using code straight from the cube (latest F1 version available), in poll mode. I had to modify the initialization code to go around the issue of the device being always busy (moving the initialization of the i2c clock to happen before the initialization of the i2c pins).
Regarding the read issue, I have confirmed the following with an I2C oscilloscope:
- Start is generated,
- 7 bit address is sent
- 8th is set to 1 (read request)
However the 9th clock is stuck to 1 which means the slave did not respond to the read request. In write mode the device is properly acknowledging the address on the 9th clock.
Considering the device properly responds to this address in write mode and considering the amount of issues reported with the STM32F103 i2c I am wondering if the STM32F103 is holding the 9th bit high and preventing the slave from acknowledging.
Has anybody been able to execute read requests (mast reads, not memory reads) using the cube code?