SPI help

[Postal2]

.... or by choosing a lossy inductor (lossy core material). Ferrite beads ....

You are right, I have a lot of different ferrite, sometimes ferrite works wonders. But in this described effect ferrite is absent:

... If I replace the 50mm FFC cable with a 120mm FFC cable, the screen becomes more reliable (as in there's less corruption). .....

[dietert1]

Here i have some scope dumps of an I2C bus with about 40 cm of 1.27 mm flat cable between STM32 MCU and BME680 sensor, with 4K7 pullups. Within the flat cable both SCL and SDA have Gnd or Vcc wires on each side.
I used a Lecroy 500 MHz scope at full bandwidth. The dumps show how ringing depends on STM32 pin speed configuration. The low speed configuration looks almost clean, except some crosstalk to the other signal in OD state. As ringing remains less than 0.8 V with all three configurations, all three work completely reliable. In this case pin speed configuration is about avoiding EMI.

Regards, Dieter

[Wolfram]

For probing fast digital signals, 500 ohm 10:1 passive probes are also a cheap way to reduce the impact of ground lead inductance. A 450 ohm series resistor at the probing point, into a 50 ohm coax terminated into 50 ohms (either using a scope with a 50 ohm termination option, or an inline 50 ohm BNC terminator). As long as the signal source is not significantly affected by 500 ohm resistive loading, this method gives very high bandwidth and much flatter response than usual high impedance probing. It's also possible to use trade off the signal level for loading by making the series resistor larger, 950 ohms for 20:1 or 4950 ohms for 100:1.

[Postal2]

.... A 450 ohm series resistor at the probing point, ....

Yes, that's right.

....The dumps show how ringing ....

I2C just doesn't reach the speeds where ringing becomes a problem.

[dietert1]

Maybe you missed it, but above it has already been explained that ringing does not depend on clock frequency but on rise and fall times.
Let me repeat: In my measurements ringing is no problem as it's amplitude is always less than 0.8 V, even when the MCU produces the fastest signal edges it can. And the larger spikes decay rapidly, lets say within 10 nsec. So the hardware works the same at much higher clock rates, e.g. 50 MHz. Next time i have some cable SPI on my desk, i will show similar measurements for SPI.

Regards, Dieter

[Postal2]

Maybe you missed it, but above it has already been explained that ringing does not depend on clock frequency but on rise and fall times. ....

Okay, okay, you scared me, from now on I will use the most sophisticated means of suppressing ringing on the I2C bus.

[Siwastaja]

I2C just doesn't reach the speeds where ringing becomes a problem.

STM32 IO pins use the exact same switching MOSFET structures in I2C and SPI modes, so there is no difference in amount of ringing when going low (driving '0'). Of course, with I2C, there will be no ringing when going up because that is super slow through the pull-up resistor.

[dietert1]

Yes, with my measurements i did not check the ringing from fast positive edges as I2C doesn't have them.
Anyway, there is the argument of linearity, so ringing from rising edges will look similar to ringing from falling edges, except with a positive spike. Traditionally rising edges were "weaker" even in totem-pole outputs, but that remains to be demonstrated by measurement.
I think ringing depends on the cable configuration. A ribbon cable with enough ground wires inside has a very regular geometry that is known to work well at rather high clock rates. Remember those ribbon cables for computer hard disks that were used at clock rates up to 66 MHz. They had a similar length and as far as i remember every third wire was a ground.

Regards, Dieter

[Postal2]

STM32 IO pins use the exact same switching MOSFET structures in I2C and SPI modes, ....

What can you suggest to eliminate this terrible interference on the I2C bus?

[ricko_uk]

Some suggestions...:

1) Have you checked there aren't any ground loops which might be redirected or attenuated when you connect the oscilloscope?

2) Have you checked if there are nearby sources of very strong EMI (on the board or somewhere else)?

3) The oscilloscope gives you a better picture than a logic analyser but if you get a non-corrupted packet you might not see the issue. Have you tried using a digital anaylser to have a better picture of all bits/bytes that might be "seen" (i.e. read) by a digital device like your micro? you might see some patterns perhaps.