Como DoxyLover señaló, la traza muestra claramente un voltaje intermedio, causado por el conflicto entre dos dispositivos que controlan esa señal SDA en direcciones opuestas para el ciclo I²C ACK . Ya que el esclavo I²C está conduciendo esa señal baja (como ACK ), entonces su Kinetis K60 MCU debe conducirlo alto al mismo tiempo.
Al igual que con muchas MCU, cuando el módulo I²C interno está conectado a los pines externos reales (por ejemplo, a través del multiplexor de pines interno), esos dos pines también deben configurarse en modo de "drenaje abierto" como paso separado en la configuración.
En el Manual de referencia de NXP, que creo que incluye su MCU K60 específica ( 20MB archivo pdf ), página 282 (sección 11.6.1 Control de pines) dice:
Por ejemplo, si una función I²C está habilitada en un pin, eso no invalida la configuración pullup o de drenaje abierto para ese pin.
En otras palabras, habilitar I²C en un pin no configura automáticamente el pin a drenaje abierto (ni cambia la configuración actual del pullup interno).
En este "I2C para Kinetis MCUs" documento, página 23 tiene esta pregunta y respuesta:
P: ¿Por qué la señal de bajo nivel en SDA o SCL no se reduce completamente a 0 voltios?
R: Para las MCU de Kinetis, es posible que deba configurar los pines I2C para el modo de drenaje abierto configurando el bit PORTx_PCR [ODE]. Otra causa puede ser una mala conexión a tierra entre su dispositivo maestro y el esclavo. dispositivo.
[mi énfasis arriba]
(Basado en el seguimiento del alcance, dudo que la conexión a tierra sea la causa de su problema).
Como ejemplos de cómo configurar el modo de drenaje abierto en algunos códigos I²C, encontré dos ejemplos aleatorios en el código de ejemplo de Kinetis aquí :
#define I2C_0_PORT_CFG (PORT_PCR_MUX(I2C_0_PIN_AF) | PORT_PCR_ODE_MASK)
y aquí :
PORTB->PCR[0] = PORT_PCR_MUX(2) | PORT_PCR_ODE_MASK;
PORTB->PCR[1] = PORT_PCR_MUX(2) | PORT_PCR_ODE_MASK;
