I2C Timing configuration tool for STM32H7 ?

[Pavel A.]

Is the I2C configuration tool STSW-STM32126 applicable to STM32H7?

Or, is there a version for H7?

[Pavel A.]

So this is the picture from a scope:

400 KHz is 1/width of the SCK low state = 1/2.5us.

The frequency of SCK pulses from edge to edge is 1/3.5 us = 285 KHz.

Is this how it should be, or it should be 2.5 us from edge to edge?

[waclawek.jan]

> So this is the picture from a scope:

Isn't this a LA rather than an oscilloscope? Post a picture from oscilloscope, that would be very interesting to see.

What is the value of the pullups? How many slaves are there on the bus, how long is the bus? (Read, what are the R and C to the rise time?)

3.5us is a bit excessive, as I wrote above, I'd expect something more around 3us. However, if you'd used only the internal nominally 40kOhm pullup, with a couple of tens of pF it may produce quite well a few hundreds of ns rise time.

Have you verified that the clock used as I2C clock is indeed 100MHz? Are there any other slow clocks (less than 100MHz) in the same design?

JW

[Georgy Moshkin]

Check "47.4.9 I2C master mode" from reference manual RM0433:

"... The I2C detects its own SCL low level ... The I2C detects its own SCL high level ..."

and "Table 384. Examples of timing settings for fI2CCLK = 8 MHz" at "47.4.10 I2C_TIMINGR register configuration examples".

Those are 10, 100, 400 and 500 kHz examples, I tried those register values and did backward and forward calculations, and tested it in hardware, there will be no exact timings. Before you try anything else try those examples, do not forget to set I2C peripheral clock to 8 MHz, and see if frequency differences are acceptable. I ran into this problem this summer, when replaced I2S dac with cheaper I2C. Unlike I2S, I2C timings are not guaranteed, and it is more focused on data transfer reliability on a bus with multiple slaves.

Still, there are some options to make clock more precise:

1) try to tune registers and pull-up resistor value. Possible problem is temperature stability affecting rising time, and SCL high/low detection analog thresholds inside MCU. Another possible problem is in a long run MCU from different batch, or SMT pull-up resistor with different tolerances will introduce additional time shift.

2) my current preferred option is I2C emulation through DMA to GPIO transfer in circular mode of clock and data to emulate waveform output similar to old design with I2S DAC. Note that it requires to sacrifice some memory, because only two bits in each sample is used. Or use bit shifting on half/complete interrupts to introduce pair of clock/data bits into the right place for defined GPIO outputs, but it will take some time inside interrupt.

3) use higher clock, for example 401kHz, and stretch it down to 400kHz using "parasitic" slave. It is probably may be implemented with some MCU internal timers with inputs/outputs, but complicates things.

[Pavel A.]

My bad. of course that was a logic.

Here is scope with parameters below

 

 

And picture from another logic

[Pavel A.]

So @Jan, @Georgy Moshkin​ do you say basically that I2C master, in contrast with SPI or UART, does not blindly clock out pulses at the specified rate; it does some evaluation of clock line state and can insert delays?

[Georgy Moshkin]

Yes, from my understanding I2C SCL high/low level state detection mechanism affects SCL actual frequency even if clock stretching is disabled. It may be not the case for older STM32 MCUs with simpler I2C peripheral.

[waclawek.jan · Accepted solution]

OK so that rising ramp explains that all. The pullups are grossly inadequate, decrease them by at least one order of magnitude. And please don't tell me you are using only the internal pullups.

> do you say basically that I2C master, in contrast with SPI or UART, does not blindly clock out pulses at the specified rate; it does some evaluation of clock line state and can insert delays?

Not me is saying that.

JW