• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 234 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.

MSPM0G3518: I2C Clock Frequency - TPR

Matthias Gilch
Prodigy 30 points

Part Number: MSPM0G3518
Other Parts Discussed in Thread: MSPM0G3519

The TRM says I2C Frequency is calculated with the following formula:
I2C_FREQ = I2C_CLK / ((1+TPR) × (SCL_LP + SCL_HP ))

The TRM also says in the description of the CTPR/MTPR register we can use this formula:
SCL_PERIOD = (1 + TPR ) × (SCL_LP + SCL_HP ) × INT_CLK_PRD

They are basically the same. For both formulas I get when using:
I2C_CLOCK = 40MHz, I2C_FREQ = 400kHz => TPR = 9

This is also in the table of examples. 

But if I write 9 into TPR, I'll get a I2C SCL Frequency of ~370kHz. Only If I set it to 8, it'll be the correct frequency.

 

Do I miss some point in the TRM or is this considered a bug?

  • 0
    TI__Genius 15430 points

    Hello Mattias, 

    It seems that it relates to the clock stretching checking function of the I2C controller. I2C controller will take time to check whether the clock line is stretched every time, so it makes the clock frequency lower than the setting value. You can try to disable clock stretching function of the I2C controller, and then check whether the clock frequnecy is correct. 

    BR,

    Janz Bai

  • 0 in reply to Janz Bai
    Prodigy 30 points
    Hello Janz,
    The controller's clock stretching was already disabled, so I don't think my observations are related to that.
    Do you have any other ideas about what could cause this behavior? Have you seen similar issues before, or is there anything else you would recommend checking?
    Best regards,
    Matthias
  • 0 in reply to Matthias Gilch
    TI__Genius 15430 points

    Hello Matthias,

    Does the I2C target enable the clock stretch function, if yes, could you please try to disable it and check again.

    And could you please try to run the demo in our SDK and check whether the clock can achieve 400kHz. (change I2C source clock to 40MHz, and set I2C bus clock to 400kHz). mspm0_sdk\examples\nortos\LP_MSPM0G3519\driverlib\i2c_controller_rw_multibyte_fifo_poll. And then tell me the results, by this, we can keep at the same page about this issue. It will be helpful for further analysis.

    BR,

    Janz Bai

  • 0 in reply to Janz Bai
    Prodigy 30 points

    Hi Janz,


    I've tried disabling the target clock stretching. This also did not help. 

    Here's the result of the SDK example, you've mentioned. I've used the LP_MSPM0G3519 and connected some I2C sensor, I've had laying around.

    Please find also the modified files of the example: i2c_controller_rw_multibyte_fifo_poll.zip 

    BR,
    Matthias Gilch

  • 0 in reply to Matthias Gilch
    Guru 103365 points

    I think what you're observing is the rise time. The I2C unit maintains a fixed High period, but that period doesn't start until SCL rises to Vih. So you're getting an extra (portion of) 443ns in your clock cycle.

    You can reduce the rise time by using stronger pullups.

    [Edit: Or, as you've demonstrated, you can reduce TPR to reduce the High/Low periods to compensate for the (added) rise time.]

  • 0 in reply to Bruce McKenney
    Prodigy 30 points

    Hi Bruce,

    you're right. I've confirmed the behavior with stronger pull-ups. I forgot about this. I think the fact, that reducing the TPR value by one hit exactly the 400kHz threw me off. 

    Thanks!

    BR, Matthias Gilch