Helpful I2C Observations

Discussion created by geoffreyfurman on Oct 13, 2012
Latest reply on Oct 17, 2012 by geoffreyfurman

I just fixed an i2c bug in our system and thought I would post my observations.

Observation 1

The datasheet for the JM60 says the only sources of I2C interrupts are:


TCF Transfer complete flag

ARBL Arbitration lost

IASS Addressed as slave


We had an I2C master entering the ISR with NONE of these bits set.

Upon inpsection we found that MST was 0 indicating that the master was no longer the master for an unspecified reason.


Observation 2

The problem was caused by an I2C timing violation, SCL and SDA rising simultaneously, which was occasionally interpreted as a STOP condition.

The timing violation was generated by the master during a read cycle when the bus turn around occurred.

My code was originally:


IICC1_TX = 0;     //Place the bus in master receiver mode

dummy = IICD;    //Release the bus to perform the read cycle

With this code a condition on the bus can occur where SDA and SCL rise together which is not allowed on the I2C bus.

Granted that SDA nominally leads SCL by the time of the instruction but on the slow rising I2C bus confusion can occur.


I modified it as such:


IIC1_TX = 0;

__asm NOP;

__asm NOP;

__asm NOP;

__asm NOP;

dummy = IICD;


When you do this you will see on the oscope that SDA clear rises in advance of SCL preventing the timing violation.

The number of NOPs may be dependent on how soft the pullups are.  I chose a number that was clearly resolvable on the oscope.