CubeMX I2C stupid UX issue

[TDJ]

Every time I need to configure I2C, which is not often, I have to check the correct rise and fall times for the default 100kHz frequency and doing so I am asking myself a question why the typical 100kHz value is provided by default but rise and fall times are not, when most of the time 1000 and 300ns values are needed and I2C will NOT work with default values 0. Would not it increase user experience if the correct, typical values were provided in addition to the typical clock frequency?

Btw, CubeMX calculated timings are slightly off the I2C specs and conditions defined in ST RM docs. I believe the CubeMX algorithm is incorrect. Therefore I suggest to always enable the 'advanced settings' and allow the user to enter timings manually. Explaining why the calculation algorithm is incorrect is beyond the scope of this post.

[AScha.3]

btw  did you ever check the real rise/fall times ?  

+  from rm:

 

[TDJ]

@AScha.3 I usually check the actual rise/fall time, but why does it matter? You seem to be missing my point.

In a standard 100kHz mode max rise time for both SDA and SCL signals is 1000ns and max fall time is 300ns. Consequently, default CubeMX settings should accommodate for the maximum allowable rise/fall times. Of course, when the actual measurements are obtained fine tunning could be made, but why not to set those rise/fall times (and consequently SCLDEL/SDADEL) to safe values by default? If the actual times are shorter then max allowed, nothing bad would happen.
Current default rise/fall time values 0 (zero) are always incorrect.

Please e.g. refer to RM0456, Table 655. This table mentions SMBus, but timings apply to non-SMBus as well. See NXP document UM10204, table 10, p.48. and other I2C standard specs.
For the detailed discussion refer to RM0456 p. 2683-2685.

[Pavel A.]

> Current default rise/fall time values 0 (zero) are always incorrect.

@TDJ Are you considering that this behavior of Cube works "well enough" for a lot of users, for long time?

 

[TDJ]

@Pavel A.  And how do you actually know that?

[Pavel A.]

@TDJ I know more than several companies and individuals who use CubeMX/IDE for several years already; none of them has major issues with I2C configuration. Questions arise from time to time, and get answered.

[TDJ]

@Pavel A.  Recently I discovered that setting I2C digital filter in CubeMX had no meaning, it did not generate the required HAL function call. The problem was not limited just to a particular MCU. Nobody noticed this for years and it is fixed now. Does it suggest that previously I worked well enough? I guess, it depends on how you define "well enough" or rather whether or not CubeMX team strives for excellence or just barely "good enough".

[Pavel A.]

Yes the digital filter is a known issue. Can't tell much on this except that every time I've asked my board designers what to do with the digital filter, they told to ignore it. And the products worked fine AFAIK. But we never had to reduce the bitrate below 100 KHz. For several years on this forum I can't recall such requirement. Of course bugs should be fixed.... in order of priority.

[TDJ]

@Pavel A. Essentially, I suggest CubeMX improvement, improvement helping less experienced engineers to get I2C working right "out of the box" because the default zero rise/fall times prevent that.
To that you replay that you know several companies using CubeMX which are happy.

Fine, I just do not see how this is relevant.

I could tell you about companies (large ones) which, for a good reason, would not even consider using CubeMX to generate any production I2C code, but, again, this is not relevant here.

[Pavel A.]

What I tried to tell, I2C code generated by Cube without modification (zero rise/fall times) actually works "well enough" for many users counting myself. So I'm curious why it fails for you, is it related to the clock timing alone or properties of the wires (termination, noise isolation etc.)?

Bug reports against Cube can be raised in this forum, but it's better if you have a FAE contact or open a support request here.

[TDJ]

@Pavel A. OK, I think now I see your point.

Do you agree that I2C CubeMX-calculated timings, based on the default best case scenario zero rise/fall times do NOT meet I2C specification timing requirements? If you are not convinced, do the math, check the four conditions specified (e.g.) in RM0456 p. 2683-2685. However, if you are convinced it is OK as it is now, give me an example of auto generated timings based on zero rise/fall times which do meet those requirements.

What I am saying is that it is possible, and desirable, to use default settings which do meet I2C specification requirements most of the time if rise/fall times do not exceeded max allowable 1000/300ns respectively for 100kHz clock and use 1000/300ns (worst case scenario) as default values, rather than zeroes (best case scenario).

Calculations convince me, arguments like "many companies are happy for years" do not.

[Foued_KH]

Hello @TDJ , 

The rise and fall time are setting as default value not as best value, so you can change the rise and fall time respecting the range for both timing.

Could you please share which issues do you have if you set fall and rise time at 0?

Foued