I2C Clock Rate

[lpcware]

Content originally posted in LPCWare by Dave on Mon Jan 07 13:12:07 MST 2013
I'm having difficulties understanding what's going on with the I2C clock and am hoping somebody can shed some light on this for me.

I'm using the LPC1788 processor, and am using the system_LPC177x8x.C file for setting up the clocks.

My target has an external 12Mhz crystal, and the clocks are setup as follows:
<code>
PLL0 Configuration: 
   MSEL=10, PSEL=1

PLL1 Configuration: 
   MSEL=8, PSEL=2

CPU Clock: 
   CCLKDIV=1
   CCLKSEL = PLLO

USB Clock:
   Divider is 4
   Clock output from PLL1

EMC Clock:
   EMCDIV=1

Peripheral Clock:
   PCLKDIV=2

Clock Output Configuraton Register (CLKOUTCFG)
   CLKOUTSEL=CPU clock
   CLKOUTDIV=1
   CLKOUT enable= unchecked

Flash Accelerator=checked
   FLASHTIM=6 CPU clocks
</code>

According to the user's manual, the equation for setting the clock speed is as follows:

<code>
                          PCLKI2C
I2Cbitfrequency=   ---------------------
                      I2CSCLH + I2CSCLL
</code>

and in Table 502 (Example I2C clock rates), when PCLK is 60Mhz, you should get a 400kHz clock rate if I2SCLL + I2SCLH equals 150

so here is my problem:

When I set I2SCLL to 75, and I2SCLH to 75, I get the following waveform on SCL (P5.3):

http://www.lpcware.com/content/image/336khz-clockjpg-0

Am I missing something here?

[lpcware]

Content originally posted in LPCWare by Dave on Fri Jan 18 09:31:28 MST 2013
Hi Wouter,

This explains it perfectly - thank you for your time in responding. 

I expect the dynamic performance of the bus will be predictable in manufacturing, and will sleep better at night...

[lpcware]

Content originally posted in LPCWare by Wouter on Fri Jan 18 04:21:43 MST 2013
Hi Dave,

A bitrate lower than set by the I2CSCLH and I2CSCLL register is something that can be typically expected. As explained earlier, I2C slave devices may use clock stretching. The I2C master supports this feature by carefully watching the SCL line, wait for SCL to become high (atleast 0.7VDD) and then keep SCL high for as long as specified in the I2SCLH register. Therefore, the risetime influences the bitrate.

The 3-12 mA spec you mention is only for the HS mode, not for Fast-Mode. The minimum value of the pull-up resistor depends on the VDD, and can be found in figure 37, page 40. With VDD=3.3V, this would be about 1.2k when no series resistor is used. The maximum value of the pull-up resistor is limited by the risetime (thus also by busloading etc.). For Fast-Mode, the maximum risetime is 300ns (Table 5, Page 32). Looking at the waveform from your first post, you have about 300ns of risetime (best guess, but hard to see at current timebase). So your 2.4k pull-ups seem to be about the maximum. Now, 400KHz would give a period time of 2.5us. However, due to your 300ns risetime you would have a period time of 2.5+0.3 = 2.8us = a frequency of 357KHz! Of course this is very confusing because of the formula given in the user manual. I'll submit a request to add a remark to the user manual to clarify this.

But, this makes the gap between the measured bitrate of 336KHz and expected bitrate (now 357KHz instead of 400KHz) already a lot less (~21KHz). I'm not really sure where this difference comes from, but I see about the same over here.

I used the EA1788 board, pin P5.3 (SCL). No bus load, pull-up of 2.4k, configured for 400KHz (I2SCLH = I2SCLL = 75):
- Measured frequency is 387KHz, risetime is 200ns.
- Expected frequency is 1/(2.5us + 0.2us) = 370KHz
Gap between expected and measured bitrate is ~17KHz...

I hope this explains to you why the measured bitrate is different than what you would expect, and that a difference of 20KHz is okay for you.

Regards,
Wouter

[lpcware]

Content originally posted in LPCWare by Dave on Wed Jan 16 10:31:10 MST 2013
Hi Frank,

After reading "Zero's" comment above (about the current requirements on the bus), I decided to look up the spec... and whaddya know - there really is a spec for minimum current through the pull-ups...

Here's the spec - http://www.nxp.com/documents/other/39340011.pdf

And on page 35, Table 6, it shows the current should be somewhere between 3-12 ma (Ics) - since I'm on a 3.3V system, that means my pull-ups should be between 275-1.1k ohms.  On a 5V system, they fall within 416-1.6k ohms...

Funny, because I always see development boards with pull-ups from 4k-10k...

All this aside, I'm pretty sure this has nothing to do with the timing issue being discussed here  (LOL)...

But I'm glad to see I'm not the only one experiencing this phenomenon... 

I ended up adding a constant to my target frequency in the calculation, as follows:
<code>
   ClockRate = PeripheralClock;
   Temp = ClockRate / (I2C_FREQ+90000);
   //Temp = ClockRate / (I2C_FREQ);
  
   LPC_I2C0->SCLL   = (uint32_t)(Temp / 2 );                   // 50% duty...      
   LPC_I2C0->SCLH   = (uint32_t)( Temp - LPC_I2C0->SCLL );     // 50% duty...      
</code>

This workaround works well, but my concern is this:

1.  Is this offset because of my board layout?

If this is the case, then in production, the boards will be the same, so the capacitance should be the same, so no big deal - the code doesn't have to change.

2.  Is this offset because of the processor?

If this is the case, then as long as it's repeatable from processor to processor, no big deal - the code doesn't have to change.

If it ISN'T repeatable from processor to processor, then I have to somehow figure out how to tune it during the manufacturing process - which will add cost and time...  <i>and this isn't what I expected from NXP when I chose this processor...</i>

I'm hoping for NXP to chime in here any minute now...  :-)

[lpcware]

Content originally posted in LPCWare by FrankAndersen on Wed Jan 16 03:33:47 MST 2013
Hi Dave,

Just want to say that I am seeing the same problem on LPC1788, running the PCLK at 48MHz, gives 99 KHz using 240 + 240. Almost correct, but trying to increase the CLK to 400 KHz, by putting 60 + 60, gives 372 KHz.

Pull up is 4K75.

Best regards,

Frank Andersen

[lpcware]

Content originally posted in LPCWare by Dave on Tue Jan 15 10:41:41 MST 2013
So Paul (and anyone else from NXP), I'm a little concerned here...

Is there something else I might be missing?  It seems to me that if the Peripheral clock is fixed at 60Mhz, and I'm setting a counter for both off-time and on-time on the clock, it should be pretty predictable, shouldn't it?

I guess my next question is this:

Is the difference predictable from processor to processor?  In other words, will the constants that are necessary to bring the clock back to 400kHz be the same for the next processor, or is there some dynamic tuning process I'll have to come up with to compensate for this error...

[lpcware]

Content originally posted in LPCWare by Dave on Wed Jan 09 11:03:31 MST 2013
Unfortunately, reducing the resistor value on the pull-ups on both SCL and SDA only sharpened the waveform, and had no effect on the frequency.

The scope pictures are attached to this response...

the 336kHz Clock JPEG is using a 2.4k ohm pull-up, and the 338kHz is using a 1k ohm pull-up on both the SCL and SDA lines...


I am wondering if there's anyone else out there that actually achieved the desired frequency by following the instructions in the user's manual???

I can certainly attain the target frequency by reducing the values in the I2SCLL and I2SCLH registers, but this seems a little lame to me...

[lpcware]

Content originally posted in LPCWare by Dave on Mon Jan 07 18:19:34 MST 2013
Well, the scope shot in my first post IS my SCL - with 2.4k pull-ups...
I'll try and swap the resistors tomorrow, and post a new scope picture for a one-2-one comparison...

Thanks guys for the suggestions...

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jan 07 16:55:41 MST 2013
The cruel truth is that this formula is crap. Of course I2C Specifications are recommending to use at least 3mA, a lot of schematics show higher resistors like 4.7k or 10k. I prefer 10k (especially since I use low power I2C sensors in low power devices). Yes, reducing pullups is increasing I2C speed, but AFAIR reducing my 10k to 1k (LPC11C14) just brought me about 2%, so this method isn't helpful at all. If you use a modern I2C device I would suggest to use a solid 4.7k and scope your SCL. That's what I'm doing since years with all LPC11xx, LPC13xx and LPC17xx...

[lpcware]

Content originally posted in LPCWare by Dave on Mon Jan 07 16:03:50 MST 2013
Hi Paul,

Thanks - that makes sense to me...  I'm using 2.4k ohm pull-ups, and I read somewhere that typical values are 10k for 100kHz, and 2k for 400kHz...

I'll drop them to 1k ohm and retest...

Eventually, I'm shooting for somewhere around 600kHz (estimate).... Do you think 1k ohm is low enough?  That's only a few milliamps, and I have unlimited power on this board (well, almost unlimited)   :-)

[lpcware]

Content originally posted in LPCWare by NXP_Paul on Mon Jan 07 15:24:40 MST 2013
Hi Dave
I don't think you're experiencing clock stretching since most Fast Mode Plus devices (PCA96xx) do not have the ability to stretch the clock.  Please refer to the second sentence "having a high capacitance on the bus or having a pullup resistor that is too large a resistance can cause a similar effect by increasing the amount of time it takes for the clock to rise again".  If you lower your pull-up resistor value, the rise time will improve, and you should notice a higher I2C clock frequency.

-Paul

[lpcware]

Content originally posted in LPCWare by Dave on Mon Jan 07 14:04:21 MST 2013
<code>
I2C doesn't operate at a fixed clock speed because the I2C master responds to something called "clock stretching" which happens when the clock is held low by a slave to request more time before the next clock. This can slow down communications. Also, having a high capacitance on the bus or having a pullup resistor that is too large a resistance can cause a similar effect by increasing the amount of time it takes for the clock to rise again.
</code>

Wow... I find this hard to believe in my situation.  All of my peripherals are 1Mhz parts!  If these parts are "stretching" the time on the clock signal at 400kHz, then what will happen when I run them at 1Mhz?

And how predictable will the timing be?

I'm using the I2C bus to communicate with peripherals INSIDE of another interrupt, that has a finite amount of time...

Hmmm - anybody else have anything here?

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jan 07 13:43:13 MST 2013
That's not unusual, see http://www.lpcware.com/showthread.php?t=3877