• State Answer Suggested
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 2431 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.

Length of delay before checking I2CMasterBusy() after I2CMasterControl() call?

C Z
Prodigy 10 points
Other Parts Discussed in Thread: TM4C1230C3PM

I spent today trying to troubleshoot a bug in my code for writing/reading an Atmel at24cm01 EEPROM chip via I2C on my Tiva TM4C1230C3PM running at 50Mhz, with the I2C clock in slow mode (100 Kbps).


I discovered a few helpful posts on this forum, mostly from Amit Ashara, giving the advice to wait on both while(!I2CMasterBusy()) as well as while(I2CMasterBusy()) after calling I2CMasterControl(), instead of just waiting on while(I2CMasterBusy()). This lead me to my solution, but didn't quite work out in my case since sometimes the program would hang forever in the loop while(!I2CMasterBusy()).

Instead, the solution that worked for me was to have a SystemCtlDelay(100) before every while(I2CMasterBusy()) loop, to allow some time for the I2C busy flag to be set before waiting, but not loop infinitely. This works consistently for me.

I can post my relevant code if need be, but my question is about the general case: how can I figure out the shortest safe argument for the call to SystemCtlDelay(), where I am still giving enough time for the busy flag to be set. I've tried with SystemCtlDelay(10) (30 cycles) and it seems to work consistently, but I bumped it up to 100 to be on the safe side since 300 clock cycles isn't a crazy-long time to wait.

Is this something I can only figure out by experimentation or is there some math that will lead me to a safe but short delay time?


Thanks!

  • 0
    TI__Guru**** 244400 points
    Hello CZ,

    The delay can be expressed as a function of the Control bit setting and the Busy flag becoming set. The biggest variable that needs to be accommodated is the prefetch buffer size and code placement. I have tried that but specifying the same changes with the different values customers have used for the system clock. Rather I would suggest slight bit of experiment to identify the value most suitable or move to interrupt mechanism.

    Regards
    Amit
  • 0
    Intellectual 290 points

    I find myself in the forever I2CMasterBusy after using I2C_MASTER_CMD_SINGLE_SEND.  According to the datasheet the I2C controller should always return to idle.  Is the datasheet incorrect?

  • 0 in reply to Stephen Holstein
    TI__Guru**** 244400 points
    Hello Stephen

    Yes, the master will return to Idle State, unless the slave holds the clock low. Can you check on the scope if the SCL and SDA return to high state?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 290 points

    I had assumed that the  Tiva™ TM4C123GH6PM chip would have taken care of the I2C pullups.  Once I added additional resistors (4.7K) to the SDA and SCL the circuit works.  There should be a note that the I2C bus requires additional pullup resistors.  

  • 0 in reply to Stephen Holstein
    TI__Guru**** 244400 points
    Hello Stephen,

    There are IO pull up's (20K-40K) that can be used. However since I2C bus capacitance is not known and neither is the Pull Up v/s Speed v/s Power requirements, we do not enable this pull up by default.

    The I2C bus application note also highlights the same fact

    www.ti.com/.../spma073.pdf

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 11940 points

    I need to second Amit's answer here.

    The fact that the I2C bus needs pull-up resistors is well known and documented, and an intrinsic property/requirement for this bus.

    There are IO pull up's (20K-40K) that can be used. However since I2C bus capacitance is not known and neither is the Pull Up v/s Speed v/s Power requirements, we do not enable this pull up by default.

    By my own and other's experience, 20..40k is far too much. A value of 1..10k is often recommended, and worked better for me. However, that also depends on bus mode (usually 100kHz .. 1MHz), line length, and impedance.