I2C sólo funciona cuando se sondea o se carga con 1Mohm

Question

Estoy tratando de solucionar problemas de comunicaciones entre un msp430fr5847 (maestro) y un sensor esclavo con chip I2C desconocido (parte de un sensor industrial).

Estoy teniendo problemas con un nuevo lote de sensores donde mis datos están siendo devueltos con todos los ceros, sin embargo, cuando se trata de solucionar problemas con mi Saleae logic pro (2Mohm, 10pf), o mi osciloscopio (10Mohm, 50pf) el sistema funciona perfectamente cuando se sondea el pin SDA.

Solucionando mas problemas el circuito funciona correctamente si añado una resistencia de 1Mohm entre SDA y masa, pero no funciona si solo añado un condensador de 10pf o 100pf.

Estoy usando resistencias pull up de 4.7k a mi rail de 3.3v.

Cuál podría ser la causa de este problema y qué se puede hacer para solucionarlo sin arreglarlo involuntariamente.

---

EDICIÓN: 19/07/2017 Aquí está una traza de alcance rápido de mis señales.

Otra cosa que olvidé mencionar es que sólo sondeando SDA hace que la placa funcione, sondeando SCL o mi línea de interrupción no consigue que funcione correctamente.

---

EDICIÓN: 21/07/2017

La trama se complica, parece que conectando otro osciloscopio no se consigue que el circuito funcione correctamente, y se ve que la única diferencia es que no se transmite un ACK.

En la imagen anterior, las trazas azul y verde son SCL y SDA cuando el circuito no funciona correctamente. Las trazas amarilla y rosa son de cuando también conecto mi lógica Saleae al Pin SDA y a tierra pero sin conectar USB (intentando evitar bucles de tierra).

Se trata de un sensor de presión industrial que compramos al fabricante. Hemos diseñado y probado previamente estas placas de circuito impreso con nuestro primer lote de sensores. Recientemente hemos recibido un nuevo lote y ahora nos encontramos con estos problemas. He hecho un poco de investigación y sospecho fuertemente (después de buscar en Google frases única mirada de la hoja de datos) que internamente el sensor utiliza un ZSC31014 o similar, hoja de datos PDF AQUÍ

---

EDICIÓN: 26/07/2017

Así que espero que la última entrega en la solución de este problema, según la respuesta detallada de SamGibson he implementado la solución de establecer el bit alto de la dirección para enmascarar el glitching al final del bit de inicio.

Esto ha funcionado sobre todo con los datos que vienen a través de lo esperado, sin embargo ahora parece que en el primer comando de lectura después de una escritura (si ese es el término correcto para un grupo de bits i2c), el esclavo intenta ACK un bit antes de tiempo (en la posición del bit de escritura). Puedo decir que es el esclavo tirando de la línea hacia abajo mediante la adición de un pequeño (47 ohmios) resistencia en serie con la línea SDA.

Normalmente empezaría esto como una nueva pregunta, pero cuando conecto el mismo osciloscopio que no tuvo efecto en la solución de problemas anterior, este problema parece desaparecer, esto realmente parece ser un problema límite, ya que incluso si conecto la sonda del osciloscopio, sin conectarlo al osciloscopio el problema se resuelve, así que estoy asumiendo que es un problema de capacitancia.

Parcela de emisión sin ámbito de aplicación

Diagrama del problema con la sonda conectada, pero no conectada al osciloscopio, observando el voltaje ligeramente más alto cuando el esclavo tira hacia abajo del bit de escritura en lugar del bit ACK.

Answer 1

I piense en He encontrado la respuesta. Resulta que es un problema conocido, pero sólo lo encontré después de decidir dónde estaba el problema y buscarlo.

He aquí el proceso que he seguido, para que puedas seguirlo (y, si es necesario, puedes adaptar tu investigación si ves resultados que difieren de mis suposiciones). La conclusión es que parece haber una incompatibilidad entre (al menos algunos) MSP430 I²C comportamiento, y el comportamiento requerido I²C por el dispositivo que sospecha que es el esclavo I²C, el IDT ZSC31014 . Disponer de la hoja de datos de ese dispositivo es fundamental para entenderlo, así que gracias por encontrarla.

La buena noticia es que existen (al menos) 2 soluciones para este problema, que explicaré al final.

La trama se complica, parece que conectando otro osciloscopio no se consigue que el circuito funcione correctamente, y se ve que la única diferencia es que no se transmite un ACK.

Las nuevas trazas son útiles, gracias, aunque yo las interpreto de forma un poco diferente.

(El subimpulso de la señal SCL, que me preocupaba en el trazo inicial, sigue ahí en el último trazo. Es interesante que el subimpulso en SCL parece mayor que el subimpulso en SDA, especialmente teniendo en cuenta las diferentes escalas verticales entre las señales SCL y SDA en la última traza. Todavía sugeriría investigar ese undershoot en SCL eventualmente, pero no creo que esté relacionado con el problema principal).

Existen esos dos "fallos" en SDA:

• Un fallo justo antes o justo después del pulso ACK no es infrecuente, cuando un Maestro I²C libera el control de SDA para permitir a un Esclavo realizar el ACK y entonces el Maestro podría volver a controlar SDA de nuevo. Por lo tanto estoy ignorando eso.

• Es la principios de SDA glitch, antes del primer pulso SCL, que es más inusual. Por la amplitud de ese glitch temprano en SDA (ver más adelante) y el hecho de que ocurre sólo antes de ese primer pulso SCL (etiquetado como 0), pero no ocurre antes de pulsos SCL posteriores donde podríamos ver un glitch en SDA (como pulsos SCL etiquetados como 4, 5, 6 o 7), sabemos que no es un artefacto de medición, ni acoplamiento desde SCL (por ejemplo).

(Para referencia posterior, el primer fallo de SDA tiene el siguiente aspecto como mínimo 2V en el último trazo, así que con Vdd a 3.6V de comentarios anteriores, eso hace que la amplitud del glitch SDA sea al menos (2/3.6) = 0.55 x Vdd. Compara eso con los umbrales de nivel lógico I2C relevantes discutidos más adelante).

Ignorando la diferencia ACK, creo ver otra diferencia entre los dos conjuntos de trazas en esa segunda captura de pantalla. La amplitud de ese principios de El fallo SDA parece ligeramente diferente, comparando la traza SDA superior etiquetada como C1 (¿amarillento?) y la segunda traza SDA etiquetada como M3 (azul). Ahora creo que las diferencias en la amplitud de ese fallo inicial de la SDA, es lo que puede hacer que tu problema aparezca o desaparezca, como explico a continuación.

Incluso una mayor resolución específica sobre el fallo ayudaría (ese es uno de los problemas al intentar trabajar en problemas "remotamente" - ¡no puedo operar el 'scope yo mismo!). Voy a suponer que cuando se amplía, se ve como el comienzo de una lógica normal I²C "1" (es decir, una curva de RC en el flanco ascendente, especialmente si usted hace temporalmente los pull-ups más débil, por ejemplo, 10k), excepto que no alcanza el voltaje positivo completo antes de que sea conducido a una lógica "0" de nuevo. Eso es lo que se muestra en otra página web enlazada más adelante. Si usted ve una forma diferente a su fallo, entonces mi análisis posterior podría no aplicarse.

El I²C Master está en control del bus en el punto de ese glitch, entre el I²C Start y el primer pulso de reloj SCL (que has etiquetado como "0" aunque es el MSbit). Eso me hizo sospechar del comportamiento del MSP430, aunque con SCL bajo en ese punto, un glitch de SDA no debería afectan a los dispositivos compatibles con I²C, ya que estarán esperando a que SCL se ponga a nivel alto antes de leer el estado de SDA.

Entonces, ¿es I²C Esclavo realmente ¿Compatible con I²C? Resulta que el ZSC31014 es " quisquilloso " y menos tolerante que algunos otros dispositivos I²C, ¡exactamente en el momento en que creo que el MSP430 está produciendo ese fallo!

En Ficha técnica de ZSC31014 enumera 3 áreas en las que admiten que el comportamiento I²C del dispositivo es "diferente". Puede que los dos primeros de la lista también te afecten en otras ocasiones (eso no forma parte de este análisis), pero es el tercer punto el que he marcado en rojo a continuación, el que está relacionado con ese fallo temprano del SDA:

---

---

La amplitud de ese fallo temprano de SDA es crítico . Si el ZSC31014 no reconoce ese deslizamiento como un "1" lógico antes de que vuelva a caer, entonces no hay problema. cayendo borde en SDA para romper esa "regla" y sólo puede ser un cayendo si ya ha sido reconocido como un "1" lógico.

Cualquier cosa que afecte a la amplitud de ese glitch SDA, como la carga adicional de un 'scope o analizador lógico en la señal SDA, podría ser suficiente para que el glitch no sea reconocido por el ZSC31014 como alcanzando un "1" lógico y, por lo tanto, no pueda ocurrir ningún "flanco SDA descendente", ese tercer punto de la lista (en un buen día, dependiendo de voltajes, temperaturas, etc.). Sin embargo, como has comprobado, la variación entre distintos osciloscopios es suficiente para que algunos de ellos añaden suficiente carga para detener el problema, y otros no. ¡Esta configuración debe ser muy marginal!

Esto confirma mi preocupación de que tus primeros lotes de sensores que "funcionaban", podrían estar "sólo" funcionando, ya que los MCUs MSP430 en esas configuraciones que "funcionaban" probablemente también estarían produciendo fallos SDA. Mi teoría sobre un posible A continuación se explica la diferencia entre los lotes de sensores, que podría explicar el diferente comportamiento que ha notificado (lote "que funciona" frente a lote "que no funciona").

Curiosamente, el ZSC31014 es diferente de I²C estándar en otra área que no se menciona en esa lista del fabricante, y esto podría explicar por qué usted parece ver una diferencia entre los lotes de sensores.

Los umbrales lógicos I²C estándar son (simplificados) - por debajo de 0,3 x Vdd para el "0" lógico, y por encima de 0,7 x Vdd para el "1" lógico, como se muestra en el gráfico Especificación I²C :

---

---

Sin embargo, el ZSC31014 tiene diferente umbrales, 0,2 x Vdd y 0,8 x Vdd, lo que significa que su "región indefinida" entre esos umbrales es más grande que los dispositivos I²C típicos:

---

---

Esa "región indefinida" más grande aumenta la posibilidad de que el fallo entre en la zona de nivel de tensión indefinido, donde puede ser reconocido como un "1" lógico (recuerde, cualquier cosa por encima de 0,2 x Vdd podría ser reconocido por el ZSC31014 como un "1" lógico, ya que en la región indefinida, cualquier cosa está permitido - sólo está por encima de 0,8 x Vdd cuando debe ser reconocido como un "1" lógico). Y, como se ha explicado antes, si el glitch es reconocido por el ZSC31014 como habiendo alcanzado un "1" lógico, entonces cuando cae de nuevo a un "0" lógico, has roto esa "regla" marcada en rojo para el comportamiento I²C requerido por el ZSC31014.

Dado que el reconocimiento de los niveles lógicos en esa región de tensión "indefinida" no está especificado, el fabricante del sensor no incumple la especificación si fabrica un lote que reconoce un "1" lógico sólo cuando alcanza 0,7 x Vdd, pero fabrica otro lote que reconoce un "1" lógico tan bajo como 0,4 x Vdd, por ejemplo. Ese hipotético segundo lote tendría más probabilidades de ver el fallo SDA como un flanco SDA descendente, violando el tercer punto de la lista, pero sin incumplir la especificación.

(Muchos de los problemas en los que he trabajado, a lo largo de los años, han sido así: Hay dos dispositivos, ninguno de los cuales incumple individualmente una especificación que tiene lagunas - pero uno es quisquilloso y menos tolerante, en un punto en el que el otro necesita que los dispositivos conectados sean más tolerante debido a su ¡comportamiento oscuro! Cada uno de esos dos dispositivos funciona bien en interfaz con la mayoría de los demás dispositivos, pero no son fiables (o fallan por completo) cuando se conectan entre sí).

¿Qué puedes hacer? Se me ocurren dos opciones:

• No utilices un MSP430 - utiliza otro MCU que no cree ese fallo SDA temprano. Sin embargo, supongo que habrás invertido mucho tiempo en el software y no querrás portar el código a otro MCU, si eso puede evitarse.

• "Bit-bang" el protocolo I²C en el MSP430, en lugar de utilizar su módulo de hardware I²C incorporado. De esta forma, tienes el control total de las señales I²C y puedes evitar que se produzca ese fallo. Sin embargo, obviamente te costará trabajo crear tus propias rutinas I²C, depurarlas, y el código resultante puede ser más grande que cuando usas el módulo de hardware I²C del MSP430, lo que en sí mismo podría ser un problema si tienes poco espacio en Flash.

Entonces me puse a buscar problemas de MSP430 I²C, y encontré que esta combinación de MSP430 + ZSC31014 es un problema conocido, ¡debido a ese fallo temprano de SDA del MSP430! Ver este hilo en el foro de TI E2E MSP430:

Foro TI E2E: MSP430 I2C glitch pulses causing trouble for I2C peripheral chip

La solución mencionada es cambiar la dirección I²C del ZSC31014 para que SDA esté alta en el momento en que se produce el fallo positivo. podría y dado que SDA se pone a nivel alto de todos modos, no hay actual fallo en SDA:

Nuestra solución es configurar el chip ZSC para que tenga una dirección con su bit 6 activado (por ejemplo, ahora estamos usando 0x42) - esto convierte el pulso de glitch en un bonito y limpio bit "alto" para la duración del bit 6 de la dirección, lo que elimina el problemático flanco descendente.

La misma solución es efectivamente la inversa de la sugerencia en la hoja de datos ZSC31014, en el cuadro rojo que he marcado. Dicen que se debe evitar un fallo SDA si el primer bit (que es el MSbit) de la dirección I²C del ZSC31014 es 0 - así que no hagas que el MSbit de la dirección I²C sea un "0", haz que sea un "1" en su lugar, es decir, ¡pon el bit 6 en la dirección I²C de 7 bits!

Dado que el hilo del foro TI E2E y la hoja de datos ZSC31014 se centran en la dirección I²C, tal vez el fallo SDA no se produce, o no es un problema si se produce, durante el envío de otros datos en el bus. Tendrás que investigarlo.

Por lo tanto, ignorando la primera solución de utilizar una MCU diferente, las dos soluciones (más prácticas) son:

• Bit-bang del bus I²C del MSP430 escribiendo tu propio código, para no crear ese fallo en SDA, o
• Cambie la dirección I²C del ZSC31014 de modo que el bit 6 de su dirección de 7 bits esté activado, lo que significa que SDA ya está alto cuando se produciría el fallo, por lo que no se produce ningún fallo. actual se produce un fallo en SDA cuando se direcciona el ZSC31014 (suponiendo que no se produce un fallo en SDA después de otros eventos de inicio de I²C durante la transferencia de datos, o si se produce uno, que el ZSC31014 no se "altera").

Espero que le sirva de ayuda.