I2C rise and falltime setting

Sebastian33 · ‎2025-11-27

We have a board with a stm32u5. were VDDIO are connected to 1.8 V and the I2C bus have pullup to 3.0 V. Some I2C devices uses 3.0 V logic levels and som 1.8 V.

Between which voltage levels shall i measure the rise and falltime that i enter in cubemx.

30%->70% of 1.8 V or 3.0 V .

We have possibility to turn off and on some devices on the bus that changes the rise and falltime on the bus. Shall then the longer or shorter rise/falltimes be used?

One reason we are asking is that our design engineers wonder why the signal of the clock never is piece wise equal in on and off timing as it is the case with other I2C masters

Andrew Neil · ‎2025-11-27

@Sebastian33 wrote:
the I2C bus have pullup to 3.0 V. Some I2C devices uses 3.0 V logic levels and som 1.8 V. ?

Surely, that cannot work ?

The 1.8V devices need to be on a 1.8V bus ?

In any I2C bus, the master needs to be configured to a setting that will work for all slaves on the bus.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

TDK · ‎2025-11-27

If the master is at 1.8 V, they should be the rise/fall times for 1.8 V. These setting shouldn't matter much.

A pin in open-drain mode pulled up to 3 V externally will work just fine here on a 1.8 V bus on the STM32 side.

If you feel a post has answered your question, please click "Accept as Solution".

FNiel.1 · ‎2026-01-05

I am the design engineer that is referred to in this item.

Communication to I2C devices are working in this design, but I wonder about two things, which seems to relate:

1. Normally you will with I2C have relatively piece wise equal on/off clock timing (yellow trace in scope plot). Here the on time is 2/3 of the bit time.

2. The clock frequency is always lower than requested. Here the requested frequnecy is 400kHz, but the resulting is 384kHz. The off pulse has the correct timing for piecewise equal on/off, but the on seems to long.

The curve is without any slaves responding. It is the STM32U5 itself alone on the bus.

Is this behaviour as expected with STM32U5 when requesting 400kHz communication or is it a setting of a register that causes the prolonged on time?

Sebastian33 is mentioning that the STM is supplied with 1V8 and that pullups are to 3V3. This is in accordance with this app note:

https://www.st.com/resource/en/application_note/an4899-stm32-microcontroller-gpio-hardware-settings…

,5.3.3 I2C application. Where it explains our application, however on using 5V instead of 3V.

But could it be the trigger for this issue somehow?

MHoll.2 · ‎2026-01-05

Hi,

Yes. I had the same experience with the timings generated by STM32CubeMX, so I normaly use the possibility to set my own timing (by enabeling Custom Timing).

You can start by using the values CubeMX has calculated and modify them for your use case. The hex value in Timing is the value writen to the I2C timing register, I normaly change only the two low bytes (SCLH and SCLL).

P.s. Mixing 1.8V and 3.3V I2C is only possibile if all 1.8V devices support 3.3V on the SDA adn SCL pin's.

TDK · ‎2026-01-05

> Normally you will with I2C have relatively piece wise equal on/off clock timing (yellow trace in scope plot). Here the on time is 2/3 of the bit time.

The I2C specification has no such requirement. Perhaps you are thinking of SPI. In I2C, the requirements for high/low periods on SCL are asymmetric.

> The clock frequency is always lower than requested. Here the requested frequnecy is 400kHz, but the resulting is 384kHz. The off pulse has the correct timing for piecewise equal on/off, but the on seems to long.

Exact clock frequencies with I2C cannot be obtained because of how the chip waits for logic high when the pin is released. This takes a variable amount of time depending on the pullup resistor and capacitance on the line. There is no requirement that the clock frequency be exactly 400 kHz. You can increase the strength of the pullup, but an exact frequency will never be obtained here. Nor is it required.

The clock frequency in scope plot is 400 kHz whereas the settings selected were for 100 kHz. This should be rectified. I assume the screenshot was taken at a different time.

If you feel a post has answered your question, please click "Accept as Solution".

FNiel.1 · ‎2026-01-06

I know, that UM10204 does not require them to be the same on and off timings and that they cannot be at 70% (ViH for receiver), where the timings you are referring to is the case with the pull-up current specified. I'm refering to the timing at the bottom, sub 10%. I have seen very few I2C hosts that does like this (yellow signal).

Andrew Neil · ‎2026-01-06

@FNiel.1 wrote:
I have seen very few I2C hosts that does like this (yellow signal).

Not sure what you mean by that?

It looks like a pretty standard waveform to me:

The slow rise suggests that your pullup is a bit weak?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

TDK · ‎2026-01-06

> I'm refering to the timing at the bottom, sub 10%. I have seen very few I2C hosts that does like this (yellow signal).

Be more specific. There's nothing wrong with the posted signal, except perhaps the pullup is a bit weak.

If you feel a post has answered your question, please click "Accept as Solution".

FNiel.1 · ‎2026-01-06

Thank's @Sebastian33 See if these setting options are different from what you tried.

We only have 3V3 slave devices and a 1V8 supplied STM32U5 as host, so STM ViL and ViH is not according to UM10204, but signal certainly passes the level as specified by AN4899.