I2C Clock signal - pulses of clock occasionally are short - see scope screenshot

You are not telling which Slave you are using. Holding the Clock Low is done in most cases by the Slave and sometimes by a second Master. This is named ‘Clock Stretching’ and his purpose is to slow down the bus in case the slave needs more time to process the signal/data.

I don’t know why you think the Slave is Not Acknowledging the data, but if SDA is the purple line then you can see on each 9th clock SDA is Low -> ACK.
On the other hand, if your scope picture reflects the real bus signal and your I2C module doesn’t read the Acknowledge bit well, then improve your bus signal while on the scope picture it looks very bad.

Hello all - and particularly Leo, thanks for taking the time to respond.  

I'm using an Omnivision Camera as the slave.   This communication sequence is the Camera initialization (setting various registers).  

I had the benefit of "zoom" on my scope and when you zoom in, it is clear that the 9th clock pulse is "high" on the SDA line -> NACK.   I have attached a new pic, zoomed in with the pulses labeled in hopes it will be more clear.

You mentioned improving the signal...  Do you have any ideas on improving the bus signal?   I replaced my TI Launchpad with an Arduino and I do see improvement in the signal on the scope.  Perhaps someone from TI can comment?   Do I have a "bad" Launchpad?   I attached an Arduino pic below the zoomed in TI pic for reference. 

If it is clock stretching between the 5th and 6th clock pulses, then (since the Camera induces the stretch) shouldn't it also occur with the Arduino?   I ran the Arduino/Camera setup multiple times at various speeds as well, but did not see the problem.    Also, shouldn't the TI handle the stretch and then have a full pulse when the slave releases the CLK line?   I haven't had to deal with a clock stretching problem before...  so I may not have the TI set properly.   Looking at the Tech Ref Manual for the CC3200, it doesn't appear that I have to set a bit to "turn on" clock stretching, is this correct?   But... I should be able to check if I'm getting a Clock Low Timeout interrupt, right?   And then possibly extend the Clock Low Timeout Count register to resolve the issue.

This is the zoomed in pic of the TI signal... with the 9th pulse boxed in red.   You see the NACK below on the purple/pink trace.  After the NACK, the master pulls the pink/purple line low again in order to do a "stop" on the I2C lines.

This is the Arduino trace...  You can see a brief "blip" where the pink/purple line pops up between the 8th and 9th pulse before the Camera slave device pulls it low to ACK.  

Clock Stretching is NOT generated by the Master but normally done by the Slave after the ACK-bit or by a 2^nd Master during Arbitration with each address CLK, this to Hold (Pause) the Master.

The Outputs (SDA & SCL) from a I2C device are ‘Open-Collector/Drain’ which means they need to be ‘Pulled-Up’ externally from the device by a resistor.

An EVM can have these pull-up resistors but are mostly weak and only be meant to be used for ‘On-Board’ I2C devices. When going Off-Board with the I2C signals the pull-up resistors needs to be re-calculated and added to the bus.

A slow rising of the signals and/or a floating high level (not saturated to bus-Vcc) indicates a too capacitive bus and pull-up resistors needs to be changed/added. The total pull-up resistance is normally in the range of 10 KOhm till 1 KOhm, but 330 Ohm is also possible.

Undershoots mostly indicates a long, inductive, bus wire. Add series resistors in the bus-signal lines, in the range of 100 Om till 1 KOhm, to eliminate this.

Noise in the signals can be caused by a bad ground connection and/or cross-talk from other signals.

I didn’t look to you address of 0x21, just counts the clock’s. The short clock, your 6^th, isn’t valid and should be ignored by an I2C device. Then counting the last rising-clock is the 9^th and SDA is Low, followed by an SDA rising = Stop. But this doesn’t match your address value. The signal is too bad to discus.

Your Arduino signals are much better, the board will have stronger pull-up resistors.

 

Yes - Clock Stretching is not generated by the Master.   This is understood.  The Camera is the Slave in my scenario.   Single master system.

The TI Launchpad has 3.3K pull up resistors.    The Arduino Mega has 10K pull up resistors.   Both are within Leo's suggested range of acceptable.   The wires I'm using to attach my camera to the TI are very short.   While the signal is noisy at the top and bottom, it certainly isn't slow rising.  This is not a long wire problem.

I still have the same main question - and Leo restated it above.

The short clock, the 6th in a previous picture isn't valid.    The Camera (slave) ignores it as I would expect.    The TI does NOT ignore it - and includes it in it's count of 9 clock pulses. 

We know that the TI is counting pulse 6 as "good" for two reasons.   First, The address transferred on the SDA line (0x21 with a write bit) only fits the clock pulses if pulse 6 is included.  

Assume for a moment that the TI DID ignore that 6th pulse...  then the address it would be sending would be 0x22 with a read bit which is totally out of line with my code.  As I mentioned in my initial posting... this problem is repeatable... but intermittent.   The TI successfully communicates with the camera most of the time.  The code is commanding a write to the correct address.  

The second reason we know that the TI is counting pulse 6 as "good" is...  If it did not include it, there would be an additional pulse in the trace.  The NXP specs for I2C lists the 9th clock pulse as a PULSE... not simply a rising edge.   

This is the main question in my mind.   Why does the TI module think this pulse is "good"?    Regardless of whether the signal is noisy at the top and bottom due to a resistance issue... the pulse in question is far to short in duration to be anything but "bad".

I would appreciate a comment from TI.     To simplify things for anyone trying to read this... I copied the trace I've referenced from a previous post into this post too.   Thanks!!

What happens with your 6^th pulse I don’t know, but as I already told you need first to improve your bus-signals. Your rise-time is out of limits.

How does the bus signals looks if you are using only the two onboard devices.

If you disable the on-board devices and add new pull-up resistors and have only 1 slave device how does your signals looks in this case.

First, We updated the 3.3K resistors on the original Launchpad with 10K resistors.   There was no noise change - which will be shown in some pics below.  

I also did some more searching within the TI site and found an interesting thread.   They don't mention any strange signal behavior captured via scope, but they discuss getting "stuck" in the I2CTransact library function at a particular function call.   That's the same position my code get "stuck" in when there is a short pulse during the 2nd or 3rd byte transmitted by the TI.   Here is the address of that thread:     e2e.ti.com/support/wireless_connectivity/f/968/t/373854     I posted to that thread asking if anyone had put a scope on their lines - but I have not seen a response yet.   The thread is very old, without resolution from TI.

I ran a few tests on my current Launchpad and then a second Launchpad for comparison.

I first tested the 2 Launchpads without any additional slave modules - only the two present on the board.    Both tests showed very little noise in the signal, but interestingly, the original launchpad SCL signal never made it above 2.3V.     Since V input is 3.3, "high" on the I2C lines is 2.3 and "low" is 1V.    The 2nd launchpad had a signal that looked much better.   Here are the pics...   The dashed line is the Y cursor on scope showing 2.3 volts.

Original:

2nd Launchpad (with 3.3k resistors) - rise time is measured as 180ns

So I think there is a problem with my original Launchpad, but I don't see how this particular issue causes the problem of the short pulses.  (this problem shows up on both Launchpads as will be shown below).

I added a second accelerometer - just as an experiment to see if another slave attached via wires causes noise.   These traces were the same as the traces without any non-Launchpad I2C slaves.   Very little - if any - noise.   So, additional wiring is not causing the noise.   I'm not going to post pics since they don't show anything more interesting that what is shown in the top pics.

Then I added the camera module.   Both Lauchpads showed increased noise when compared with the first two tests.  The 10K resistors on the original Launchpad maybe helped a tiny bit, but it didn't make a huge difference.    Below are the two pictures. 

This is the 2nd Launchpad (3.3K resistors)  Notice the circled area in the picture.   You can see that the SDA signal gets "super noisy" when the Camera module is actually pulling the signal down to ACK.  

Here is a shot of the 1st launchpad with 10k resistors.

Pic of 2nd Launchpad showing the bad pulse is still present.  X cursors are added to show the SCL period - 384kHz.   Also note that there is no "super noisy" areas around the bad pulse - which indicates that the Camera module is not pulling the lines down - this address is NACK by the Camera.

Last pic - the period of the "bad" pulse is measured at 588kHz.  

It is true that the signal is noisier with the Camera slave board attached.   We have a second board that we will wire up and see if the original camera dev board is causing the noise.   But - why would noise cause the TI module to cut the signal off early on these pulses?    

I did get "stuck" in I2CTransact with the 2nd module when I hooked it up with only the Launchpad I2C slaves (no additional wiring) - but unfortunately I didn't capture it on my scope.

i have a similar problem here, i use a cc3200 launchpad to talk to a mpu6050 via the i2c interface, sometime my logic analyzer could only get 8 clock pulses, then the cc3200's i2c interface enters the error state. 

This is good input.

As I read it;
Board 1; 10K pull-up. Two on-board slaves. Long rise-time. Picture with too low high-level. No noise.
Board 2; 3K3 pull-up. Two on-board slaves. 180nS rise-time (as I remember good for 400KHz). Picture with not fully saturation of high-level. No noise.

Both boars shows strong capacitive behavior (look after STOP), check the capacitance of your scope probe, use a 1:10 probe. Use/add pull-up’s of 1K. The signal pulses must saturate at Vcc.
You can also check the signal from only the cc3200, remove both jumpers and add two 10K pull-ups.

Adding the camera adds noise. The noise from the camera can’t be eliminated by the altering the pull-up resistors value but only on the camera chip/board. Verify that Vcc is properly decoupled to Vss, add 10-22nF + 100nF ceramic capacitors directly on top of the noise source, the chip legs or immediately next to them, not through any plane.
Realize that your scope will not be able to show the full noise, there will be much more of higher frequency and voltage.
10mm of connection wire is about 1uH inductor, this can result in some voltage across your GND wire, this voltage is added to the I2C signals.

You can’t use a logic analyzer to analyze your signal quality. You need Anne’s method/setup.