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 .

 

[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

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

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

 

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

 

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

 

[MEde.1]

The ADG715 is potentially a little fussy. My bit banging functions and careful applications of delays (having the SDA start slightly before and end slightly after the clock pulse) results in everything working fine the speed is terrible but completely non-critical in our application. By fine I mean that the ADG pulls the SDA line done for the ack.

It even works in our production generator (which is currently in a real Frankenstein state, some of it is still running at 5 volts and all of the stuff hanging off the STM32 is now 3.3v with level shifters everywhere, it's only intended as a proof of concept for the next generation generator)  

[Andrew Neil]

---

@MEde.1 wrote:

The ADG715 is potentially a little fussy. 

---

So have you contacted AD about that?

What timing difference(s) do you see between your working bit-bang code, and the non-working HAL code?

Does it work wit other microcontroller brands using their hardware I2C?

ST Application note AN2824, STM32F10xxx I2C optimized examples described controlling the I2C hardware manually - without HAL:

https://www.st.com/resource/en/application_note/an2824-stm32f10xxx-ic-optimized-examples-stmicroelectronics.pdf

 

[waclawek.jan]

Breadboard?

Post photo.

And post waveforms.

JW

[thismarkjohnson]

That Timing value maps directly to the I2C_TIMINGR register (PRESC, SCLDEL, SDADEL, SCLH, SCLL), so each group of bits controls a different part of the I2C clock timing. I had to dig into the reference manual and even used an online calculator once (similar to how I use https://lgspuanhesaplamaa.com.tr/ for quick calculations) to really understand how changing those fields affects the waveform.