AnsweredAssumed Answered

KL43 I2C problem

Question asked by Butcher on Dec 6, 2014
Latest reply on Nov 2, 2015 by Oscar Rozo

Hi All

 

I have a nasty feeling that the I2C in the KL43 could have a problem.

 

I have used the same interrupt driven driver on just about all KL and K devices but this one behaves differently.

Initilly I had the problem that the BUSY bit was set in the stauts register after performing a read of a number of bytes from a slave. So I let the interupt routine run a few times (with a break point) and it all looked OK and if I work like this the problem isn't always seen and the operation then runs (continuously reading blocks of data from the slave [without any pauses on the bus] forever - whereby repeated starts are used for following read all the time).

But generally it was behaving wierdly and the most bizzare thing that is seen is the following. To make it clear I can run the same driver code on a KL46 and a KL43 (50kHz I2C clock) and see this difference:

KL46:

- the slave address has just been sent and the first byte of slave data is to be read

- in order to start the read of the byte of data a dummy read is made of the data register, which then kicks off the I2C master sending 9 clocks

- the the next interrupt arrives, the data byte is read, which then kicks off the read of the next byte, and so on until all but one are read

- before the final read the ACK bit is cleared so that there is no ACK sent to the slave

- finally the stop condition is sent.

 

KL43:

- the slave address has just been sent and the first byte of slave data is to be read

- in order to start the read of the byte of data a dummy read is made of the data register, which then kicks off the I2C master sending 9 clocks (but the master doesn't send 9 clocks but instead sends 'continuous' clocks)*

-  the the next interrupt arrives, the data byte is read - here the master is still sending continuous clocks so the read is not controlling anything

- before the final read the ACK bit is cleared so that there is no ACK sent to the slave - because the master is sending clocks all the time the reading is not necessary synchronised (?)

- finally the stop condition is sent. When the bus blocks at busy I see that the master has sent an ACK to the last byte sent and there is no stop condition.

 

Comparing the user's manual for the KL43 and KL46 doesn't reveal any obvious major differences (KL43 has an additional status register) so I would expect the behaviour to be the same on both parts.

* The fact that the master sends continuous clocks is a major difference which suggest the root cause of the unreliability. This is very easy to reproduce since it just needs the debugger to break on the read of an available byte and the master will then be reading and ACKing each read for everever when the debugger is pausing the processor (the KL46 master will wait until the data register is read and then sends out the next 9 clocks as expected.

 

Is this an error in the I2C controller in this part or is there some new mode/behaviour that it defaults to?

 

Regards

 

Mark

 

P.S. There is a migration guide form the KL46 to the KL43 at http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4997.pdf?fasp=1&WT_TYPE=Application%20Notes&WT_VENDOR=F…

This explains that the new I2C can obtain faster speeds due to being double buffered.

It also states that there is no software impact when using the new I2C, which my tests with identical SW haven't been able to confirm..

Outcomes