AnsweredAssumed Answered

Kl17 I2C Slave using transactional API

Question asked by Doug Baker on Sep 27, 2017
Latest reply on Oct 12, 2017 by Doug Baker

We are using a KL17 as a slave using the high level Transactional API callback interface.  We are using the GNU compiler version 6.3.1.

 

The master is sending the KL17 two bytes of data and the KL17 is expected to respond with 3 bytes of data back to the master.  The KL17 is the salve, and we have another ARM CPU as the I2C master.  A scope with an I2C analyzer shows the 2 bytes the master sends always looks good but sometimes the KL17 does not receive the 2 bytes properly.  The Kl17 will sometimes ( say 1/100) will not receive the second byte [rx2]  properly in the callback.

 

The scope with an I2C bus analyzer will show: 

Note, the slave address is 50, S=Start, R=Repeat Start, E=Stop

S[50] [rx1] [rx2] R [51]  [tx1] [tx2] [tx3] E

 

 

Sudo code:

Callback

{

                Switch RX Event

                                xfer->data = (unsigned char*) &rxbuff[0]; 

                                xfer->dataSize = 2;

                break

 

                Switch TX Event

                                Check rx data here, this is where the incorrect data is seen [rx2].

                                xfer->data = (unsigned char*) &txbuff[0]; 

                                xfer->dataSize = 3;

                break

 

                Switch Complete Event

                break

}

 

The callback code flow is RX Event followed by a TX Event and finally the Complete Event.

 

Question 1: Is the expected sequence for a 2 byte I2C write followed by a three byte read?

 

Question 2: Would we ever expect to see the callback come back from the first 2 byte receive is it had not received the two bytes?

 

Question 3: what do we expect xfer->transferredCount to be each time we get the callback?

Outcomes