2
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Just in case - you have decoupling caps right on your VCC/GND pins in all recommended by datasheet locations? Ignoring that causes all sorts of random issues. \$\endgroup\$ – BarsMonster Jun 20 '11 at 15:19
  • \$\begingroup\$ Yes, I do have the recommended decoupling caps. \$\endgroup\$ – PICyourBrain Jun 20 '11 at 15:21
  • 1
    \$\begingroup\$ I had something like this happen where I was working in the arduino environment. I had not configured the pin for output but I was trying to use it as such. So when I wrote HIGH to it the internal pullups were activated allowing a small amount of current to flow. It wasn't enough for my application to work but when I attached the scope it worked. I was puzzled for awhile until I noticed the lack of an output command. I'm not sure if this relates to your problem but the symptoms were so similar I thought I'd mention it for smarter people to mull over. \$\endgroup\$ – NickHalden Jun 20 '11 at 18:14
6
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ it is a maximum capacitance, not a required capacitance. \$\endgroup\$ – Kortuk Jun 20 '11 at 16:53
  • \$\begingroup\$ @Kortuk - I wasn't trying to insinuate that I2C has a required capacitance & even said maximum capacitance in my answer. For interconnecting different types of ICs I've seen some finicky things in the past when working with I2C. I thought that if the scope probe changed things, the only thing it could be providing was a capacitance to GND. \$\endgroup\$ – Joel B Jun 20 '11 at 18:08
  • \$\begingroup\$ do not get me wrong, I just wanted to make sure that people knew the distinction. I agree that the capacitance to ground is all it is doing. \$\endgroup\$ – Kortuk Jun 20 '11 at 18:56
  • \$\begingroup\$ @Kortuk - Providing distinction as a good moderator should. Thanks! \$\endgroup\$ – Joel B Jun 20 '11 at 20:26
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ PICyourBrain says he doesn't even have to connect the ground clip of the probe. (Which left me puzzled) \$\endgroup\$ – stevenvh Jun 20 '11 at 16:18
  • \$\begingroup\$ @stevenh Ah, didn't see that. In which case, make that two puzzled. \$\endgroup\$ – Thomas O Jun 20 '11 at 16:24
0
\$\begingroup\$

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 slave? 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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.