# PIC32 I2C not operating as expected

I'm having a problem getting I2C running with a PIC32MX795F512L. It was not acknowledging the address byte being sent out, so I put a logic analyzer on SDA and SCL and got the trace shown below:

The two excursions on the SCL line are the only ones that occur. So I don't understand why there are only two, instead of one per bit plus the start and stop conditions. This is obviously why I never see any acknowledgment.

Also, SCL is low all of the time before these sequence starts, and I expected it to be high and then go low with SDA high to indicate a start condition. I have checked that I have pullups on both SCL and SDA.

The code I am using is straight out of Microchip's I2C example code. Here is the relevant part:

   // Start the transfer to write data to the EEPROM
if( !StartTransfer(FALSE) )
{
while(1);
}

// Transmit all data
Index = 0;
while( Success && (Index < DataSz) )
{
// Transmit a byte
if (TransmitOneByte(i2cData[Index]))
{
// Advance to the next byte
Index++;

// Verify that the byte was acknowledged
if(!I2CByteWasAcknowledged(EEPROM_I2C_BUS))
{
DBPRINTF("Error: Sent byte was not acknowledged\n");
Success = FALSE;
}
else
{
Success = TRUE;
}
}
else
{
Success = FALSE;
}
}

// End the transfer (hang here if an error occured)
StopTransfer();
if(!Success)
{
while(1);
}


It gets to the I2CByteWasAcknowledged call and fails. Anyone have any pointers on getting I2C on a PIC32 to work with the Peripheral Library code?

• Any chance you could watch the clock/data lines with a oscope? – W5VO Sep 20 '12 at 1:40
• Yeah, it looks like those two glitches on SCL are simply crosstalk from the rising edges on SDA. – Dave Tweed Sep 20 '12 at 1:44
• Check the pullup resistor on the SCL line. – Turbo J Sep 20 '12 at 8:55
• @DaveTweed If you expand out the pulses on the SCL line, they are very uniform in width and last several microseconds, so I am pretty sure they are not crosstalk. – tcrosley Sep 20 '12 at 18:01
• @TurboJ I had 4.99K pullups on both the SCL and SDA lines; I have also tried 2.2K with the same results. – tcrosley Sep 20 '12 at 18:02

The problem turned out to be a bad connector on the logic analyzer. It is a 34-channel LA, but we tended to use just the first few channels over and over. Apparently the female jack for the SCL line, which accepts a pin like those on 0.1" headers, had become flaky. I should have realized it was something to do with the LA when I got the same results with the Bit Whacker.

I looked at the signals with a scope, and both the SCL and SDA were high when idle, and when low with the start protocol.

I picked a different set of channels on the LA, reconfigured the I2C interpreter to use those instead of the first two channels, and got a nicely interpreted I2C protocol.

As you mention, the SCL and SDA lines should idle high, so there is definitely something fundamentally wrong with the SCL. As a commenter said, there also seems to be cross talk occurring since the SDA going high causes the SCL to glitch.

• Are you sure the SCL line you've wired up is the one it should be?
• Verify you are using the right I2C interface on the pic (I2C1 vs I2C2 etc)
• Please verify you're calling I2CSetFrequency and I2CEnable (and with the right interface)