• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1857 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C outputting incorrect clock

Joseph Senay54
Prodigy 220 points

I am using a TM4C123 family microcontroller as the master of a PMBus.  While trying to debug an issue that is causing a bad CRC to occur on some reads, faster clock speed seems to operate better with the particular power module I am using, so I wanted to increase my I2C clock speed from 100KHz to 400KHz. At 100KHz the clock and data look fine, besides the occasional CRC error. When trying to move to 400KHz though, the I2C bus clock seem to be more like 268KHz or so. I would think that the operation of changing the I2C data rate would be as simple as changing:

ROM_I2CMasterInitExpClk (I2C4_BASE, ROM_SysCtlClockGet (), false);

to

ROM_I2CMasterInitExpClk (I2C4_BASE, ROM_SysCtlClockGet (), true);

Now I have known the SysCtlClockGet() function to be a bit finicky in the past, so I tried an explicit value of 50,000,000 in the function's place. Still see a clock around 260ish KHz. My system clock is set up for a 50MHz clock, I believe:

//400MHz/(2*4) = 50MHz

ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_OSC_INT); 

Any suggestions?

  • 0
    TI__Guru**** 244400 points
    Hello Joseph

    What you are seeing is something called SCL clock stretching. The master is attempting to meet the 400KHz, but due to RC charge time of the bus, the rising edge is delayed, which causes the master to wait and then put the next SCL pulse. Since the SCL is effectively shifted out it would cause the bus frequency to be lower.

    This is a standard behavior of the I2C bus and nothing to do with TM4C12x devices. You can compensate the same by reducing the value of the R and making it stronger.
  • 0 in reply to Amit Ashara
    Prodigy 220 points
    Amit,

    I do not believe this is a clock stretching issue. Or if it is, I don't believe this is the only issue. The pull-up is 2K and the rising clock edge is not all that slow, it looks like it could manage the 400KHz. When I manually change the system clock input into the MasterInitExpClk() function the I2C can get closer to 400KHz, ~350KHz. If it was clock stretching I don't believe I could get it to be better than what I had previously. At 40MHz system clock is about when I can no longer get closer to the 400KHz I2C clock.

    Regards,
    Joseph
  • 0 in reply to Joseph Senay54
    TI__Guru**** 244400 points
    Hello Joseph,

    Checklist

    1. Is the I2C Glitch Filter enabled?
    2. What is the value being programmed by the API to the I2CMTPR register for 50MHz system clock
    3. A snapshot of the I2C transaction!
    4. What is the maximum operating SCL for the slave device as per the slave device datasheet?
  • 0 in reply to Amit Ashara
    Prodigy 220 points

    Amit,

    1. I2C glitch filter is enabled with 31 pulse filter

    2.  I tried letting the function set this register and setting it explicitly to 6 then 5. With 6 I would expect a 357KHz clock and with 5 I would expect 416KHz. Neither worked as expected (screenshots below)

    3. Attached

    4.  It supports both 100KHz and 400KHz as specified in its datasheet.

  • 0 in reply to Joseph Senay54
    TI__Guru**** 244400 points

    Hello Joseph

    Joseph Senay54 said:
    1. I2C glitch filter is enabled with 31 pulse filter

    That explains a lot. The Glitch filter causes the effective clock to be slowed down as the glitch filter requires to monitor the line for 31 continuous low or high to allow it to be passed.

    Please see the effect of glitch filter on TM4C129x for 100 KHz. The effect is more profound at 400KHz


    As an experiment reduce the glitch filter to 4, 8 and 16 and you would see the SCL changes and moves closer to 400KHz.