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

[waclawek.jan]

Failed clock stretching?

What's the hardware? What's the slave (slaves?)? How is it connected?

JW

[DDeba.1]

The hardware is custom made for the application. I only have one master and one slave and the slave is a battery with SMBus. They are connected through wires. A 2.7k pull-up resistor on the Master side and a 200R resistor in series between the Master and slave. 

I doubt its a failed clock stretching. Clock stretching is happening on the clock pulse right before the failed one, you can see the ~0.6V step before the pulse. Also, due to the series resistors and wires, when the slave stretches the clock, the bus voltage is around 0.6V. The failed clock is seen to go back to 0V which indicates that its actually the master who is prematurely pulling the clock low. Any ideas why the master could do this?

[PieterInHetBos]

 i think your rise time is to long

[DDeba.1]

Hi, 

I measured the clock rise time (attached) and it is in the range of 1us (1000ns) as set in the I2C settings. Shouldn't this be good?

[PieterInHetBos]

It is the max dictated by the standard:

https://www.ti.com/lit/an/slyt770/slyt770.pdf?ts=1687859672419&ref_url=https%253A%252F%252Fwww.google.com%252F#:~:text=The%20I2C%20protocol%20dictates%20the,ns%20and%20300%20ns%2C%20respectively.

[DDeba.1]

Hi, 

I checked the hardware and found that the slow rise time issue is coming from the slave. Unfortunately, this is something I have to accept and work with, so I need to make the STM32 to accept slower rise times than the I2C standard specifies. I tried to tune the I2C_TIMINGR value to allow a rise time higher than 1000ns. The issue is that I'm finding it difficult to relate the rise-time value to the timings description given in the datasheet. I tried to change the SCLDEL value from 3 to 5 (data setup time increased from 1375ns to 2062.5ns) but the issue remained. One thing that I noticed is that the missed pulse has a pulse duration of approx 650ns (image attached). This duration is constant no matter the value of SCLDEL that I set. 

Can anyone tell me how can I force the MCU to accept rise times higher that 1000ns?

[PieterInHetBos]

How are you sure it is not fixle in hardware?

I sadly cannot help you with te risetime in the STM32

[DDeba.1]

The only reason I am assuming the rise time is not fixed in hardware is because the STM32MXCube lets you set the signal rise time value. Unfortunately, it forces you to stay within the I2C standard so it does not let me go above 1000ns. If anyone can help with this regards, I could finally confirm if the issue is indeed coming from a slow rise time or not

[Bob S]

Can you decrease the 200 ohm series resistor?  How long are you wires?

If the issue really is slow rise time (likely exasperated by your series resistor), can you modify the hardware and add a rise time accelerator (LTC4300 or the like)?  Beware that the LTC4300s rely on bus capacitance to work properly.  You may need to use higher value pull-ups if your bus capacitance is not high enough.