• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1808 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 communication rate problem on Tiva Launchpad

Mark Shachkov
Prodigy 30 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hello, i am using Tiva Launchpad and Keil uVision 4.74.0.22. After compiling and flashing the compdcm_mpu9150 example from TivaWare 2.1.0 i am connected my 100MHz logic analyser (Saleae Logic 16 from aliexpress.com) to sda and scl lines and i was expected to see 400khz communication rate. But guess what i saw? First of all, rate is near 342khz (pulse period 2.92us) - that is first strange(unexpected) thing, because looking at the source code we can trace this part executing, while i2c module is initializing


//
// Initialize the I2C master module.
//
MAP_I2CMasterInitExpClk(ui32Base, ui32Clock, true);

where the ui32Clock is 40000000. According the data-sheet of the tm4c123gh6pm rev #15842.2741, page #1004, the formula to calculate expecting comm rate is SCL_PERIOD = 2 × (1 + TIMER_PRD) × (SCL_LP + SCL_HP) × CLK_PRD , where for our case CLK_PRD = 1/40000000; SCL_LP = 6; SCL_HP = 4; and TIMER_PRD is setting in time of I2CMasterInitExpClk execution. Checking the content of 0x4002.300C (I2C3 Master Timer Period (I2CMTPR) register address), we can see value of 0x04, which is providing us the the SCL_PERIOD = 2.5us. (as expected)

The second strange thing is that ratio scl_high/sch_low is 0.78 (on the screen: 1.28/(2.92-1.28)), but according the data-sheet it is fixed at 4/6 (0.666....).

So, do you have any ideas of what is going on?

  • 0
    Guru 47900 points

    We note this is your first post, here.  Welcome.

    I recall reading nearly an identical post - in fact the similarities are striking.  And - iirc - issue was resolved.

    There's a "search box" top/right this forum page - enter I2C and gradually sharpen your search criteria - bet you that past post will reveal...

  • 0 in reply to cb1
    Prodigy 30 points

    I'm really tryin' hard to find the topic u mention, but i have no results, after spending about 20 minutes =/
    Maybe u can give me some key-words (topic starter nickname or smthn like that)?

  • 0
    TI__Guru**** 244400 points

    Hello Mark,

    I2C is an Open Drain Bus Implementation. This configuration allows multiple masters to talk to multiple slaves w/o damaging the IO's when a contention occurs. when it does occur, then the I2C protocol is able to detect the same and the Master;s that see a mismatch between what they transmitted and what was on the bus relinquish the bus.

    To be able to do this with Open Drain, a Pull Up is required so that when the Master or Slave wants to put a 1 on the bus it releases the drive to the IO causing the Bus to Rise to 1 with the Pull Up. So in effect this is a RC charging of the line and will follow the RC time constant.

    From the controller perspective, it released the bus at time T=0, but for the RC to charge the bus the Time constant will come into picture. As a result the Ratio of SCH/SCL would be different on the IO.

    Also when baud rate is programmed to 400K, the actual baud rate will be lesser as the controller samples the line to an effect called clock stretching which is a mechanism by which a Slave can reduce the SCL clock rate. This can be read in the I2C specification.

    I hope this is a descent explanation.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 30 points

    Amit Ashara said:

    Hello Mark,

    I2C is an Open Drain Bus Implementation. This configuration allows multiple masters to talk to multiple slaves w/o damaging the IO's when a contention occurs. when it does occur, then the I2C protocol is able to detect the same and the Master;s that see a mismatch between what they transmitted and what was on the bus relinquish the bus.

    To be able to do this with Open Drain, a Pull Up is required so that when the Master or Slave wants to put a 1 on the bus it releases the drive to the IO causing the Bus to Rise to 1 with the Pull Up. So in effect this is a RC charging of the line and will follow the RC time constant.

    From the controller perspective, it released the bus at time T=0, but for the RC to charge the bus the Time constant will come into picture. As a result the Ratio of SCH/SCL would be different on the IO.

    Also when baud rate is programmed to 400K, the actual baud rate will be lesser as the controller samples the line to an effect called clock stretching which is a mechanism by which a Slave can reduce the SCL clock rate. This can be read in the I2C specification.

    I hope this is a descent explanation.

    Regards

    Amit


    So, according your words, the mpu9150 can not communicate over i2c on rates higher than 340khz? But guess what happen when i manually changed the value of I2CMTPR - the rate increased(370khz) and the mpu9150 still giving proper data. (Using 80MHz clock, I2CMTPR is 0x09 after initialization procedure, i set it manually to 0x08).

  • 0 in reply to Mark Shachkov
    TI__Guru**** 244400 points

    Hello Mark,

    I never said that MPU9150 cannot work above 400K. I was only explaining why the behavior you are seeing are happening. You do not need to change the MTPR to confirm that. You can change the Pull Up resistance and the Baud rate will change.

    The maximum rate at which MPU9150 (or for that matter any i2C Slave device) is mentioned as part of the Data sheet of the device.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 47900 points

    May I register my support for Amit here?  He's answered correctly/completely in our book.

    You seem fixated on, "400KHz or bust" - yet no explanation of why that's such a, "Holy grail!" 

    Any I2C line capacitance or excessive (pull-up) resistance (anywhere upon your I2C connection path) will potentially reduce bus speed.  You may try disconnecting your slave board - and then scoping the MCU's clock output - freed from the burden imposed by your slave board.  Such often serves to identify where the bus "bottleneck" resides - if any really exists.

    I'd be surprised if your system (notably) suffers due to even a 20% fall-off from the "theoretical" 400KHz I2C setting...