Catching i2c glitches noise double clocking on a scope - Page 1
Forum section: electronics / projects

author: phatroug
author_rank: Newbie
timestamp: June 11, 2022, 06:17:30 pm
content: I can run a multi node i2c communication bus @ 100khz for hours with no errors. Once in a blue moon I suspect i am getting a pulse of noise that couples onto the data line or clock line and double clocks or makes a corrupted start stop condition. I have a total phase analyzer which i can see a corrupted transaction when the event occurs. I also have a saleae that catches the glitch with pulse width of 25 ns in the data line when the corrupted packet occurs. The data in this transaction gets shifted and the software analyzer in saleae and total phase gets confused.Problem is , its random and I need to determine how often the gitch is occuring and get a better hold on it. My current scope method captures a bunch of data and stops it from triggering again when a upper level software apps catches a crc error.Any ideas / recommendations of methods for capturing noise with a scope for further analysis with an i2c bus?Maybe probe the data line and trigger on pos and neg pulses less then 1uS?Thanks

author: Siwastaja
author_rank: Super Contributor
timestamp: June 11, 2022, 06:35:23 pm
content: You need to approach it from the different perspective.It's EMC/EMI issue. Either an extremely serious emission issue in some unrelated device; or immunity issue in your device. 99.9% likely the latter; the idea of EMC rules is to leave a lot of margin so that even if some device exceeded legal emission levels, even significantly, other devices still have immunity.Emission can be from anywhere, say, neighbor's fridge's mechanical thermostat clicking. Or your own device badly self-interacting!Now you are chasing the rare occurrence of this mystical emission. It's going to be hard. Instead, you should be trying to replicate/mimic the kind of emission that reproduces the issue at your will. It can be as easy as switching on/off your soldering station from the mains power switch, discharging a capacitor into a loop of wire, whatever. Once you have that, you can test the signal integrity.At the same time, you should be looking at the design itself. Why is it susceptible? Do you have good contiguous ground plane under the I2C lines? How long are the traces? Is it going in a cable? Is power supply bypassing OK? Maybe add filtering, or consider something more robust than I2C if it is off-board?

author: RoGeorge
author_rank: Super Contributor
timestamp: June 11, 2022, 06:56:29 pm
content: Digital oscilloscopes can trigger on a pulse length criteria. Set the oscilloscope on maximum number of samples, set the trigger condition on pulse length, and the trigger mode to "Single", so it won't trigger or auto-trigger again. Once you capture the event, use SCPI commands or save locally the captured memory for further analysis.If you do that to a remote compute (by SCPI) you can automatically restart the "Single" trigger mode so to save a collection of many failure events, in the hope to see some pattern for the failure.You didn't specify, what oscilloscope do you have? The exact method to capture the failure depends from one oscilloscope to another, or it might not be possible at all. A picture with the digital capture of an error from the Saleae might also help.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 11, 2022, 07:26:29 pm
content: 25ns glitches do not really exist on an I2C bus by itself due to the passive pullup resistors and rate limited open drain sinks, so it's indeed likely that the signals are coupled in from some external source.What sort of wiring do you have on your I2C signals? Is it on a PCB (and with a GND plane?) or are you one of those folks who think you can run I2C reliably through a few meters of wiring?Common high noise sources are:* Fluorescent lighting* Iron core transformers with manual switches.* Universal motors with defective noise suppression (hand held drills, vacuum cleaners, kitchen appliances, etc).Maybe you can write a simple uC program that detects when data gets corrupted, and then creates some visible or audible signal. This can aid in hunting down noise sources. If you hear the thing when you go make coffee then you're close to the culpritAnd it works both ways.You can increase noise immunity of your circuit by better shielding, pcb layout, etc.You can use a known noise source to test noise immunity of your circuit.

author: iMo
author_rank: Super Contributor
timestamp: June 11, 2022, 07:52:12 pm
content: Try to put a small capacitors on the i2c bus (against gnd), like 100pF or something like that..What are your pullups values like, btw?Crazy idea, but it may help.. With 100kHz clock a couple of pF cannot hurt, and it can clean the 25ns glitch up..

author: exmadscientist
author_rank: Frequent Contributor
timestamp: June 11, 2022, 08:28:27 pm
content: Quote from: Doctorandus_P on June 11, 2022, 07:26:29 pmIt is possible if the chip itself is designed wrongly.TI has a few C2000 parts like this:Quote from: The poor guy cleaning up after TI's 65nm CMOS design teamThe ridiculous part is that this chip's successor, having all new 65nm masks cut and the issue identified for years, has the same stupid error. Way to go, guys? (I mean, I guess it's probably a standard cell issue, but... come on. This does not make you look good, TI.) Oh, and that's version I of the document (SPRZ422I). Version H, which seems to have disappeared from the web but which I still have a copy of somewhere, has a slightly different suggested fix... so why the change? Not! Encouraging!Anyway. Back to the issue at hand.

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 11, 2022, 08:47:09 pm
content: Quote from: exmadscientist on June 11, 2022, 08:28:27 pmSome I2C chips pull the lines high for a very short time on a low to high transition to overcome bus capacitance and allow the use of higher value pullup resistors.