Using an oscilloscope makes my I²C-bus work.

[Mercator]

Hi,
I have a weird problem. I would like to measure the ambient temperature using an MCP9808 and a PIC 24FJ64GB004. Both are connected via an I²C Bus (Pins SDA2 and SCL2 on the PIC). I'm using MPLAB's Code Configurator for generating some driver code.

When I first tested the project, the I²C-Bus didn't work. So, I connected my oscilloscope to the SDA and SCL lines and suddenly it worked! Actually, quite reliably. So, it can't be the code. I know, I probably added some capacitance to the circuit by connecting the probes. But why does it work at all and how can I fix it? How can I troubleshoot it if the problem is gone as soon as the oscilloscope is connected? 

I attached a screenshot of the schematic and layout. There are two MCP9808 in two different packages, but only one will be placed (the MCP9808 is in short supply every now and again).

Thank you for your help!


 

 

[nctnico]

Are the pins on the PIC properly configured for I2C?

[tatus1969]

could you post some scope shots showing the traffic? maybe somedetail rising/falling edges. maybe try using slower speed for a test.

[rstofer]

I think I would have put the pull-up resistors at the far end of the bus relative to the uC.

[wraper]

Likely not a source of the problem but thermal pad of MCP9808 must be connected to GND according to the datasheet (may be according to other part of the datasheet  ).

[Ice-Tea]

Keep in mind that the probe represents a small capacitive load. So, you may try to put a 20pF cap to GND on both traces (without the probe) and see see what happens...

[wraper]

May also be, that what is affecting the operation is not necessarily probe capacitance but the fact you are connecting GND of the PCB to the mains earth through the scope.

[LA7SJA]

Read this http://ww1.microchip.com/downloads/en/DeviceDoc/70000195f.pdf

This doc suggest 2K2 pull-up and you should test:

bit 9 DISSLW: Disable Slew Rate Control bit
       1 = Slew rate control is disabled
       0 = Slew rate control is enabled

Johan-Fredrik

[Feynman]

May also be, that what is affecting the operation is not necessarily probe capacitance but the fact you are connecting GND of the PCB to the mains earth through the scope.

I would consider a grounding problem aswell.

I think it is very unlikely that the probe's capacitive load affects I²C operation. With a 10X-Probe the majority of the probe's capacitance is isolated with a 9MOhm resistor and I strongly doubt that the tip capacitance does any harm (or in this case good) to a I²C-Bus, that is not even near anything "high-speed" where such effects would matter.

Also 2k2 vs. 3k3 pull-up resistors should not make that much of a difference.

[tatus1969]

May also be, that what is affecting the operation is not necessarily probe capacitance but the fact you are connecting GND of the PCB to the mains earth through the scope.

I would consider a grounding problem aswell.

I think it is very unlikely that the probe's capacitive load affects I²C operation. With a 10X-Probe the majority of the probe's capacitance is isolated with a 9MOhm resistor and I strongly doubt that the tip capacitance does any harm (or in this case good) to a I²C-Bus, that is not even near anything "high-speed" where such effects would matter.

Also 2k2 vs. 3k3 pull-up resistors should not make that much of a difference.

There is always a capacitor in parallel with then 9M that is in the range of 10-15pF depending on the probe. Connecting it to one of the I2C signals will increase its rise time, and by this change the relative timing of the two. If timings are too tight (the reason why I asked to lower the I2C speed), this can make the difference.

[Ice-Tea]

... that is not even near anything "high-speed" where such effects would matter.

A 400kHz clock on a high speed input double clocks just as easily as a 400MHz clock.

[22swg]

When I first tested the project, the I²C-Bus didn't work.

I would suspect a bus collision on I2C start , how you configuring the I2C pins.?

[tatus1969]

... that is not even near anything "high-speed" where such effects would matter.

A 400kHz clock on a high speed input double clocks just as easily as a 400MHz clock.

I would agree to that when we would be talking about push-pull outputs, but this is open-drain with pull-up. Capacitances do matter here, even at such low speed.

[Mercator]

Wow. Thanks for all the answers. You are awsome! 

Are the pins on the PIC properly configured for I2C?

I think so. Used MPLAB Code Configurator (nice, simple GUI) for that. Since it works with the probes attached, the configuration should be fine. Attached some pictures of the configuration.

could you post some scope shots showing the traffic? maybe somedetail rising/falling edges. maybe try using slower speed for a test.

I tried 400kHz and 100 khz speed. I will post a scope picture shortly.

I think I would have put the pull-up resistors at the far end of the bus relative to the uC.

I'm not an electronics engineer. Can you explain to me why this might be better? Is it just good practice or absolutely vital?

Likely not a source of the problem but thermal pad of MCP9808 must be connected to GND according to the datasheet (may be according to other part of the datasheet  ).

Yes, I noticed when I got the PCB's made. Forgot to do it. Stupid me. 
I will keep that in mind for the next revision. However, the datasheet says
"There is an internal electrical connection between the Exposed Thermal Pad (EP) and the GND pin. The EP may be connected to the system ground on the Printed Circuit Board (PCB).". So it's not a must. As I understood it, its only to reduce the effects caused by self heating.

Keep in mind that the probe represents a small capacitive load. So, you may try to put a 20pF cap to GND on both traces (without the probe) and see see what happens...

Yes, but typically the I²C-Bus doesn't require adding capacitance. There is even a maximum of 400pF.

May also be, that what is affecting the operation is not necessarily probe capacitance but the fact you are connecting GND of the PCB to the mains earth through the scope.

There is an extra USB-port on the board. I used it as a serial interface to get a temperature reading. So it should be connected to mains earth through the computer, right (used a desktop PC)?

Read this http://ww1.microchip.com/downloads/en/DeviceDoc/70000195f.pdf

This doc suggest 2K2 pull-up and you should test:

bit 9 DISSLW: Disable Slew Rate Control bit
       1 = Slew rate control is disabled
       0 = Slew rate control is enabled

Johan-Fredrik

Good idea, tried it with a 100khz speed, with DISSLW enabled and disabled. No change. Doesn't work. The doc doesn't say anything about 2.2k. It just gives you some rough formulas. In fact, I²C should work with anything between 2.2k and 4.7k.

When I first tested the project, the I²C-Bus didn't work.

I would suspect a bus collision on I2C start , how you configuring the I2C pins.?

There's only one device on the bus. So there shouldn't be any collisions. The bus is configured as shown in the screenshots attached.

... that is not even near anything "high-speed" where such effects would matter.

A 400kHz clock on a high speed input double clocks just as easily as a 400MHz clock.

I would agree to that when we would be talking about push-pull outputs, but this is open-drain with pull-up. Capacitances do matter here, even at such low speed.

Yes, but shouldn't the circuit fail rather than work by adding capacitance through the scope? I will post a scope image shortly.

[pix3l]

Hi Mercator,

As you can see on page 4 of this document: http://ww1.microchip.com/downloads/en/DeviceDoc/70000195f.pdf , pull up resistors of 2k2 are recommended. And they are quite vital to the working of an I2C bus...

[22swg]

Hi Mercator, Not used CC but been using I2C and PIC24 ( all flavours ) for some time, so I have a set up that works . (a) H/W 2k2 pullup  (at final end device if possible but not essential ) keep I2C wire as short as practicable ( b) S/W , Bus collision can occur even with one slave device . ( I'm guessing here >) as the PIC enables  I2C it needs to 'see' both clock and data high, if not collision bit set, and nothing works, So I  TRISxx=0  the clock and data I/O pins as outputs , then make them high LATxx=1, then back to inputs and immediately enable I2C, seems to work especially if you have some high MIPS going on ...

[Mercator]

Scope pictures, anyone? 

First, if I just poke the pads of the unused MCP9808 footprint, I just get a high level on both lines. There seems to be no activity.

If I solder on some fine copper leads and attach the scope probes to those, it works. I stiched together I wide screen image of the complete communication. Channel 1 (yellow) is the SDA line, Channel 2 (blue) is the SCL line.

Communication starts with the start condition, followed by the address of the MCP9808 (0b0011000), the write-bit (0) and an Acknowledge bit. Then, the µC selects the ambient temperature register (0b00000101). Then, there is a short period of silence on the bus and then the µC starts again with the address of MCP9808. This time with a read-bit (1), followed by an acknowledge bit, the MSB-data of the ambient temperature register, another acknowledge and the LSB-Data with the stop condition at the end.

[Mercator]

Hi Mercator, Not used CC but been using I2C and PIC24 ( all flavours ) for some time, so I have a set up that works . (a) H/W 2k2 pullup  (at final end device if possible but not essential ) keep I2C wire as short as practicable ( b) S/W , Bus collision can occur even with one slave device . ( I'm guessing here >) as the PIC enables  I2C it needs to 'see' both clock and data high, if not collision bit set, and nothing works, So I  TRISxx=0  the clock and data I/O pins as outputs , then make them high LATxx=1, then back to inputs and immediately enable I2C, seems to work especially if you have some high MIPS going on ...

Just soldered in two 4.7k resistors in parallel to the 3.3k pullups. Making it an effective 1.9k which is as close to 2.2k as I can get right now. Still nothing.
Then, I selected "Start High" in the pin manager of MCC to mimic what you did. And it works! 
Just to make sure, I desoldered the 4.7k resistors. It stopped working.
So, I soldered them back in and it works again!

So, in summary: The SDA and SCL pins have to be configured to start high and the pullup resistors should be around 2.2k.

Thanks a lot to all of you guys! 

[tatus1969]

Scope pictures, anyone? 

First, if I just poke the pads of the unused MCP9808 footprint, I just get a high level on both lines. There seems to be no activity.

If I solder on some fine copper leads and attach the scope probes to those, it works. I stiched together I wide screen image of the complete communication. Channel 1 (yellow) is the SDA line, Channel 2 (blue) is the SCL line.

Communication starts with the start condition, followed by the address of the MCP9808 (0b0011000), the write-bit (0) and an Acknowledge bit. Then, the µC selects the ambient temperature register (0b00000101). Then, there is a short period of silence on the bus and then the µC starts again with the address of MCP9808. This time with a read-bit (1), followed by an acknowledge bit, the MSB-data of the ambient temperature register, another acknowledge and the LSB-Data with the stop condition at the end.

I checked the signals carefully, cant't find anything that is even close to critical. Looks like a perfect noise-free I2C comms. Also the rise time is well within limits. You should not need to reduce the pull-up resistors to make it working. The microcontroller's I/Os are definitely in open drain configuration.

Is that a picture of the exact situation that fails when you disconnect the probe?

Is the I2C implementation that you use pure software based bit banging? It looks like that. Maybe there is a hidden error in the implementation, for example sampling the slaves ACK at the wrong moment in time. It must be sampled by the master *after* the rising clock edge.

Although it seems to work now, I wouldn't find this fix trustworthy. You didn't tell in detail how you diagnosed the not working I2C. Was that a return value from the library, possibly indicating slave NACK? Another idea: solder 47k resistors to each of the I2C signals, and attach your 1:10 probe to these. This will bandwidth-limit your signal on the scope, but for 100kHz it should still be enough and it will eliminate the capacitive loading that causes the I2C to miraculously work (not enough for 400kHz!).

[tatus1969]

First, if I just poke the pads of the unused MCP9808 footprint, I just get a high level on both lines. There seems to be no activity.

Huh?? Is it possible that we are chasing a soldering problem??? I would grab a magnifying glass now...

[22swg]

Is the I2C implementation that you use pure software based bit banging? It looks like that.

Tatus.... The OP used MPLAB Code Configurator  ?

[nctnico]

First, if I just poke the pads of the unused MCP9808 footprint, I just get a high level on both lines. There seems to be no activity.

Huh?? Is it possible that we are chasing a soldering problem??? I would grab a magnifying glass now...

You might be on to something here! Redoing the solder joints with some flux is never a bad idea in case of weird problems.

[tatus1969]

Is the I2C implementation that you use pure software based bit banging? It looks like that.

Tatus.... The OP used MPLAB Code Configurator  ?

When you could look into my brain and open up the Microchip page, then you would only read "this page intentionally left blank"