• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 1024 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.

Determining the I2C Module Clock Frequency

D.A. Hartman
Prodigy 20 points
Other Parts Discussed in Thread: DAC8574

All,

I've read the Clock Generation section of SPRU175A.  I'm trying to communicate to a DAC8574 from a C6713 (master), and I'm confused as to how to specify the I2C prescalar register (I2CPSC) when it is not clear to me what the module clock frequency needs to be.  I know that the master clock frequency should either be 100 kHz or 400 kHz according to whether it is operating in Standard or Fast mode, but what should I be setting the module clock frequency to?

Many thanks in advance for your help.

Dan

  • 0
    TI__Mastermind 18130 points

    Hi Daniel,

    I'm not sure how familiar you are with how the peripheral clocks are generated within the DSP so please forgive me if I cover some of what you already know. All of the DSP modules are clocked by the internal system clock. Page 77 of the datasheet includes a diagram showing how each of these clocks is derived. The main system clock coming from the PLL is fed into a divider for SYSCLK2 which is then divided down to feed the peripherals. This is the clock fed into the I2C module.

    For example, if running the DSP at 300MHz SYSCLK2 must be 150MHz (per the first footnote of Table 35 on p79). This means you must divide down the 150MHz clock to a 400 or 100kHz bus clock. I'm looking at a newer version of the I2C User Guide (SPRU175D), but Figure 11 names this as the "DSP Input clock." This 150MHz clock must be prescaled down to somewhere between 6.7 and 13.3MHz (divide 150MHz by between 12 and 22). This new clock is what actually drives the I2C logic.

    From here the clock is then divided again using the I2C Clock Dividers to then generate the 100/400kHz output clock.

  • 0 in reply to TimHarron
    Prodigy 20 points

    Thank you Tim.

    My apologies for referring to an outdated document.  SPRU175A is missing the required prescaled module clock frequency range between 6.7 and 13.3 MHz. 

    What's the rational behind choosing one value over another within the 6.7 through 13.3 MHz range, is it to achieve a whole number for the denominator for the I2C serial clock frequency equation (see Figure 11 from SPRU175D)?

    Thanks again for your help.

    Sincerely,

    Dan

  • 0 in reply to D.A. Hartman
    TI__Mastermind 18130 points

    Presumably this allows some leeway for calculating an output frequency as close as possible to 100/400kHz. I really can't say specifically as I did not design the IP block, but that seems a perfectly logical assumption to me.

  • 0 in reply to TimHarron
    TI__Guru*** 125430 points

    There's a noise filter that is part of the I2C block.  That prescaled clock frequency affects the window of time that the noise filter looks at.  Practically speaking though, I generally try to get the clock down to a convenient frequency in the given range.

  • 0 in reply to Brad Griffis
    Mastermind 7560 points

    Hi Brad-san,

    I'd like to know a little bit more details about the prescaled module clock limitation and the included noise filter.

    Q1)  If I don't divide I2C input clock down into the range of 6.7 - 13.3 MHz, is there any trouble?
    Q2)  What is the roll of the noise filter? (Is there any reason for the noise filter addition to I2C?) 

    Thanks in advance for your cooperation.

    Best regards,
    j-breeze

  • 0 in reply to j-breeze
    TI__Guru*** 125430 points

    j-breeze said:
    Q1)  If I don't divide I2C input clock down into the range of 6.7 - 13.3 MHz, is there any trouble?

    I cannot ever endorse operating outside of our required ranges and generally speaking cannot predict how things might fail if you disregard our specs.  Practically speaking, I've never seen any failures from customers operating "a little bit" outside the range, but I still don't recommend it.

    j-breeze said:
    Q2)  What is the roll of the noise filter? (Is there any reason for the noise filter addition to I2C?) 

    The I2C specification requires it.  Please see the spec for further details.

  • 0 in reply to Brad Griffis
    Mastermind 7560 points

    Brad-san,

    Thank you for your prompt reply and information. I will check the i2c spec out.

    Best regards,
    j-breeze

  • 0 in reply to j-breeze
    Mastermind 7560 points

    Hi Brad-san,

    I've got the I2C specification from http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf and read it to find descriptions of the noise filter. 
    So, what you pointed out is "Slope control and input filtering for Fast-mode devices...." in the chapter 1-1.  My understanding is correct?

    And then, in C6745/C6747 TRM(spruh91a), a description related to the noise filter is "A noise filter on each of the two pins, I2Cx_SDA and I2Cx_SCL" in chapter 22.2.
    It is also correct?

    Any advices would be appreciated.

    Best regards,
    j-breeze

  • 0 in reply to j-breeze
    Mastermind 7560 points

    Brad-san,

    I'm sorry for troubling you when you are busy, but I'd really appreciate it if you give me a reply.

    Best regards,
    j-breeze

  • 0 in reply to j-breeze
    TI__Guru*** 125430 points

    j-breeze said:
    So, what you pointed out is "Slope control and input filtering for Fast-mode devices...." in the chapter 1-1.  My understanding is correct?

    Correct.  Later in Table 4 it specifies "Pulse width of spikes which must be suppressed by the input filter".

    j-breeze said:
    And then, in C6745/C6747 TRM(spruh91a), a description related to the noise filter is "A noise filter on each of the two pins, I2Cx_SDA and I2Cx_SCL" in chapter 22.2.
    It is also correct?

    Yes.

  • 0 in reply to Brad Griffis
    Mastermind 7560 points

    Brad-san,

    Thank you for your prompt reply and kindly support.

    Best regards,
    j-breeze