I2C 400kHz signal running at 364kHz

[edware]

Posted on February 16, 2008 at 22:28

I2C 400kHz signal running at 364kHz

[edware]

Posted on May 17, 2011 at 12:20

Correct waveform attached here...

[edware]

Posted on May 17, 2011 at 12:20

I have configured the I2C for 400kHz operation using the HSI clock source and the PLL.

Everythink looks OK, however the I2C speed is only 364kHz. I have set the I2C2 CCR register field to 0x1E which should yield a 2.5us bit period. I cannot account for the discrepancy, given the maximum HSI variation is +/-2% at 25 degrees C. Can anyone else see slower than expected I2C comms? The attachment shows SDA and SCL at an expected 2.5us bit time. [ This message was edited by: edware on 07-01-2008 04:33 ] [ This message was edited by: edware on 07-01-2008 04:36 ]

[16-32micros]

Posted on May 17, 2011 at 12:20

Hi Edware,

Can you share your hardware connection : VDD, Pull-ups on I2C bus ? You can measure and output your RC Frequency using the MCO Output pin to check its accurancy. PS: In our datasheets you can see that the value of the CCR register is not yet characterised and should be prepared for the next updates. Cheers, STOne-32 :p

[edware]

Posted on May 17, 2011 at 12:20

Hi STOne-32,

thanks for the suggestions. I have measured the PLL output frequency (/2) using the MCO output as suggested - it measures around 98MHz so is within spec. My target hardware has TWO sets of 4K7 pullups on the SDA and SCL lines. (i.e. one set on my STM32-SK board and one set on my I2C eval board). So pullup value is 2.35kOhm. I removed one set of pullups (leaving the SCL and SDA line with one 4K7 pullup each) and found no difference in the frequency.- see OnePullup.jpg I did notice something odd - at 100kHz there is no error:

• with a set frequency of 100kHz I get 0kHz - 0% error
• with a set frequency of 200kHz I get 5kHz - 5% error
• with a set frequency of 300kHz I get 9kHz - 7.7% error
• with a set frequency of 400kHz I get 1kHz - 10% error Do you know when the CCR registers will be characterised - roughly? Thanks! Ed

[edware]

Posted on May 17, 2011 at 12:20

Here's the MCO output waveform - PLL output /2.

[mail2shashikant]

Posted on May 17, 2011 at 12:20

Hi Edware,

We are also working and facing same problem while configuring clocks for I2C. Our configuration is: Fast mode Duty cycle 2. So for 400Khz the CCR value is 801E. And we are getting 88.888Khz. And for 100Khz CCR is 807B and we are getting 21.680Khz. Is this a problem in the controller or hardware? Please give a solution if you have.

[edware]

Posted on May 17, 2011 at 12:20

Hi mail2shashikant,

I don't have a solution, but would suggest you try one of the examples provided by ST in their firmware library. If the I2C examples run too slowly, I would suspect your hardware. Is it possible your setup is missing a divide by 4 factor somewhere? (i.e. using the RC oscillator output instead of the PLL output) Regards

[dale2]

Posted on May 17, 2011 at 12:20

Here's the information that may clear up this mystery:

You can get exactly 400KHz SCL output if you select ''duty cycle 1'', which is 2:1, instead of ''duty cycle 2'', which is 16:9. When you select ''duty cycle 2'', the timing of the Thi and Tlow are refactored and the granularity of the timing control via CCR becomes very coarse. If you are running full tilt (72MHz PLL with 36MHz PCK1 feeding the I2C peripheral), you can select between divisors of 4 (resulting in 360KHz SCL) or 3, resulting in 480KHz SCL which exceeds the fast mode I2C specification. Try changing to the 2:1 duty cycle in your initialization code and see if that works. I'm using it to talk to the LM75 I2C temperature sensor on the STM3210B-EVAL board and it seems to work just fine. I've checked the timing with an HP logic analyzer. Thanks, Dale Wheat

[edware]

Posted on May 17, 2011 at 12:20

I found the slow speed was due to multiple I2C devices on the bus.

When the number of devices was reduced, the I2C speed returned to 400kHz.