I2C Custom Timing

[MEde.1]

Hi,

Can anyone point me in the direction of some more information about the custom timing under the I2C parameter settings?

Are we modifying a specific register? or something else? Do each of the 8 bits do something different?

[AScha.3]

Hi,

just read in rm , I2C -> registers : (here the magic timing value is written :) )

You cannot generate a "new" I2C bus timing , its just about : how long are hi and lo periods (relative, at its fixed clock , 100 - 400kHz ) and when the level decision on receiving is made.

Usually you can leave this, as Cube sets it, when you change the clk speed 100 <-> 400kHz .

[Pavel A.]

This question was IIRC already raised quite long ago. Once ST has an Excel file to calculate custom value of I2C_TIMINGR, but later this functionality moved into CubeMX. Requests to publish the formula were rejected.  Even in that Excel file the script was read-protected. So the formula of I2C_TIMINGR remains guarded secret, like the cola recipe.

[MEde.1]

HI AScha.3,

I have read the RM and it's less than helpful, it talks about CubeMX being able to set the "magic" number but doesn't give any hint on what that should be. Unfortunately, none of the "standard" settings are able to coax an ack from our ADG715 analogue switches over I2C. The project is substituting a PIC18F with the STM32 in an existing product that is on the market, it's been a nice learning project as everything else is defined and works so it has "just" been figuring out how to make the STM32 either mimic the PIC18F or rewrite the functions to make use of the STM32 abilities. It appears that in our application our ADG715's require some decidedly non-standard timings (being able to compare the traces with the working PIC18F showed the STM32's pulses to be very "pointy", relatively long ramp times and short plateaus vs. the very square and slower PIC18F. I would have long since given up if it wasn't working with the PIC18F!

I finally managed to get an ack last night after trying some random numbers in the custom timing which resulted in a much squarer waveform, so getting it to work is possible I just need a method for relating the registers to the "magic" number that can be set in the IOC / CubeMX

[MEde.1]

Hi Pavel A,

I don't suppose you know what this Excel spreadsheet might have been called? 

I have looked in CubeMX and it doesn't seem to offer any functionality above STM32CubeIDE? Or maybe I am not recognising what I should be looking for / not looking in the right place? 

For those who find this thread in the future this thread is relevant:

https://community.st.com/t5/stm32-mcus-wireless/how-to-calculate-the-i2c-timing-register-value/td-p/136359

[AScha.3]

Hi,

 the "magic" number is just the I2C timing register - as i showed in previous post.

And i cannot believe, its so big problem to use the ADG715 with I2C here.

Just : what are your pullups on i2c lines ?

For hi-speed i recommend : try 2k7  and 400kHz setting, i show you how i set it:

Try this setting with your chips, 2k7 pullups ; i have 38MHz as clock for i2c , fyi.

[Pavel A.]

@MEde.1 Of course I do remember it. It was designed before the L4 series by may still work.

  https://www.st.com/resource/en/application_note/dm00074956-i2c-timing-configuration-tool-for-stm32f3xxxx-and-stm32f0xxxx-microcontrollers-stmicroelectronics.pdf

Someone published this: https://github.com/nemuisan/STM32_I2C_Timing_Keisan

Possibly ported from some STM32U5 example

https://github.com/nemuisan/STM32_I2C_Timing_Keisan/blob/master/I2CKeisan/i2c_timing_utility.cpp

If that code actually works, it can be ported to Python or Jypiter notebook on Github, or maybe Google sheet.

[MEde.1]

Couldn't get the STM32 to interact with the ADG715's at all via HAL. So I simplified things, I wired up a single ADG715 and used the STM32L476RG with clean code and still no ack. I then went to a direct bit bashing approach and it works on the simplified setup, it's not the most elegant solution but at least it's progress. It seems like the the ADG715 should be compliant with the I2C standard so have no idea why HAL is struggling so much. 

It's not working in the production generator (using the STM32H755) but the scope traces are clean and the timing of the SDA and SCL are nicely synchronised and match the STM32L476RGs output. Just no ack. I suspect that is our hardware setup, we are switching from a PIC18F to the STM32 so have level shifters aplenty and it's possible I killed the generators ADG's earlier in testing

[Pavel A.]

>  Just no ack

The slave does not ACK where required? This is enough for the HAL library API to fail. And not compatible with decent I2C.

[AScha.3]

Can you show the hardware/circuit you use ?

Esp. the ADG715 pins and circuit .