I2C Master - strange behaviour (Busy, HAL error)

[KR51K]

Hello,

I have a problem with the I2C communication on my STM32F405. The F4 is running in master mode and has 3 identical sensor connected to I2C1, I2C2 and I2C3. I want to read from the sensors "parallel" 3 bytes with the HAL_I2C_Master_Receive_IT function and a frequency of 1kHz (bus frequency is 400kHz).

My problem is, that this communication seems to be extremely unreliable. So communication is sometimes running for several minutes, but sometimes the communication stucks directly after the first reading. What I see on the scope is that SCL is going low and remains low and I return from the Master_Receive_IT function with a HAL Busy. Strange thing is, that this often happens to all I2C channels simulatneously. And currently I see no way how to recover from this state. I tried e.g. a __HAL_RCC_I2C2_FORCE_RESET(); followed by a __HAL_RCC_I2C2_RELEASE_RESET(); that releases the SCL line, but I get in the same error direct when trying to read the sensor again. So my questions are:

1. why does this happen? I reading 3 I2C in parallel to much? Do I get a problem with the interupts?
2. how I can get out of the busy problem? Is there any elegant way out?

Thanks and best regards!

[TDK]

> I want to read from the sensors "parallel" 3 bytes

What do you mean by this? In I2C, only one slave at a time can respond.

Do all slaves have a unique address?

> how I can get out of the busy problem? Is there any elegant way out?

You can try toggling the SCL (so disable I2C peripheral, initialize pin as GPIO) pin 9 times at 100kHz or less to get slaves out of their bad state. But the focus should be on figuring out why they're getting into a bad state in the first place.

[KR51K]

Hello,

I use one sensor three times (pressure sensor, that didn't make any problems in other projects so far) that all have the same address. That's why I connected them to three different I2C busses (I2C1-I2C3). There are no other slaves on the bus. I start the reading in a 1kHz loop, with the HAL_I2C_Master_Receive_IT function, so I don't wait to start the reading of sensor 2 before sensor 1 finished it's reading.

This clocking sounds interesting, I'll have a look how to implement this most suitable. But you are very right: I would like to understand what happens that the sensor gets into this situation.

[TDK]

Oh, I missed that they were connected to different peripherals. In which case there shouldn't be any address conflicts.

Not sure how much overhead each routine is adding, but it's possible all 3 reads don't complete in time for the next read to start. Maybe reduce the sample rate to 500 Hz and see if the issue persists. It is odd that all three error out simultaneously. Certainly an answer there worth finding.

Consider investing in a logic analyzer.

[KR51K]

Hello,

with 400kHz I see that the communication is finished within 85us, so this should be no problem.