This relates to an earlier query (some months back) related to I2C transactions failing when the processor clock rate was slowed. As there was an easy workaround (don't run the clock so slow!), I had put it into the curio basket, but it has bugged me, and have finally had a bit of spare time to play with it and try and understand what is happening.
As a brief precis, I've been running a USCI based I2C at 100K, in master receiver mode, reading 3 bytes of data (2 bytes plus a PEC) from a sensor. This worked fine at higher clock rates (above 4MHz), but under this attempted to read an additional spurious byte. What follows is my understanding of what is happening.
The documentation states that the STP must be requested while the final byte is being read. In code terms, this means that the STP needs to be requested immediately the RXBUF for the penultimate byte is serviced. I had assumed that I had the time taken to read the final byte to play with - at 100K this should have given me around 80uS. This should have easily been adequate, particularly as nothing was happening between servicing the RXBUF for the penultimate byte, and requesting the STP. But I was still seeing the failures, even with some trivial test logic with the RXBUF read immediately followed by the STP. A play with a logic analyser, together with yet another read of the documentation has finally shed some light on this.
I had ignored that the USCI buffers the incoming bytes, and will continue to clock and read data while waiting for the previous RXBUF to be serviced. If the RXBUF is not serviced in time (which is what was occurring at the reduced clock rates), the USCI will eventually halt the I2C clock when it has buffered all but the last bit of the next byte. Once the RXBUF is read, it will immediately clock this last bit. What this means is that rather than the time taken to read a whole byte to get the STP in place (~80us), if the next byte is already fully buffered, the available window is only the time needed to read the final bit (around 8us). At low MSP clock rates (like 1MHz), there is simply not enough time to request the STP before the USCI completes reception of the current byte, and starts reading another, spurious byte.
Does this sound valid? I can't see any means of protecting from this, other than being very cautious with combinations of low MSP clock rates, and high I2C data rates.
Regards - Andrew