i2c clock frequency

Discussion in 'Embedded Systems and Microcontrollers' started by prajagop, Apr 20, 2010.

  1. prajagop

    Thread Starter New Member

    Apr 19, 2010

    I have been trying to ask this question at NXP I2C support & Forum, but haven't had a reply so far. It is really on the I2C bus, rather than on any particular controller.

    So, here we go:

    I have a processor that supports the I2C port (Philips 2.1 Rev), and I am trying to measure the clock frequency for fast mode. I have an Rp (pull up R) of 1.2KOhm to 3.3V.

    I read that I need to have a correct pull-up resistance, and it also depends on the capacitance. I have NO slave connected to the device, and I am probing the signals from the pcb using an oscilloscope, so can I assume a Max Cp of 400pF, or do I need to actually measure the rise-time and then look at it?

    The formulae as I know is Rmax*Cmax = 1.18tr, where tr is the rise time (300ns for fast mode), Rmax is the limit outside which the clock starts slowing down, and Cmax is the max load capacitance.

    I just want to arrive at accurate frequencies, with no slave device connected. Currently I am observing 345Khz for 400Khz. Could it be that the capacitance is too high (thus Rp should be rather low, so that the rise time doesn't increase), but I have nothing connected to the Master I2C signals?

    The processor spec says it confirms I2C spec, and I dont have any other details from its datasheet. How exactly do I arrive at an accurate clock frequency for my Master board, when no slave is connected to it?

  2. John Luciani

    AAC Fanatic!

    Apr 3, 2007
    The clock frequency is usually set by changing the value in a configuration
    register. It is independent of the bus capacitance and the pullup (within reason).
    Loading the bus with too much capacitance or using two high a pullup resistance
    will increase your rise and fall times but the frequency will be unchanged (within reason).

    Is the I2C frequency set properly in software? The I2C frequency is usually
    dependent on the system clock. Is the system clock running at the proper
    frequency? A system clock that is 10% slow could produce the difference
    you are seeing.

    (* jcl *)