Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I am trying to communicate Kinetis K60 tower board with a Cypress IC CY8CMBR3116 cy8320 development board as slave IC. There are only two devices on the I2C bus. I am attaching a snapshot of the communication taking place on the I2C bus.
The problem is that the acknowledgment is not low enough for the master to detect and even the stop condition is not correct. This is happening after sending the default address of 0X37 to the cypress IC.
Please tell me the reason for this output.
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->PCR[0] = PORT_PCR_MUX(2) | PORT_PCR_ODE_MASK;
PORTB->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.
