Yo creo que he encontrado la respuesta. Resulta que este es un problema conocido, ¡pero solo lo descubrí después de decidir dónde estaba el problema y buscarlo!
Aquí está el proceso por el que pasé, para que pueda seguirlo (y, si es necesario, puede adaptar su investigación si ve resultados que difieren de mis suposiciones). La conclusión es que parece haber una incompatibilidad entre (al menos algunos) el comportamiento I²C de MSP430 y el comportamiento I²C requerido por el dispositivo que sospecha que es el esclavo I²C, el IDT ZSC31014 . Tener la hoja de datos para ese dispositivo es fundamental para comprender esto, así que gracias por encontrarlo.
La buena noticia es que hay (al menos) 2 soluciones para este problema, que explicaré al final.
La trama se complica, parece que conectar un osciloscopio diferente no hace que el circuito funcione correctamente, y se puede ver que la única diferencia es que no se está transmitiendo un ACK.
Los nuevos rastros son útiles, gracias, aunque los interpreto un poco diferente.
(El subimpulso de la señal SCL, que me preocupaba en la traza inicial, todavía está allí en la última traza. 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 el último rastro. Todavía sugeriría investigar ese SCL underhoot eventualmente, pero no creo que esté relacionado con el problema principal).
Existen esos dos "problemas técnicos" en SDA:
Un problema técnico justo antes o justo después del pulso ACK no es infrecuente, cuando un I²C Master libera el control de SDA para permitir que un Slave realice el ACK y luego el Master puede volver a conducir SDA nuevamente. Por lo tanto, estoy ignorando eso.
Es el primer error de SDA, antes del primer pulso SCL, que es más inusual. A partir de la amplitud de esa falla técnica SDA temprana (ver más adelante) y el hecho de que ocurre solo antes de ese primer pulso SCL (etiquetado 0), pero no ocurre antes de los pulsos SCL posteriores donde podríamos ver una falla técnica en SDA (como SCL pulsos etiquetados 4, 5, 6 o 7), sabemos que no es un artefacto de medición, ni un acoplamiento de SCL (por ejemplo).
(Para referencia posterior, el error técnico de SDA inicial parece al menos 2 V en el último seguimiento, por lo que con Vdd a 3.6 V de comentarios anteriores, eso hace que la amplitud de error técnico de SDA sea al menos (2 / 3.6) = 0.55 x Vdd. Compare eso con los umbrales de nivel lógico I2C relevantes discutidos más adelante).
Ignorando la diferencia de ACK, creo que veo otra diferencia entre los dos conjuntos de trazas en esa segunda captura de pantalla. La amplitud de esa falla técnica de SDA temprana parece ligeramente diferente, comparando la traza SDA superior etiquetada C1(¿amarilla-ish?) Y la segunda traza SDA etiquetada M3(azul). Ahora creo que las diferencias en la amplitud de esa falla técnica de SDA temprana es lo que puede hacer que su problema aparezca o desaparezca, como lo explico a continuación.
Ayudaría una resolución aún más específica sobre el problema técnico (ese es uno de los problemas al tratar de trabajar en problemas "remotamente", ¡no puedo operar el 'alcance yo mismo!). Asumiré que cuando acercas, parece el comienzo de una lógica I²C normal "1" (es decir, una curva RC en el borde ascendente, especialmente si temporalmente debilitas las dominadas, por ejemplo, 10k), excepto que no lo hace. No alcanza el voltaje positivo completo antes de que vuelva a un "0" lógico. Eso es lo que se muestra en otra página web vinculada más adelante. Si ve una forma diferente a su problema técnico, entonces mi análisis posterior podría no aplicarse.
El I²C Master tiene el control del bus en el punto de ese fallo, entre el I²C Start y el primer pulso de reloj SCL (que ha etiquetado como "0" aunque es el MSbit). Eso me hizo sospechar del comportamiento de MSP430, aunque con SCL bajo en ese punto, una falla de SDA no debería afectar a los dispositivos compatibles con I²C, ya que esperarán a que SCL aumente antes de leer el estado de SDA.
Entonces, ¿es ese I²C Slave realmente compatible con I²C? Resulta que el ZSC31014 es " exigente " y menos tolerante que algunos otros dispositivos I²C, ¡exactamente en el momento en que creo que el MSP430 está produciendo ese problema técnico!
La hoja de datos ZSC31014 enumera 3 áreas donde admiten que el comportamiento I²C del dispositivo es "diferente". También puede verse afectado por los dos primeros en esta lista en otros momentos (eso no es parte de este análisis), pero es el tercer punto que he marcado a continuación en rojo, que está relacionado con ese error técnico de SDA:
La amplitud de esa falla técnica SDA temprana es crítica . Si esa falla no aumenta lo suficiente como para que el ZSC31014 la reconozca como un "1" lógico antes de que vuelva a caer, entonces está bien: el dispositivo tiene que ver un borde descendente en SDA para romper esa "regla" y solo puede ser un borde descendente si ya ha sido reconocido como un "1" lógico.
Cualquier cosa que afecte la amplitud de esa falla SDA, como la carga adicional de un 'alcance o analizador lógico en la señal SDA, podría ser suficiente para evitar que la falla sea reconocida por el ZSC31014 como que alcanza un "1" lógico y por lo tanto no "cae" SDA edge ", ese tercer punto en la lista, puede ocurrir (en un buen día, dependiendo de los voltajes, temperaturas, etc.). Sin embargo, como ha encontrado, la variación entre diferentes osciloscopios es suficiente para significar que algunos de ellos agregan suficiente carga para detener el problema, y otros no. ¡Esta configuración debe ser muy marginal!
Esto confirma mi preocupación de que sus lotes anteriores de sensores "en funcionamiento" podrían estar "solo" funcionando, ya que las MCU MSP430 en esas configuraciones "en funcionamiento" probablemente también producirán fallas de SDA. A continuación se explica mi teoría acerca de una posible diferencia entre lotes de sensores, que podría explicar el comportamiento diferente que usted ha informado (lote "en funcionamiento" versus lote "no en funcionamiento").
Curiosamente, el ZSC31014 es diferente del estándar I²C en otra área que el fabricante no menciona en esa lista, y esto podría explicar por qué parece ver una diferencia entre lotes de sensores.
Los umbrales lógicos I²C estándar son (simplificados): por debajo de 0.3 x Vdd para la lógica "0", y superiores a 0.7 x Vdd para la lógica "1" como se muestra en la especificación I²C :
Sin embargo, el ZSC31014 tiene umbrales diferentes , 0.2 x Vdd y 0.8 x Vdd, lo que significa que su "región indefinida" entre esos umbrales es mayor que los dispositivos I²C típicos:
Esa "región indefinida" más grande aumenta la posibilidad de que la falla ingrese al área de nivel de voltaje indefinido, donde podría reconocerse como un "1" lógico (recuerde, cualquier cosa por encima de 0.2 x Vdd podría ser reconocida por el ZSC31014 como un "1" lógico , ya que en la región indefinida, todo está permitido: solo está por encima de 0.8 x Vdd cuando debe reconocerse como un "1" lógico). Y, como se explicó anteriormente, si el ZSC31014 reconoce que la falla ha alcanzado un "1" lógico, entonces cuando cae nuevamente a un "0" lógico, ha roto esa "regla" marcada en rojo para el comportamiento I²C requerido por el ZSC31014.
Dado que no se especifica el reconocimiento de los niveles lógicos en esa región de voltaje "indefinida", el fabricante del sensor no está rompiendo la especificación si hacen un lote que reconoce el "1" lógico solo cuando alcanza 0.7 x Vdd, pero hacen otro lote que reconoce un "1" lógico tan bajo como 0.4 x Vdd, por ejemplo. Ese hipotético segundo lote sería más probable que vea la falla de SDA como un borde de caída de SDA, en violación de ese tercer punto en su lista, pero sin romper su 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 está rompiendo individualmente una especificación que tiene lagunas, pero uno es quisquilloso y menos tolerante, en un punto donde el ¡otro necesita que los dispositivos conectados sean más tolerantes debido a su comportamiento oscuro! Cada uno de esos dos dispositivos está bien conectado con la mayoría de los otros dispositivos, pero no son confiables (o fallan por completo) cuando se conectan entre sí).
¿Entonces que puedes hacer? Pensé en dos opciones:
No use un MSP430: use otro MCU que no cree esa falla técnica SDA temprana. Sin embargo, espero que haya invertido mucho tiempo en el software y no quiera transferir el código a otra MCU, si eso pudiera evitarse.
"Bit-bang" el protocolo I²C en el MSP430, en lugar de usar su módulo de hardware I²C incorporado. De esa manera, usted tiene el control total de las señales I²C y puede evitar que ocurra ese fallo. Sin embargo, obviamente sería un trabajo crear sus propias rutinas I²C, depurarlas, y el código resultante puede ser más grande que cuando se usa el módulo de hardware I²C MSP430, lo que en sí mismo podría ser un problema si le falta espacio en Flash.
Luego, busqué problemas de MSP430 I²C, y descubrí que esta combinación de MSP430 + ZSC31014 es un problema conocido, debido a la falla técnica de SDA del MSP430. Vea este hilo en el foro TI E2E MSP430:
Foro TI E2E: los pulsos de falla MSP430 I2C causan problemas para el chip periférico I2C
La solución mencionada allí es cambiar la dirección ZSC31014 I²C para que SDA sea alta en el momento en que podría producirse un error positivo , y dado que SDA se hace alto, de todos modos, no hay ningún error real en SDA:
Nuestra solución consiste en configurar el chip ZSC para que tenga una dirección con su bit 6 configurado (por ejemplo, ahora estamos usando 0x42): esto convierte el pulso de falla en un bit limpio y "alto" para la duración del bit de dirección 6, que se elimina de la problemática caída del borde.
La misma solución es efectivamente el reverso de la sugerencia en la hoja de datos ZSC31014, en el cuadro rojo que marqué. Dicen que debe evitarse una falla de SDA si el primer bit (que es el MSbit) de la dirección I²C de ZSC31014 es 0, así que no haga que el MSbit de la dirección I²C sea un "0"; ¡Establezca 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, entonces quizás no se produzca el error de SDA, o no sea un problema si ocurre, durante el envío de otros datos en el bus. Tendrás que investigar eso.
Por lo tanto, ignorando la primera solución alternativa de usar una MCU diferente, las dos soluciones (más prácticas) son:
- Golpee el bus MSP430 I²C escribiendo su propio código, para que no cree esa falla en SDA, o
- Cambie la dirección I²C del ZSC31014 para que se establezca el bit 6 de su dirección de 7 bits, lo que significa que SDA ya es alto cuando se produciría el error, de modo que no se produce ningún error real en el SDA cuando se soluciona el ZSC31014 (suponiendo que un error del SDA no ocurre después de otros eventos I²C Start durante la transferencia de datos, o si ocurre uno, que el ZSC31014 no se "molesta").
¡Espero que ayude!
