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?

 

 

[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

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