[SOLVED] PIC18F26K83 I2C slave problem

[Ttelmah]

On the CSTR thing, I mentioned this here a while ago.
On a few chips, this won't clear immediately after the data is read. There
has to be a tiny delay. I think it is listed in one erratum, but seems to
actually apply to quite a few chips that don't list is as an errata.
Therefore I recommended that if you had problems, try clearing this.

There is also one other bit that may need handling. GCEN. If this is enabled
you will get an interrupt if a general call occurs on the bus, and the
standard handler will not know what to do in this event.

[jaka]

FYI, with latest beta version of PCH, 5.124P the I2C peripheral on K83 is again very easy to lock up with SCL low. For example if you try to read data with too high I2C clock rate.

This might be because of mismatched libraries and pch.dll. I got only the .dll from CCS but my other files are still version 5.116, the latest version my previous maintenance supported.

Now when it locks up with SCL low, clearing CSTR or re-initializing the I2C peripheral won't help.

I won't be debugging this further now, I will be staying at older compiler version which has been proven to work in the field for years. I can work around the other problems which were fixed to 5.124P.

To complete the post, earlier in this thread I mentioned that timeout checking for SDA was not needed. But later we found out that it is. The I2C peripheral can still sometimes lock up with SDA low, if there is something unusual happening on the bus. For example, some device on the bus loses power for a while, causing load on the bus. The SDA low timeout code snipped in my earlier post in this thread allows to recover from such events.

It seems Microchip has made the I2C peripheral much too complicated to be used reliably. The old MSSP was better, although that had it's problems too.