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.
Hi,
I know this topic has already been discussed in a few topics (e2e.ti.com/.../569566
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
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 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...
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.
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...)