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.

TM4C129XNCZAD: TM4C I2C Master generates short SCL clock pulses/glitches

Part Number: TM4C129XNCZAD

Hi,

I know this topic has already been discussed in a few topics (e2e.ti.com/.../569566

e2e.ti.com/.../1799603

However I'm still missing an explanation for the source of the problem, so here is my situation.

I'm using a TM4C129 as I2C master. Glitch filter is set to 8 (running at system clock of 120 MHz) with a I2C at 100 kHz

So what I have here is the same situation as described in the other threads with a short SCL pulse:

I know that the signal quality is rather poor and the rise time for the clock is beyond limits.

But what I don't understand is, why the Master aborting the started clock edge and pulling it low. At this point I'm 100% sure the master is holding the SCL lane low, as the slaved use different low levels when they perform clock stretching.

My current assumption is, that the rise time of SCL is too slow for the master and thus it assumes a slave holds the clock low. And then the master holds the SCL low for itself to keep a regular timing for the scl toggling. However I cannot find anything about this behavior in the datasheets.

So can you please confirm my theory or if it is wrong can you explain whyy the TM4C master is holding the clock low after aborting the clock edge?

Many thanks in advance

Fabian

  • Hello Fabian,

    To better understand you exact system setup, have a couple questions:

    Do you have any other master devices on the bus? Could the glitch be coming from another master device if so?

    What value pull-up resistors are you using?

    Also for your reading, Section 6 of our I2C app note also has some comments on glitch suppression (not directly related your question, but useful nonetheless to expand on DS content): www.ti.com/.../spma073.pdf
  • Hi thanks for the quick resonse.

    We have a 4k7 pull-up resistor, which I know is too high. As I said I know the rise time is beyond limits. So we will adjust this for sure

    But what I'm trying to understand is what is bringing the TM4C to pull the clock low again during a rising edge.

    We are using a single master system so I'm 100% sure the glitch is coming from the TM4C.

    Concerning the glitch suppression, the data sheet is not completely clear for me: As I understood it, it affects the input (or output during write) path, when it comes to shifting the data into/out of the IO FIFOs.

    I did not expect it to affect the clock generation. Or am I wrong in this interpretation?

    best regards

    Fabian

  • May it be asked if that 'swallowed SCL pulse' ALWAYS OCCURS at that particular 'Bit Position' - or with (only) those TWO I2C SDA code transactions?      

    Might you alter the SDA output to, 'TWO OTHER (legal) SDA Codes - and note if (anything) changes?     (especially the Bit Position - in which SCL becomes 'swallowed.')

    What happens if you apply that exact same I2C transaction with a  DIFFERENT I2C chip?     (not the same model being used)    Indeed the Slave should have 'Limited Ability' to impact SCL - yet 'Such HAS OCCURRED' (we've seen it - twice iirc!) - and represents an 'illegal' Slave Behavior.    

    What's proposed here seeks:

    • to remove a 'defective/illegal' Slave response as a possibility
    • gain insight as to the MCU being (somehow) 'sensitive'  to a certain 'Bit Position or SDA Sequence' - which may lead to such (unwanted) behavior.

    To insure the 'cleanest performance of the MCU's I2C Module' - we find it desirable to execute an 'I2C Module Reset Function'  prior to (further) use  - which should insure 'proper initial operating conditions...'

    Like you - we're leaning to an 'MCU Issue' - and the methods herein - intend to 'fairly' determine if the "MCU Alone" - sits atop the Suspect List...

  • The glitch in the SCL lane is randomly distributed across different bit positions as well as different addressed slaves.

    What I notice on such a SCL glitch is, that the rising edge of the SCL got a bit of distortion (due to external noise) which causes it to rise a bit more slow than in the other cases when the SCL is generated correctly.

    That is what brings me to the assumption, that the MCU aborts the pulse and pulls SCL low again. Which is in my opinion a legal behavior of a master, e.g. when it assumes/detects someone is holding the SCL low e.g. a slave performing clock stretching.
    In that case I assume that the MCU would hold SCL low until its internal timers advance to the next cycle to generate a new valid clock pulse.
    If that's the case I don't see any problem in this behavior, as this all seem to be valid I2C bahavior. In this case the source of the problem is the bad signal quality which we have to deal with anyway. If thats not the case we have to dig for another explanation.

    So can you please confirim or disprove this theory.

    Best regards
    Fabian
  • Hello Fabian,

    I agree that the issue stems from the bad signal quality. I don't see any flaws with your described understanding of the I2C behavior on the TM4C end.

    I think both cb1 and myself are more looking as to how to help you solve the issue so the glitches no longer plague your system.

    Changing the pull-up resistors would be the biggest task at hand and hopefully will resolve the issue. In addition to that, you can also detach your slave devices to verify that the MCU is not causing any of the undesirable behaviors as well.
  • Do (any) of these 'compromised' SCL clocks occur w/in the FIRST passed 'SDA Byte?'    (i.e. prior to the generation of the 'ACK' - by a properly addressed Slave - which is performing properly)

    To my mind - the I2C Master's ability to impose a 'slowed SDA signal's rise' - proves doubtful.     It would almost surely prove helpful to provide a 'proper' Current Monitoring of SCL - and contrast that measure during 'Normal vs Runted' SCL events.

    You specify 4K7 as pull-up R value - has that (really) and (recently) been MEASURED?      Unless there are MANY devices on your I2C bus (making it capacitance laden) - it is our (usual) experience that 4K7 proves successful.     It must be noted too - that STILL UNEXPLAINED - is 'HOW that SAME 4K7 value - WORKS SUCCESSFULLY - THE  VAST MAJORITY OF THE  TIME!'

    How many devices ARE RESIDENT upon your I2C Bus - and must ALL be "Up & Powered" - even when - especially when - only ONE is going to be (immediately) addressed?   (many I2C devices can be powered by a single MCU GPIO - or certainly by that GPIO driving into an xstr. buffer...)

    And - would it not prove more INSIGHTFUL - to temporarily switch to another I2C Port - and, 'Test for the overlap of this occurrence?'     I don't believe that the full & proper 'Powering of the MCU' has been proven - and 'Power' is always - the 'first & most vital segment' - to 'Test/Verify!'     If possible - and you agree to attempt such test - employ I2C pins from a, 'Different Side' of your MCU!     (each side of the MCU is (somewhat) separated by the internal power routing scheme...)

  • Hi Ralph, hi cb1

    We have reduced the Pull-up to 1k which gives us rise times which are within the required limits. and we have reduced a serial resistor (from 100R to 47R) which we use in combination with a TVS fo protection against external ESD pulses.

    We have around slaves. The reasons why we have such a high load, is due to the routing of the I2C bus, which is across multiple PCBs and multiple connectors. All slaves are constantly powered. I don't think the power supply is the bottleneck, as the power supply is far overrated.

    With the reduced Pull-ups we have not seen any problems so far. But this is not a reliable information, as it is rather hard to trigger for thoses glitches. So I will need some time and hopefully can provide you better measurements next week. So this is as expected the obvious solution, so far so clear, but I still want to understand what & why the SCL lane is pulled low during a rising edge.

    @ cb1:

    " It must be noted too - that STILL UNEXPLAINED - is 'HOW that SAME 4K7 value - WORKS SUCCESSFULLY - THE  VAST MAJORITY OF THE  TIME!'"

    Well that is not completely true: As I said in my previous post: "What I notice on such a SCL glitch is, that the rising edge of the SCL got a bit of distortion (due to external noise) which causes it to rise a bit more slow than in the other cases when the SCL is generated correctly." So to sum it up: with a 4k7 resistor we are at the edges of the specification with the rise time (~1000 ns), and with a bit of noise we are exceeding the specified rise time of 1000ns. That is what brings me to the theory with the MCU pulling SCL low again when it realizes the rise time is obviously violated.

    So I would not say the I2C Master imposes the slow SCL rise time, but rather the system with the 4k7 pull-up already exceeds or at least comes close to the edges of the requirements.

    Best regards

    Fabian

  • I (now) - must accept your explanation of the 'likely' inadequacy of the 4K7 pull-ups.

    That said - having been 'in this field' for awhile (and enjoying 'some' success) - your description, 'I2C signals - across multiple PCBs and multiple connectors' - 'Scares me mightily!'     It is understood 'WHY you've chosen such a (demanding for I2C path)' - yet such designs are at 'highly increased risk' - and may suffer 'accelerated' failure.     (that's been my firm's (repeated) findings - also that of (many) of our clients.)

    Under such, 'Multi-Board, and passage thru board interconnect' conditions - it is believed that strategically placed, 'I2C Bus Amplifiers/Repeaters' - and 'Quality Board to Board Inter-Connects' often 'Raise the Robustness' (as well as the performance) of such 'extended' I2C systems...   Some even drive 'higher currents' - somewhat regularly - through the board interconnects - to maintain the connector's conductive 'wetness.'    (Yet NOT while the board is 'UP & Fully/Operationally' Running!)       The temptation to run @ high 'I2C' data rates (always present) - should be resisted - as well.     

  • We do not require to run high data rates. The 100 kHz I2C mode is completely sufficient for our needs.
    We know of the problems of such a system, however a set of I2C Amplifiers is not an option due to a lack of space on the PCBs.

    We can pretty good deal with the system by reducing the Pull-Ups to 1k.

    I just need to understand that the suddenly pulled low SCL lane at the glitches comes from the MCU due to bad rise times, to accept this as solution. If there might be another reason for these glitches, we will have to dig further to into the system, as we cannot assume the 1k pull-ups will solve this issue.
  • The suggested,  'Use of (another) of the MCU's I2C channels'  (even one temporarily hacked)  which repeats this 'runted SCL resonse' - indeed likely proves an, 'Intended MCU response to a flawed 'signal's rise time!'     The 'replication of such an MCU behavior' - is often 'proof of intention' - which (appears) to be 'just what'  you are seeking...

    Perhaps - even more resourceful/inspired - RAISING the VALUE of the pull-up R - should 'exaggerate the arrival' of such 'Runted SCL signals!'     (if indeed - such SCL 'clamping' - is via design intent.)     STILL - the switch to a 2nd I2C Channel (temporarily) proves IDEAL.    (to 'really' confirm 'design intent.')      Nothing else - provides that degree of confirmation...

    Such may warrant your experimentation.     (only you - possess your unique system - thus can 'Test/Verify' - under those (highly) unique conditions...)

  • Hello Fabian,

    If the rising edge did not complete successfully in the right time frame, which from your image seems to be the case, then that is just a result of the TM4C master trying to get the communication corrected. The SCL line being pulled low like that when the master is responsible for the bus is in order to get the communication back onto a proper timing pattern.

    Possible causes for the failed rising edge include the pull-ups we were discussing.

    As reducing the pulldowns has solved the problem, it looks like that was the root cause. When testing also keep track of the capacitive load on the bus as well since that can also limit the size of your pullup resistors.
  • Ok cool thanks for the confirmation, that the master pulls the SCL low to reestablish proper timing.

    I have not seen any problems with the reduced pull-ups, so I assume that this was the only root cause and there are no other side effects.

    Thanks both of you for the extensive help on this topic

    best regards
    Fabian