Not getting proper acknowledgement and stop condition on I2C bus
TL;DR - Some or all of the problem(s) are in your code.

You didn't supply the relevant code, but the two problems that I see in that scope trace, are both code-related:


As DoxyLover pointed out, the trace clearly shows an intermediate voltage, caused by conflict between two devices driving that SDA signal in opposite directions for the I²C ACK cycle. Since the I²C slave is driving that signal low (as an ACK), then your Kinetis K60 MCU must be driving it high at the same time!

As with many MCUs, when the internal I²C module is connected to actual external pins (e.g. via the internal pin multiplexer), those two pins must also be set to "open-drain" mode as a separate step in the configuration.

In the NXP Reference Manual which I believe includes your specific K60 MCU (20MB pdf file), page 282 (section 11.6.1 Pin control) says:


  For example, if an I²C function is enabled on a pin, that does not override the pullup or open drain configuration for that pin.


In other words, enabling I²C on a pin does not automatically set the pin to open-drain (nor does it change the current setting for the internal pullup).

In this "I2C for Kinetis MCUs" document, page 23 has this question and answer:


  Q: Why is the low level signal on SDA or SCL not completely pulled down to 0 volts?
  A: For Kinetis MCUs, you may need to configure the I2C pins for open drain mode by setting the PORTx_PCR[ODE] bit. Another cause for this may be a poor ground connection between your master device and slave device.
  [my emphasis above]


(Based on the scope trace, I doubt the ground connection is the cause of your problem.)

As examples of setting open-drain mode in some I²C code, I found two random examples in Kinetis sample code here:

#define I2C_0_PORT_CFG          (PORT_PCR_MUX(I2C_0_PIN_AF) | PORT_PCR_ODE_MASK)

and here:

PORTB-&gt;PCR[0] = PORT_PCR_MUX(2) | PORT_PCR_ODE_MASK;
PORTB-&gt;PCR[1] = PORT_PCR_MUX(2) | PORT_PCR_ODE_MASK;  
As glen_geek has highlighted in earlier comments, it seems that your code continues with I²C communication even after the ACK cycle has the problem described above. Therefore you may have another code bug in this area.