PIC24 I2C slave sometimes setting first data bit high?

[allenhuffman]

We have some well-tested I2C code that has been in use for years, but while trying something new, I observed something:

My Master program tries to read a few bytes from a PIC24 Slave device. Normally, we respond with a 0xAA (10101010) byte as a start code, followed by the rest of a header and then any data plus a checksum at the end.

Using a Saleae Logic Analyzer, and having the PIC24 return "0x01" for the first byte, shows this most of the time:


Good:

I see the correct clock pulses, and the Master writes out the address with the read bit set (0x65 in this case).

I then see the data line drop LOW until the next set of clock pulses to read the 0x01.

Bad:

I see the correct clock pulses, and the Master writes out the address with the read bit set (0x64).

I then see the data line remain HIGH. When the next set of clock pulses happen, it is still high and is seen as a "1" bit, then it drops and gets the "1" at the end, representing 0x81.

The PIC code is being done in an ISR, and I am manually clearing the IRQ so I can check for the P stop bit or IRQ for next incoming byte in my routine.

The code that is running in the ISR for this case ("first read") is basically this:

[Ttelmah]

I suspect that is caused by erratum 38.
The TBF bit is set, so the peripheral thinks it already has a byte to send,
which just happens to be 0xFF. Suggests some slight timing issue on the
bus is causing this error.

[allenhuffman]

[allenhuffman]

As a workaround, I did a few tests. I found that if I just read one extra byte than what I really am expecting, the problem goes away.

The only thing special my code is doing is making a decision whether to write a byte from a transmit buffer, OR send a hard-coded "you read when I was not expecting it". That shouldn't have changed anything, unless that timing was enough to change the outcome.

Then I just tried enabling clock stretching on the address read, and that also made the problem seem to go away:

[Ttelmah]

That makes total sense.
What is happening, is that without the stretch, the master is intermittently
starting it's read _before_ the byte has been loaded. The clock must be
held till the byte is loaded.