Estoy tratando de solucionar problemas de comunicación entre un msp430fr5847 (maestro) y un sensor esclavo con chip I2C desconocido (parte de un sensor industrial)
Tengo problemas con un nuevo lote de sensores donde se devuelven mis datos con todos los ceros, sin embargo, cuando intento solucionar problemas con mi Saleae logic pro (2Mohm, 10pf), o mi osciloscopio (10Mohm, 50pf) el sistema funciona perfectamente cuando sondeo el pin SDA
Además, la solución de problemas del circuito funciona correctamente si agrego una resistencia de 1Mohm entre SDA y tierra, pero no funciona si solo agrego un condensador de 10pf o 100pf.
Estoy usando resistencias pull-up de 4.7k para mi riel de 3.3v.
Qué podría estar causando este problema y qué se puede hacer para solucionar el problema sin solucionarlo involuntariamente.
EDITAR: 19/07/2017 Aquí hay un seguimiento rápido del alcance de mis señales.
Algo más que olvidé mencionar es que solo sondear SDA hace que la placa funcione, sondear SCL o mi línea de interrupción no hace que funcione correctamente.
EDITAR: 21/07/2017
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.
En la imagen de arriba, 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 enchufar el USB (tratando de evitar bucles de tierra).
Para agregar un poco más de información sobre el sensor, es un sensor de presión industrial que compramos del fabricante. Hemos diseñado y probado previamente estos PCB con nuestro primer lote de sensores. Recientemente recibimos un nuevo lote y ahora nos encontramos con estos problemas. He realizado un poco de investigación y sospecho fuertemente (después de buscar en Google frases únicas de la hoja de datos) que internamente el sensor usa una hoja de datos PDF ZSC31014 o similar AQUÍ
EDITAR: 26/07/2017
Esperemos que la última entrega para resolver este problema, según la respuesta detallada de SamGibson, haya implementado la solución de configurar el bit alto de la dirección para enmascarar la falla al final del bit de inicio.
Esto ha funcionado principalmente con los datos que llegaron como se esperaba, 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 (en la posición del bit de escritura). Puedo decir que es el esclavo que tira de la línea hacia abajo agregando una pequeña resistencia (47 ohmios) en serie con la línea SDA.
Por lo general, comenzaría esto como una nueva pregunta, pero cuando adjunto el mismo alcance que no tuvo efecto en la solución de problemas anterior, este problema parece desaparecer, esto realmente parece ser un problema límite, incluso si adjunto la sonda de alcance, sin conectarlo al alcance, el problema está resuelto, así que supongo que es un problema de capacitancia.
Trama de problema sin alcance adjunto
Trama de problema con la sonda de alcance conectada, pero no conectada al alcance, observando el voltaje ligeramente más alto cuando el esclavo tira hacia abajo el bit de escritura en lugar del bit ACK.
fuente
Respuestas:
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.
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 etiquetadaM3(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:
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:
¡Espero que ayude!
fuente