I2C Custom Timing not available in SMBus mode (CubeMX)

[TDJ]

Why CubeMX I2C Custom Timing MCU connectivity config option is unavailable in SMBus mode? Custom Timing is an advanced option for those which really know what they are doing and I do not think it makes sense to take it away in SMBus mode.

On the opposite side, it would make a lot sense to set initial Rise Time and Fall Time to more proper values (e.g. max allowed 1000 and 300ns) to simplify setup for novice users. Current default zero values are always incorrect.

In addition, Cube MX is unable to set up timings for standard mode 10kHz. Such mode is supported - see RM0440, 41.4.10 I2C_TIMINGR register configuration examples, p.1888-1889

Tested with the latest CubeMX 6.7 and STM32G431KBTx.

[Ghofrane GSOURI]

Hello @TJast​ 

First let me thank you for posting

Actually Custom timing for I2C communication refers to the ability to specify the timing parameters for the I2C communication protocol in a microcontroller. These timing parameters define the timing of the I2C clock and data signals, and can be adjusted to optimize the performance of the I2C communication for a specific application.

The specific timing parameters that can be customized for I2C communication depend on the microcontroller being used. In the case of the STM32G431 microcontroller, the following timing parameters can be customized:

• SDA_HOLD_TIME : The minimum hold time for the SDA data signal.
• SCL_START_HOLD_TIME : The minimum hold time for the SCL clock signal after a start condition.
• SCL_STOP_HOLD_TIME : The minimum hold time for the SCL clock signal after a stop condition.
• SCL_LOW_PERIOD : The minimum low period of the SCL clock signal.
• SCL_HIGH_PERIOD : The minimum high period of the SCL clock signal.
• SDA_SETUP_TIME : The minimum setup time for the SDA data signal.
• SDA_HOLD_TIME : The minimum hold time for the SDA data signal.

To set custom timing for I2C communication on an STM32G431 microcontroller, you can use the

I2C_TimingTypeDef structure to define the timing parameters and pass them to the HAL_I2C_Init() function when initializing the I2C peripheral.

In the other hand The SMBus (System Management Bus) mode is a variant of the I2C protocol that includes additional features such as support for alert responses and block transactions. When the I2C peripheral is configured to operate in SMBus mode, it uses fixed timing parameters that are specified in the SMBus specification. As a result, the option to set custom timing for the I2C communication may not be available when the SMBus mode is selected.

In general, the use of custom timing for I2C communication is more commonly associated with the standard I2C mode, rather than the SMBus mode. This is because the standard I2C mode allows for more flexibility in terms of the timing parameters that can be customized, and the custom timing can be used to optimize the performance of the I2C communication for a specific application

Thx

Ghofrane

[Ghofrane GSOURI]

Concerning the Fall and rise time :

In standard mode I2C communication, the maximum clock frequency is typically set to 400 kHz. However, if you want to operate the I2C communication at a lower frequency, such as 10 kHz, you can use custom timing parameters to adjust the rise and fall times of the SCL and SDA signals accordingly.

The rise and fall times of the I2C signals are typically specified in terms of the minimum and maximum values allowed by the I2C specification. These values are determined by the capacitive load on the I2C bus and the voltage level of the signals. For example, for standard mode I2C communication with a 3.3 V voltage level and a capacitive load of 400 pF, the minimum and maximum rise and fall times of the SCL and SDA signals are given by the following values:

• Minimum rise time: 300 ns
• Maximum rise time: 1000 ns
• Minimum fall time: 300 ns
• Maximum fall time: 300 ns

To determine the appropriate rise and fall times for your specific application, you can use these values as a starting point and adjust them based on your specific requirements and the performance of the I2C communication.

[TDJ]

@Ghofrane GSOURI​ Thank you for your response.

I am well aware of SMBus standard being more strict than I2C although: 1) the same timings can be achieved in more than one way, e.g. depending on PRESC registry value. 2) Custom Timings are for those who really know what they are doing and, I believe, there is no need for CubeMX to protect such engineers from making mistakes. 3) I believe that CubeMX does not always calculate correct settings, which I explained in a different post some time ago, that includes SMBus mode. For that reason, I always prefer calculating timings and registry settings myself, including SMBus. That is the reality.

I appreciate your time, but I think it would be better to focus on the issue in hand, that is, CubeMX preventing the settings I want, rather than restating irrelevant I2C basics.

Regarding the default rise/fall times; again, I am afraid that you missed my point entirely. My intention was to suggest CubeMX improvement, not to ask for I2C specs.

[Ghofrane GSOURI]

Hello @TJast​ 

Thank you for your contributions and for your detailed explanations,

Your suggestion is taken into consideration , it has been reported to STM32CubeMX development team

Internal ticket number: 143136 (This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates.

Thx

Ghofrane

[TDJ]

Hello @Ghofrane GSOURI​, there is another issue with CubeMX SMBus support. Setting "Coefficient of Digital Filter" to a non-zero value adjusts timings, but it does not seem to actually enable the digital filter. Digital filter is enabled by calling HAL_SMBUS_ConfigDigitalFilter() and call to this function is missing from generated MX_I2C1_SMBUS_Init() function. I think this is a bug - probably never reported since no one relies on HAL to use SMBus anyway.

[Ghofrane GSOURI]

Hello @TJast​ 

Actually I appreciate your great contributions , I confirm the issue on my side.

Internal ticket number: 143640 (This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates.

Thx

Ghofrane

[TDJ]

@Ghofrane GSOURI​ I have hot checked, but likely the problem applies not only to SMBus, but to I2C as well.

[Ghofrane GSOURI]

Hello @TJast​ 

It has been reported to STM32CubeMX development team and that will be fixed as soon as possible.

Both mode ->[I2C]: Select SMBUS mode  and ->[I2C]: Select I2C mode .

Internal ticket number: 143640 (This is an internal tracking number and is not accessible or usable by customers).

Thanks again for having reported.

Ghofrane