STM32 I2C missing/short clock pulses

[DDeba.1]

Hi, 

I'm developing a product using the STM32G030C8T6. I set the I2C using the STM32CubeMX (settings attached) and used the functions supplied by the LL library. The I2C is set as Master and I only have one Master and one Slave on the bus. I manage to transmit and receive but sometimes, one of the clock pulses have a much shorter period which is causing Arbitration or Bus errors. I attached an image showing what I described. Does anyone has an explanation of why this could happen?

Thanks

[DDeba.1]

Right now I had actually removed the 200 ohm resistors. Also, the wires are around 10cm long.

In any case, I have confirmed that the issue is the rise time. The slave which I was using is a product which was developed years ago and incorporates into it two slave devices, one of which was the one slowing the bus. I got another version of the same product without the slave which was slowing the bus, and now having a rise time of ~260ns. The issue disappeared completely. 

The problem still remains though that I need to be able to communicate also with the slave device that is causing the slow rise time. On one side, I can incorporate a bus accelerator like @Bob S mentioned. On the other side, I was hoping that I can tell me STM32 micro to tolerate slower rise times. Is the latter possible? 

As a side note, I kept increasing the SCLDEL value in the I2C_TIMINGR register and, even though it improved slightly, the issue still remained. In keeping on increasing the Data Setup Time value, I'm feeling I'm just walking blindly as I still haven't managed to relate this value to the tolerated rise time. Again, I think the accepted rise time can be modified given that the STM32MXCube accept rise time values as parameters for the I2C settings. 

Any further help would be greatly appreciated. 

Thanks

[Bob S]

The rise time accelerators work both ways.  They accelerate the rise time on both sides of the chip - the STM32 side and your slave device side.  Look at the data sheet!

[DDeba.1]

When I said"on one side, I can incorporate...." I was comparing alternative solutions, not referring to physical location of the master/slave devices (this is a commonly use phrase in my native language...). I still have asked if the MCU can be made to accept slower rise times (outside the spec of the I2C standard) so as to avoid increasing the BOM cost of the product. 

[PieterInHetBos]

Can you maybe share what slave chip you have?

[Bob S]

I am having a hard time picturing how a slave can slow the rise time.  But what you have is what you have.

Try decreasing your pull-up resistor.  Perhaps 1K instead of 2.7K

[PieterInHetBos]

If the slave has a realy big input capacitance the rise time can slow because the opendrain properties

[DDeba.1]

Thanks for your replies.

@PieterInHetBos @Bob S The slave I am communicating with is a smart battery with SMBus. I went further into its schematic and found that it has 68pF caps on both the SCL and SDA lines (for some reason, who designed this battery thought they would be beneficial ?!?!? ). So it turns out that the issue is not due to the slave chips. Nonetheless, a lot of customers already have these batteries and the product I am developing should be able to communicate with them anyways.

I have tried also using 1k resistors but the issue persists. Decreasing further the resistors will cause another issue due to the series resistors in the bus on the slave side, ie, when the slave pulls the bus low, a potential divider is created between the pull-ups and the series resistors. Thus, the smaller the pull-up value, the higher the potential level will be during logic '0'. 

So far, I only see two solutions: 1) Using a bus accelerator as @Bob S suggested, but will increase BOM cost or 2) finding a way through the timing register of the I2C for the SMT32 to accept slower rise times. 

Another possibility would be to detect the issue through firmware. The problem is that, as far as I can tell, a bus or arbitration error is not always generated when the short clock pulse happens, which is leading to wrong data packets. Thus, I would need to read the same parameter multiple times and use majority voting to choose the correct value. Though it works, I would ideally solve the issue at the source by removing the short clock pulse issue. 

[Bob S · Accepted solution]

The only 2 options I see are (1) add the rise time accel chip, or (2) change your I2C/SMBus interface to bit-bang instead of using the ST I2C hardware.  I am not sure you can get a **reliable** and repeatable solution running the STM32 I2C hardware out of its intended range of (rise time) operation.  The LTC4300 and similar chips are designed to overcome high capacitance on the bus - exactly the situation you face.  That would be the best solution IMHO, yes, with increased BOM cost.

[PieterInHetBos]

this morning i thought maybe you can try to do an even lower clockspeed. There is no minimum for I2C. 30kHz is really low but maybe you can try even lower. The bit bang solution is also good i thing without increasing cost. 

[DDeba.1]

Hi all,

Thanks for your proposed solutions. I have already tried to lower the I2C clock to 20kHz but I had the same result. So far, what I made is to burst read the same parameter 5 times and if all values I receive are the same, I accept the value as correct. I would prefer this to bit banging to decrease processing from the MCU.

In future though, I might convince the project leader to add the bus accelerator as solving the issue at the source is the optimal solution. 

Thanks again for your help.