STM32F103 - I2C failure to ack

js2 · ‎2017-03-07

Posted on March 08, 2017 at 00:10

Hi,

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?

JS

js2 · ‎2017-03-08

Posted on March 08, 2017 at 15:58

Hi:

Thanks for the reply. I believe I have fixed the issue. I had modified the cube code so no stop would be sent at the end of a transmit. That worked when reading the device since a transmit was followed by a read (which sends a stop at the end of the request), but would leave the i2c controller in a busy state when I was writing data only (no stop sent). I modified the transmit function so I can now specify whether or not a stop should be sent at the end of the transmission. Everything works now.

Now, when generating code from STM32CubeMx, is there a way to create exclusions so I don't lose the modifications I made to the drivers? I've found that cubeMX overwrites sections that I thought were reserved for user code (for instance, the section

/* USER CODE BEGIN 2 */

/* USER CODE END 2 */

in main.c keeps being cleared whenever I regenerate the code.

Mark Shoe · ‎2017-03-09

Posted on March 09, 2017 at 10:12

Hi I had exactly the same problem with a 103. My

BH1750FVI did not respond. When i touched the clock or data, (dont remember) with the scope the device did acknowledge. So i placed a 100pf on the line. Also the HAL spi driver has a timeout fixed at 10 seconds and thats much too long for my watchdog. You can change that but every time you import a changed CubeMX project the setting is back to 10 sec.

Cezar Chirila · ‎2018-03-29

Posted on March 29, 2018 at 21:05

Hi! Can you please show the code of the modifications that you made to the HAL library? Thank you!