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.

[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.

[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]

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]

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.