AnsweredAssumed Answered

I2C hardware sending an extra 8 clocks (byte?) at end of READ.

Question asked by rick stuart on Mar 9, 2017
Latest reply on Mar 13, 2017 by Mark Butcher

We have noticed that our KL03 is sending an extra 8 clocks (one byte?) at the end of our I2C reads.  We expected to see a START, EEPROM-ADDRESS-WRITE, EEPROM-REGISTER-ADDRESS, RE-START, EEPROM-ADDRESS-READ, DATA-NAK & STOP.  But what we actually see is an extra 8 clocks after the DATA-NAK.  I think the EEPROM is fine with this as it always sends 0xff because it recognized the NAK given out by the KL03 after the previous DATA given out by the EEPROM.  But we would like to keep all our I2C transactions as short as possible.  Our code looks like this:

 

I2C0_C1 |= I2C_C1_TX_MASK;
IIC_Start();
IIC_CycleWrite((SlaveAddress | (0x03 & (Reg >> 8))) * 2);
IIC_CycleWrite((uint8_t)(0x00ff & Reg));
IIC_RepeatStart();
IIC_CycleWrite(((SlaveAddress | (0x03 & (Reg >> 8))) * 2 ) + 1);
IIC_CycleRead(0,&res); // Dummy read
IIC_CycleRead(1,&res);
IIC_Stop();

 

Where passing 0 as the 1st parameter to IIC_CycleRead causes an ACK and passing a 1 causes a NAK.  The 1st res is written over as it is a dummy read.

 

Now, if we move the call to stop to before the call to read we see on the scope that the 8 extra clocks are gone!  This does not sound correct.  To send a STOP before the final byte is READ:

 

I2C0_C1 |= I2C_C1_TX_MASK;
IIC_Start();
IIC_CycleWrite((SlaveAddress | (0x03 & (Reg >> 8))) * 2);
IIC_CycleWrite((uint8_t)(0x00ff & Reg));
IIC_RepeatStart();
IIC_CycleWrite(((SlaveAddress | (0x03 & (Reg >> 8))) * 2 ) + 1);
IIC_CycleRead(0,&res); // Dummy read
IIC_Stop();

IIC_CycleRead(1,&res);

 

Is this actually the correct way to handle I2C?

 

-thanks

Outcomes