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?

[Imen.D]

Hello @Pavel A.​ ,

It's a standard tool and integrated now into CubeMX.

So, it's the same used for STM32H7.

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

[Pavel A.]

Thank you Imen.

I'm asking because the value calculated by Cube results for me in wrong actual clock on the wires.

The board is Nucleo H753, on HSE 8 MHz from st-link.

I2C1 clock should be 400 KHz but the customer sees on the wire something about 300 KHz or less.

The device on I2C is flexible and looks working at this clock rate, but the customer has a precision bug and demands 400 KHz.

Any advice what else to check?

 

 

[Georgy Moshkin]

Check this thread: How to achieve exact SCL clock timings for I2C master in transmit mode?

I think that most reliable option to obtain exact timings would be emulating external I2C master with 400kHz PWM output, or emulate additional slave on the line and use it to stretch slightly higher clock down to 400kHz.

[waclawek.jan]

> the customer has a precision bug and demands 400 KHz.

I2C SCL is not precise and was never meant to be such. Its exact timing depends on the rise time determined by the pullup and parasitic capacitance. AFAIK the I2C module in STM32 correctly ensures minimum timing, i.e. it waits until the feedback input from SCL indicates that its level has risen above threshold, and only after that starts the high-level timer. You can "reverse-correct" for this by tweaking SCLH/SCLDEL, but I personally would work with the customer to explain why his expectation is flawed.

JW

[Imen.D]

 Hi @Pavel A.​ ,

You have to calculate with the formula provided in the reference manual.

There are uncertainties in the I2C frequency due to the fact the analog filter delay is unknown and also the total of tSYNC delays, but you should reach more than 300 kHz.

The analog filter delay can be found more or less in the device datasheet (you can use the max filtered pulse as delay). I do not know the analog filter value used in CubeMX. If you want a more precise frequency you can use digital filter instead of analog filter.

Note also that the rise and fall time must corresponds to the one measured on the board, I do not think customer have 200 ns as falling edge.

After getting TIMING register value with the tool, they should adjust it by reducing SCCL or SCLH counter if needed.

Here PRESC=1 so, the counters resolution is 250 ns with 8 MHz PCLK.

Hope this helps!

Imen

[Pavel A.]

Our engineer believes that the I2C timing calculation does not work when the source clock to I2C is too high (in my case 100 MHz).

He changed the I2C clock source mux to HSI/4 (16 MHz) then Cube generated value results in 400 KHz SCL.

I tried to select other sources of I2C clock in Cube but failed. More on in new thread.

[waclawek.jan]

> Our engineer believes that the I2C timing calculation does not work when the source clock to I2C is too high (in my case 100 MHz).

Give values.

JW

[Pavel A.]

This is what cube gives for 100 MHz source clock from PCLK1: 0x009034B6

 

 This is for 16 MHz source from PLL3:

[waclawek.jan]

0x06+1+0x1A+1=34

34/16MHz = 2.125us

If this setting yields you cca 400kHz clock, the delays discussed above are cca 375ns.

Assuming they are roughly the same for the 100MHz setting (they should be slightly less, as one of the constituents is the resync which is synchronous, see master timing description in RM),

0x34+1+0xD6+1=268

268/100MHz = 2.68us

1/(2.68us + 0.375us)=327kHz

QED

JW

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

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

[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

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

[waclawek.jan]

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