I2C TRISE

[hazelnusse]

Posted on May 01, 2012 at 07:54

I would like to understand what the I2C TRISE register does.

The standard peripheral library effectively sets it to either:

I2Cx->TRISE = PCLK1 / 1000000 + 1;

or

I2Cx->TRISE = (PCLK1/1000000*300)/1000 + 1; 

For example, for a 36MHz peripheral 1 clock, PCLK1=36000000, this results in:

I2Cx->TRISE = 37;

or for fast mode:

I2Cx->TRISE = 11;

So, it seems like this can be interpreted as the number of peripheral cycles it takes for the SCL line to go rise. RM0008 mentions this as well:

The filter value can also be added to TRISE[5:0].

Does anybody know what this means exactly? I presume that this register somehow affects how many clock cycles the peripheral waits after releasing SCL to see if it has actually gone high (the slave could stretch the clock, so the master needs to verify the line has gone high after some period of time), but I really don't know. If this is the case, then it seems like you could use TRISE to cause the STM32 to wait a more or less than the I2C spec (300ns for fast, 1000ns for standard) before checking to see that the clock line has indeed gone high. If you knew your circuit had lower rise times, you could reduce TRISE to reduce some of the bus overhead; conversely, if you knew your bus had higher rise times, you could increase TRISE to make sure that SCL has time to go high. Has anybody experimented with this setting? Thanks, Luke #stm32-i2c-ccr #stm32-i2c

[dimax]

Posted on September 07, 2013 at 12:15

HI.

 I wonder about it as well. Would be nice if ST representative(s) here in forum will lit some light on that mysterious register.

Actually after a year of my experiance with STM32 I'm no longer surprised about low quality of ST documentation. I do not understand why is it so difficult for company like ST to provide comprehensive data sheet free of errors (without talking about fixing spelling and grammar errors and translating some texts to real English) . If I would have to choose 32bit ARM platform now I would definitely go to Atmel's SAM3 or NXP one at least to get a norma DataSheet that explains IC functionality.

[dimax]

Posted on September 17, 2013 at 07:33

HI,

Still nothing. Can anyone here from ST stuff explain the functionality of TRISE? Also I wander where from comes the I2C master limitation of 400Kbps? Based on the registers description I see no problem to configure I2C module to run at higher frequencies. Will it work? If not why?

[Danish1]

Posted on September 17, 2013 at 11:54

xol.xol:

The 400 kHz limitation comes from the I2C specification itself (see for example the official documentation by Philips - now NXP - who invented I2C).I2C is a very old interface - the original version came out around 1982 when 100 kHz was plenty fast enough and did not stretch the technology of the day.You must remember that I2C is an open-drain (or open-collector) interface so the waveform is asymmetrical and potentially horrible. As it is self-clocked, it is critical to know whether the rising edge on one line happened before or after the falling edge on the other line. But the falling edge is driven by a transistor, yet the rising edge only by a resistor so it is much slower.Add to this the need for each device to ignore noise on the lines, and the possibility that different ICs might be using different technologies and/or supply-voltages, so what each chip regards as logic 0 or logic 1 and it is amazing that it works at all.ST guarantee that their I2C interface will work at 400 kHz (provided all the connected peripherals will work at 400 kHz - some only work at 100 kHz - and that your resistor value is sensibly chosen and your stray capacitance is within the necessary limits).They don't say what will happen if you clock it faster than that.It might work.It might not work.It might work on your test-bench, but when you make a batch of 1 million of these units you might find that some of them don't work at your chosen 550 kHz when they are out in the snow.And if you then complain to ST they can tell you that they only guaranteed for it to work at 400 kHz so it's your problem to deal with angry customers. ST won't give you your money back.I agree that the documentation does not explain things, and it's frustrating to not understand why something should be set the way they tell you it should be set. That setting might only be important in (for example) multi-master configurations or where the slave uses clock-stretching - both of which are beyond the experience of most people who use I2C.

[dimax]

Posted on September 17, 2013 at 14:12

xol.xol:

The 400 kHz limitation comes from the I2C specification itself (see for example the official documentation by Philips - now NXP - who invented I2C).

Wrong. Go and read the latest specification. There are Fast Plus mode that works at 1MHz and High-Speed mode that works up to 3.4MHz.

I'm manufacturing SUB-20 device and work a lot with I2C spec and custom I2C devices.

http://www.xdimax.com/sub20/sub20.html

I agree that the documentation does not explain things, and it's frustrating to not understand why something should be set the way they tell you it should be set. That setting might only be important in (for example) multi-master configurations or where the slave uses clock-stretching - both of which are beyond the experience of most people who use I2C.

Right. I need to implement Fast Plus and High Speed Master as well as Slave working on up to 3.4MHz (according to I2C spec). I can't do it without understanding of IC implementation details. That's why I'm complaining. I got used to work with Atmel AVR and I never faced luck of documentation. In my more then 20 years experience this is not the first time I have to work blind and/or make reverse engineering. But I never did it with CPU as all CPU's I worked before were documented well.  

[lendre.sandrine]

Posted on September 17, 2013 at 16:05

Hi Luke

You are right : when the I2C peripheral releases the SCL line to high level, the HIGH level counter starts counting (CCR*TPCLK1 counter in standard mode). After TRISE time, the peripheral checks the SCL level on the bus. If SCL is HIGH, the peripheral keeps on counting the high level duration. If SCL is LOW, it means that a slave is stretching the bus and the low level counter stops until SCL HIGH level is detected. This specific management is due to the fact the loopback from the SCL rising edge generation by the peripheral to the SCL rising edge detection by the peripheral takes time even if no slave stretches the clock. This loopback duration is linked to SCL rising time (impacting SCL VIH input detection), plus delay due to the analog noise filter present on SCL input path, plus delay due to internal SCL input synchronization with APB clock. Without TRISE register, this loopback duration would lead to a reduced frequency compared to the expected one (calculated with CCR register), because the high level counter should count only when the SCL high level is detected due to possible slave clock stretching. Programming TRISE with the SCL maximum rising time from NXP I2C standards justensures that the frequency is not decreased whatever application rising time.If you program TRISE with a value lower than the application rising time, the only impact can be a reduced frequency. The I2C functionality is not guaranteed if your application SCL rising time is higher than the maximum from NXP I2C standards .

Best regards

Sandrine

I would like to understand what the I2C TRISE register does.

The standard peripheral library effectively sets it to either:

I2Cx->TRISE = PCLK1 / 1000000 + 1;

or

I2Cx->TRISE = (PCLK1/1000000*300)/1000 + 1; 

For example, for a 36MHz peripheral 1 clock, PCLK1=36000000, this results in:

I2Cx->TRISE = 37;

or for fast mode:

I2Cx->TRISE = 11;

So, it seems like this can be interpreted as the number of peripheral cycles it takes for the SCL line to go rise. RM0008 mentions this as well:

The filter value can also be added to TRISE[5:0].

Does anybody know what this means exactly? I presume that this register somehow affects how many clock cycles the peripheral waits after releasing SCL to see if it has actually gone high (the slave could stretch the clock, so the master needs to verify the line has gone high after some period of time), but I really don't know. If this is the case, then it seems like you could use TRISE to cause the STM32 to wait a more or less than the I2C spec (300ns for fast, 1000ns for standard) before checking to see that the clock line has indeed gone high. If you knew your circuit had lower rise times, you could reduce TRISE to reduce some of the bus overhead; conversely, if you knew your bus had higher rise times, you could increase TRISE to make sure that SCL has time to go high. Has anybody experimented with this setting? Thanks, Luke

[dimax]

Posted on September 17, 2013 at 17:02

Is it your assumption or are you related to ST?

I see no reason to hardware to wait TRISE time before starting to check if SCL is high. It can start checking SCL level immediately and once it goes high start counting SCL High period. This is what spec requires. So theoretically there is nothing bad to have TRISE always Zero hens it is useless. 

[lendre.sandrine]

Posted on September 17, 2013 at 17:27

I am from ST, working in application team in charge of I2C in MCUs.

You are correct and the new I2C peripheral present in STM32F0 and STM32F3 families is designed as you say. In older families, the I2C clock frequency is defined with CCR. If you keep TRISE at 0 there is no real issue: for instance in standard mode you would get a SCL frequency a bit less than 2 * CCR * TPCLK1 rather than precise 2 * CCR * TPCLK1, and the frequency would be impacted by the bus load variation (impacting SCL rise time). We removed this management in new families that we considered difficult to explain for a small added value. Best regards Sandrine

[dimax]

Posted on September 18, 2013 at 07:33

Thanks a lot for your commitment. Now I'm not filling alone and can go on with much more confidence. (You had to put this information into reference manual to escape this thread).

Well now I want to ask a real question. Where the 400KHz limitation comes from? Can I run I2C Master and Slave at 1MHz and 3.4MHz if my system clock theoretically allows it? I need to implement Fast Plus and HS mode in both Master and Slave. Can I do it based on HW module or should I go back to bit-banging?   

[lendre.sandrine]

Posted on September 18, 2013 at 08:55

If you refer to NXP I2C specifications, you will find that each mode must respect some timings. In the STM32F1/F2/F4/L1 I2C, these timings are hardware coded and depend on the value programmed in FREQ field. If you look at F0/F3 families they are programmed by SW.

So to come back to F1 I2C, the speed limitation is mainly linked to the maximum ''data valid time'' timing. If you increase the speed above 400kHz you may violate the timing provided by NXP for fast mode +. If the maximum data valid time is violated, you can have communication errors. So it may work or not, we do not guarantee. High-speed mode up to 3.4MHz has a specific protocol with high-speed header which is not supported. Best regards Sandrine