STM32F407VG, I2C Locked up and can't release the SDA line

[Mr_RO]

Hello,

I have an STM32F407 (Master) communicating with an AHT10 device (Slave) over I2C as one to one. Till this part everything works just fine, the problem start when i add a new device (Slave) in the same bus (eg. MPU6050) after a while the I2C lines locked up (SCL High and SDA Low). As shown in the picture below.

Once I power off only the AHT10 Device the lines goes back normal, and if I put it back in the bus, after some times (the period of time it's not synchronised) the problem will appear again. As shown below.

At first i thought that the problem within the AHT10 Device and As I mentioned before in one to one connectivity he works just fine. Even tho, the master his the one that he should release the line. Aside from that, I noticed that the I2C not sending the 9th clock pulse to release the I2C lines. As shown below.

So, I checked the I2C_ISR register to get the status of the I2C peripheral and I found that the ARLO Bit = 1 (Arbitration Lost Bit), so I tried to reset the I2C through the SWRST Bit (Software Reset) in the I2C_CR1 register. After, the I2C is initialized and the register statue returned to the ideal state, but the problem remain the same.

PS: As I noticed in the previous problems within the community, this is a frequent problem.

Waiting for support, Thanks in advance,

Regards,

[waclawek.jan]

> At first i thought that the problem within the AHT10 Device

Yes, it is - it "understands" some of the commands to the other device as commands directed to it, and responds to it. Are the I2C addresses of both devices different?

ARLO=1 means "some other device pulled SDA low while I, the master, have set it to 1".

I don't understand the remark about the 9th pulse.

JW

[Mr_RO]

Hi @waclawek.jan 

Thanks for the reply,

> it "understands" some of the commands to the other device as commands directed to it, and responds to it.

- Yes, that's what I am doubt of but both of the two devices are Slaves and each one have specific address the AHT10 with 0x38 Add and the other have 0x68 Add.

> I don't understand the remark about the 9th pulse.

- The 9th pulse suppose to release the bus ( and correct me if am wrong ).

Regards,

[waclawek.jan]

You can check, which device pulls down SDA, by inserting small (roughly 1/10-1/5 value of the pullup) resistors in series (two different values for the two slaves) - this arrangement should result in different voltages on SDA (but still below the logic-0 threshold), as the series resistors form a voltage divider together with the pullup; and measuring that voltage in the case of error would reveal, which device pulls down SDA.

> The 9th pulse suppose to release the bus ( and correct me if am wrong ).

Yes, but only when the offending device is in sync. It may quite well not be, given this is an unexpected behaviour anyway.

JW

[TDK]

ARLO getting set is indicative of a badly behaving slave device. The STM32 releases SDA and SCL in such an instance. Probably this is happening on the 8th bit, so the STM32 releases the lines and doesn't try the ACK bit.

Perhaps the AHT10 is pulling down SDA too early.

An analog capture might be more informative here.

[waclawek.jan]

> Perhaps the AHT10 is pulling down SDA too early.

AHT10 should not have pulled down at all, as the other device was addressed.

JW

[TDK]

Maybe. There are writes to both 0x38 and 0x68 in that chain of actions. Don't think the address of the device is shown for the zoomed in screenshot that you annotated, only the last 3-4 bytes. The 0x38 shown there is data, not an address.

The idle case (SDA+SCL both high) isn't shown anywhere at all. Start condition not shown anywhere. The device is probably out of sync from the outset.

Perhaps missing pullups, or initialization is done in a sloppy manner.

[Mr_RO]

Hi Again 

Thank you gentlemen's

> You can check, which device pulls down SDA

- I already know that the AHT10 his the one how pulling the SDL low, because when i take him out, the bus back to work again. But in other case, when when i take the MPU60 out, the bus remain locked and the SDA low till i take the AHT10 out.

> Maybe. There are writes to both 0x38 and 0x68 in that chain of actions. 

- Yes there are, and they are separated with some of time (2s, 3s, 4s) in the software.

> The idle case (SDA+SCL both high) isn't shown anywhere at all

- Yes there is, the idle status it's more clear at the beginning in the first picture.

> Perhaps missing pullups, or initialization is done in a sloppy manner.

- Am already using pull-up resistors and calculated as shown below plus my I2C config

Regards,

[waclawek.jan]

@TDK, fair points.

> The 0x38 shown there is data, not an address.

Indeed. But... what if AHT10 considers it as an address? It's a chinese product, after all, and I've seen I2C devices deviant in various ways even from reputable manufacturers during the years.

@Mr_RO, show us a zoomed section of the end of communication, so that at the beginning of that zoomed section both SDA and SCL are high, then we see START, and then all the rest of communication ending with the invalid SDA being low state. It may take more than one screenful, but that does not matter.

JW

[waclawek.jan]

I tried to find datasheet for AHT10, and was able to find only this Chinese version, although that appears to come directly from the manufacturer.

In that under Fig.11 at page 6 left bottom, footnote 3 says, if I copied it correctly:

3. I2C总线上仅能连接单个AHT10, 且不能连接其它 I2C 器件。

Google translated it as:

3. Only a single AHT10 can be connected to the I2C bus, and other I2C devices cannot be connected.

The first part is understandable - AHT10 has only one I2C address - but the second part is maybe significant for this thread. I don't speak Chinese so can't tell if this is a good translation.

JW