• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 1546 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

SMB/I2C short clocks look like glitches to slave

TM4C123BH6PZ: I2C SCL Clock Pulse too short - Runt Pulse

Brittany Kurtz
Prodigy 40 points
Part Number: TM4C123BH6PZ

Hello,

First of all let me explain that I have seen a few posts similar to this issue already. I still have some questions regarding what is happening in my system and the origins of the problem. 

I am using the TM4C123BH6PZ in a single-master mode configuring to an ADC (MCP3428-E/ST) and the pull-up resistors on the bus are 4.99Kohms. The bus is running at 100KHz. 

My issue is his: I observed a very short clock pulse that seemed to confuse the timing between the MCU and ADC, which caused the ADC to hold SDA low while waiting for the stop bit. See the captures below. Unfortunately I have only been able to capture this error with a logic analyzer. The measured pulse width of the runt pulse is .2599uS.

From reading about other users having similar problems with the tm4c, I am still not clear what the origin of the issue is. Does the tm4c glitch filter only handle inputs on SCL/SDA or is it possible for the glitch filter to also filter out these runt pulses on the output of SLC? 

Is this a proven issue with the tm4c (and if so is there a diagnosis and solution?), or is it more likely something with my firmware or hardware? I did read one user claim that lowering the pull-up resistor values fixed the problem because the rise time of the runt pulse did not meet the specs, so the mcu was trying to re-establish correct communications. If this is happening in my system (since I have 4.99k instead of the conventional 4.7k pull-ups), why is the rise time not slow on all of the SCL pulses, instead of just a few random pulses? 

Any ideas/tips are welcome, thanks! 

  • 0
    TI__Guru 72500 points
    Hi Brittany,
    Typically runt pulses on the I2C SCL means that the rise time of that signal is too slow. The master releases the line, but it thinks the slave is holding it low so it also asserts it low and delays another clock period. You really need to look at the signals with an oscilloscope as the logic analyzer hides the details of the rise time from you. Depending on the capacitance of your I2C bus lines, the 5K pull-up may be too large. Your rise time may be marginal, working just barely most of the time, but not always. Here is some more information about I2C bus operation and calculating pull-up resistor values.
    www.ti.com/.../slva689.pdf
    www.ti.com/.../slva704.pdf
  • 0 in reply to Bob Crosby
    Prodigy 40 points

    Hi Bob,

    Thanks for information. I have not been able to capture a runt pulse with a scope yet (they seem very intermittent), however attached is a capture of how the rise times normally look. Yellow is SDA, Green is SCL.  

    The I2C spec calls out the max rise time is 1000ns. The signals have a rise time of 730-790ns, which does seem pretty large but should I be concerned about this considering they are below the max?

  • 0 in reply to Brittany Kurtz
    TI__Guru 72500 points
    Actually, that looks like it should work. Does the scope have the ability to capture a pulse? Maybe you can capture the runt pulse. Can you tell me if the sequence on the logic analyzer is a write or read to the ADC? (Who is driving SDA when the glitch occurs?) Does the glitch always occur at the same spot in the sequence?
  • 0 in reply to Bob Crosby
    TI__Guru 72500 points
    It would be interesting to see if the runt pulse goes away if you reduce the size of the pull-up. Perhaps you can just put another 5K in parallel with the current 5K (resulting in an equivalent 2.5K pull-up). If that does not solve the issue, it is not a simple rise time problem.
  • 0 in reply to Bob Crosby
    Prodigy 40 points

    The runt pulse happened on a write to the ADC. Since I've only been able to capture and observe this runt pulse only once, I don't know if it always happens in this bit order or if it changes. From talking with some of my coworkers, it seems that this problem could take a few days of constant run time before it happens again, which is why it's hard to capture. 

    By reading this post https://e2e.ti.com/support/microcontrollers/other/f/908/p/423351/1509939, it seems that there were some error handling issues and possibly some problems in the TivaWare Library concerning the glitch filter. 

    What I am confused about is how would the glitch filter helps remove the runt pulses on SCL? It sounds like this glitch filter is only for removing pulses less then 50ns on an input into the mcu. Is this true? 

  • 0 in reply to Brittany Kurtz
    TI__Guru 72500 points
    This does not look like a glitch filter issue to me. From the logic analyzer trace, the TM4C should have been generating a clock at this time.
  • 0 in reply to Brittany Kurtz
    TI__Guru 72500 points
    Did you resolve this issue?