I am working on a circuit with a PIC mcu and an LCD display on a breadboard. The PIC communicates with the display via I2C. For some reason I can only get the communication to work properly when my o'scope probe is connected to the SDA line of the I2C interface. I know the communicate is working because the display shows my text. If I remove the probe and then restart the firmware the display stays blank. Any ideas what is happening here? I am using 4.7k pull-up resistors on both the data and clock lines of the I2C as recommended by the PIC manual. I also tried swapping the resistors out with 1k's and 10k's but that didn't seem to help. Also, it doesn't matter if the ground clip on my probe is connected to the PCB ground or not (so I don't think it's a grounding issue). Any ideas what is going on here? I know I should really get a real PCB made but I wanted to prove the design was good on the breadboard first.
You didn't say which PIC you are using, but there have been at least two confirmed bugs in the IIC mode of some of the MSSPs. One of them had something to do with sampling the ACK bit on the wrong edge of the clock. The bugs I know about were quite a while ago, so they have probably been fixed in newer PICs. Still, I tend to use all firmware implementation of IIC in master mode. You need the hardware to implement a slave, but in master mode you own the clock so it's easy.
The scope probe is adding a little capacitance to the SDA line, which slows down and delays the edges slightly. Something is probably not right in that there is a race condition in there somewhere. The slower or delayed edge of SDA is apparently making it work. Try putting a 22-47pF cap on the line and see if that appears to make it always work. I wouldn't want to ship it that way without knowning the cause and understanding that's a reliable fix though.
Another possibility is noise getting onto the line from other parts of the system. In that case the cap to ground is making the line a little lower impedance, which attenuates the noise a bit. If it's noise, then adding a cap to SCL will be fine. If there is a race condition somewhere, adding a cap to SCL will probably make it worse.
I've seen too many flaky things with IIC over the years so that now I use a firmware-only implementation whenever possible. In firmware I can guarantee that there are never two things happening on any one edge.
Each scope probe has some inherent capacitance to it. I2C has a specification for maximum allowable bus capacitance (400 pF). Adding the scope probe (& its capacitance to GND) to your trace may be causing your circuit to fall more closely within a "sweet spot" that the IC is looking for within the specified capacitance. Read the scope probe, most of them usually list their capacitance. Then, put a capacitor to GND of the same (as similar as possible) on the SDA line and power up your circuity without the probe connected, and see if that fixes it.
If you haven't got a good ground connection between the display and your microcontroller, the ground clip of the probe can give you a "good enough" ground to allow I2C to work.
I found that you cannot program a PIC using a PICkit 2 unless you connect the ground and Vdd to the chip (I was young!) but that when the scope ground was connected it provided a ground to the earth pin which connected to my laptop's earth pin, which went through a class-Y cap to join the PSU's ground to earth, connecting USB ground to earth. I found that even with this configuration I would often get programming errors, because it was a very noisy path. But it just about worked, much better than not at all.
I had a UART problem at cold temperature where the probe fixed it when it was touching the flow control line. Long story short - it was because the software wasn't setting the pin muxing properly where on a LOW it was basically a weak pull down. At low temperatures the leakage current gets lower so the weak pull down is more like an open. This is bad because the fall times will be impacted and also it could pick up all kinds of noise and cross talk. There's no way to se what's happening because the measurement instruments impacts the result. Adding a 1Mohm resistor helped pull the line LOW. You could try the same troubleshooting method by soldering a 1M to GND, and see if that fixes it, then check the pin muxing in the software.
What load is the scope/probe set for 1Mohm? 50ohm? make sure it is not on the low ohm setting.
Are you the i2c master or depndent? One way to debug it might be to sample the input and echo it out another i/o pin that you are not using, then probe that with the scope. The controller is not that fast but you can get an idea of what the processor core is actually seeing when it samples that input.