I2C1 problem in STM32F401 with LSM6DSLTR

[shydv15]

Hi,

I have custom developed board that uses STM32F401RCT6TR as MCU. I have LSM6DSLTR IMU sensor on the board and MCU is communicating with IMU using I2C1 channel (PB6 and PB7). I also have 2.4" screen (ILI9341) that displays IMU values and external EEPROM (on I2C2 channel) to store data. 

I am facing problem in I2C1 (PB6 and PB7) channel. Sometimes the sensors returns correct values, but most of the times it returns weird data. I think that my library is correct because I used same library in  my another board (that uses STM32F030) and it was working as expected. I have pull up resistors attached to the I2C lines. I also changed the MCU and IMU with new ones, but nothing changed and IMU not worked as expected.  I think it is sth related to my code. Could you please help me to solve this issue? I have attached LSM6DSLTR library and main code to this post.

Thank you

[shydv15]

I noticed following thing. When I power on the device, and measure I2C1 clock freq. using oscilloscope, it shows 100kHz clock freq as expected, but If I reset the device for few times, then there is no clock freq. (osciloscope shows noise). 

[Pavel A.]

@shydv15 Do the "weird" data values look valid at all for the device (n the range of possible values etc.)? Generally you should do the usual filtering and discard random glitches. But if you get something that does not look like random glitches, it can be a problem in communication with  the sensor or wrong configuration of the sensor.

Here you can find somebody who can review your library and help with your STM32 project.

[Tesla DeLorean · Accepted solution]

Was just going to say double check clocking, as the setting are a lot more complex/different between STM32 families. Watch APB bus speeds.

Watch static state of pins at initialization, several STM will fault into a BUSY state.

Watch that slaves rarely have an async-reset, and depending on if they were left hanging 9-clock methods of disengaging them from the bus should be considered in retry/recovery methods.

Try to identify failings early on via WHOAMI register checks/confirmations. Sanity check IMU's have been started, and are running.

The pull-up topology and values can also impact the bus behaviour.

Watch also that a lot of the GY-xx boards have 5V supply expectations, and then level-shifters between the slave's 3.3V domain, and the artificial bus 5V domain. This is mostly a consequence of targeting 5V Arduino Maker's

[shydv15]

Hi Tesla, 

I measured SDA pin and saw that whenever the problem occurs, the SDA pin is low. I applied clock cycling method to release the bus and it worked. Now, I can properly initialize the sensor. Thank you very much for your help.