¿Por qué mi escritura I2C se vuelve NAK?

Estoy tratando de conectarme a un dispositivo existente, para el cual no tengo documentación. El dispositivo expone una interfaz 5v I 2 C con varios circuitos integrados en el bus. He usado un analizador lógico para capturar el tráfico y no entiendo por qué no se aceptan mis escrituras.

Sistema de trabajo:

Unknown microcontroller  ==| connector |==+== PIC 12F509 with internal oscillator
                                          |== 24C16WI 2k EEPROM
                                          \== Logic analyzer

La primera comunicación con el dispositivo es enviar una solicitud de escritura a la dirección 0x49, pero cuando intento hacer lo mismo, no recibo respuesta. Hay diferencias de tiempo obvias entre mi solicitud y la de ellos, pero no estoy seguro de si son significativas. La comunicación con el 24C16WI es exitosa, pero no puedo obtener respuesta del PIC.

Solicitud de trabajo (tasa de baudios 36kHz) ( captura Saleae ):Comunicación I2C desde el sistema de trabajo

Mi solicitud (tasa de baudios 31kHz) ( captura Saleae ):Mi petición

Suponiendo que la diferencia no dependa de una señal distinta de las líneas I 2 C, ¿son significativas las diferencias de temporización en la señal? Si son significativos, ¿cómo puedo generar el tiempo requerido usando un Atmel SAMD21J18?

¿Qué me estoy perdiendo?

Como control rápido de cordura, conecta un visor a las líneas lógicas y asegúrate de que los niveles sean correctos (o pon las sales en modo analógico, si tienes uno que pueda hacerlo). Me mordió un analizador lógico que mostraba transiciones que en realidad no cumplían con las especificaciones requeridas.
¡El maestro (proveedor CLK) es fácil pero el esclavo no! ¿36 khz requerían un divisor de 1 MHz para rastrear lo que sucedió?
En la captura de trabajo, la sincronización de los bordes es horrible, pero eso podría ser un problema con el bus. Esto realmente requiere una traza de osciloscopio.
¿Estás golpeando un esclavo I2C dentro de PIC12F509? Quizás deberías mirar su código. ¿Ha probado una secuencia SCL/SDA de limpieza de bus aprobada por I2C? También podría ser un bloqueo de encendido.
Le conectaré un visor en breve. @glen_geek, leí la hoja de datos del dispositivo esclavo (PIC12F509) pero no vi una implementación de hardware I2C. Solo puedo suponer que están golpeando un poco. No he intentado volcar el código, pero supongo que tienen el conjunto de fusibles de protección de código. El PIC12F509 es parte de un dispositivo de terceros, por lo que no tengo acceso al código fuente original.
@dsgdfg, no entiendo. Actúo como maestro de bus para el PIC12F509 del dispositivo de terceros. Las frecuencias medidas son simplemente midiendo el período SCL en el analizador lógico.
Estás haciendo I2C un poco más rápido que la transacción exitosa, tal vez el código I2C 12F509 de bit-bang no puede seguir el ritmo. ¿Intentó una transacción un poco más lenta?
@glen_geek, mi SCL cambia más lentamente que la transacción de trabajo. Observo que hay un retraso mayor en la secuencia de inicio, pero no estoy seguro de cómo producirlo con el controlador Atmel ASF I2C.
@mbrig, Low es 0v, high es 3.36v, 3.7Vdd. No hay ruido evidente durante períodos estables, tiempo de subida de 600 ns, tiempo de caída de 120 ns, el timbre es de ~1 Vpp durante 100 ns.
El esclavo no es fácil de decir, necesita un detector de 2 bordes (subida, caída) y un temporizador interno para recibir los datos correctos. Estamos hablando de comunicación basada en el borde, por lo que no podemos manejar datos si tiene un período prolongado en la detección del borde. Combina todos mis comentarios y comprueba esto.

Respuestas (2)

Resumen: Sospecho que el nuevo tiempo I 2 C no es lo suficientemente cercano al original, y al menos una secuencia I 2 C "anormal" se muestra en el "trazo de trabajo", lo que puede ser difícil de reproducir.

Detalles:

Suponiendo que la diferencia no dependa de una señal que no sean las líneas I 2
C [...] ¿Qué me estoy perdiendo?

Las capturas del analizador lógico son muy útiles, gracias. Junto con la otra información, creo que tenemos un buen "sospechoso".

Hay diferencias de tiempo obvias entre mi solicitud y la de ellos, pero no estoy seguro de si son significativas.

Apuesto a que las diferencias de tiempo son significativas, especialmente porque:

La comunicación con el 24C16WI es exitosa

Entonces, usando su propio I 2 C Master, puede comunicarse con el dispositivo I 2 C estándar (esa EEPROM). Como dijiste, el problema es tratar de obtener una respuesta del PIC y, como señalaste en un comentario posterior, ese PIC no tiene un módulo I2C incorporado:

Leí la hoja de datos del dispositivo esclavo (PIC12F509) pero no vi una implementación de hardware I2C. Solo puedo suponer que están golpeando un poco.

¡Sí! He visto otros dispositivos PIC (sin un módulo I 2 C interno) programados como esclavos I 2 C, que tenían restricciones de tiempo significativas en su comportamiento I 2 C.

Observo que hay un retraso mayor en la secuencia de inicio

Exactamente. No he medido con el software Saleae, pero "a simple vista" hay un retraso de aproximadamente 0,8 ms entre la condición de inicio de I 2 C y el primer cambio de la señal SCL en el seguimiento de trabajo , y no hay tal retraso en el seguimiento fallido .

Ese retraso no es el comportamiento típico de I 2 C, pero sospecho que es necesario que el firmware PIC (desconocido) reconozca la condición de inicio de I 2 C (por ejemplo, tal vez tenga que despertarse del modo de suspensión, usando el PIC GPIO "wake on change" cuando la señal SDA cambia como parte de la condición de inicio I 2 C).

Si estuviera en su situación, comenzaría con la hipótesis de que todos los tiempos I 2 C originales son importantes (no solo la velocidad del reloj SCL, donde ya es similar a la velocidad original) y trataría de duplicar los tiempos originales y comportamiento por completo . Después de todo, esa secuencia original funciona :-)

Hay otras partes inusuales en la transacción I 2 C "funcional":

  • En el byte de dirección, parece haber un pequeño retraso entre el reloj del bit 8 y el reloj del (9º) bit ACK/NACK. Nuevamente, ese retraso (que no existe en su seguimiento "fallido") podría ser requerido por el firmware PIC.

  • En el siguiente byte, veo solo 8 pulsos de reloj, no los 9 pulsos esperados, lo que explica el comentario del software Saleae sobre "Falta ACK/NACK". Una vez más, este comportamiento I 2 C (anormal) puede ser necesario para cumplir con las expectativas del firmware PIC, pero es probable que sea difícil o imposible de reproducir, utilizando el código de biblioteca/controlador I 2 C "normal" , ya que esto normalmente generaría los 9 pulsos de reloj normales.

No estoy seguro de cómo producir eso con el controlador Atmel ASF I2C.

No he usado ese controlador. Puede investigar si puede insertar un retraso después de enviar la condición de inicio I 2 C, antes de enviar la dirección del dispositivo. Eso es independiente del pulso de reloj "Missing ACK/NACK" (¡que podría faltar!) cuando el Maestro transmitió el segundo byte en el "rastreo de trabajo".

Por lo tanto, es posible que no pueda usar ese controlador "tal cual" y, en su lugar, es posible que deba escribir su propio código de bajo nivel ("controlador"), lo que le brinda más control. Si todo lo demás falla para brindarle la cantidad necesaria de tiempo y control de pulso de reloj, es posible que deba hacer un bit-bang de las señales SDA y SCL del Maestro para algunas o todas las secuencias de protocolo I 2 C que necesita .

Creo que estás en algo aquí. Agregar un retraso entre la condición de inicio y el primer bit de datos al cambiar a una implementación de software I2C hizo que el PIC reconociera el byte de dirección. Creo que la interfaz puede estar mal etiquetada como I2C :) El acuse de recibo que falta en el byte 2 es especialmente interesante.

¿Por qué estás usando la dirección 0X49?

Encontré estos datos en el 24C16, lo que implica que la dirección base es 0x50. Tenga cuidado con la representación de la dirección en 7 u 8 bits.

El momento de la "solicitud de trabajo" se ve mal. Debe tener tiempo de configuración antes del borde positivo del reloj.

Su solicitud está mejor formada pero tiene una dirección incorrecta.

ingrese la descripción de la imagen aquí

Kevin, estoy tratando de comunicarme con el PIC, no con el 24C16. Puedo comunicarme con el 24C16 con éxito en la dirección 0x50.
Lo siento, mi error. Aun así, el momento se ve mal en la solicitud de trabajo. Los datos están cambiando al mismo tiempo que el borde positivo del reloj, eso no es I2C legal. ¿Dónde está la transición de inicio?
Eso se ve un poco cerca para mayor comodidad. Acercar muestra los datos que llegan aproximadamente 1 μs antes de que suba el reloj .
¿Por qué mi escritura I2C se vuelve NAK?
RespuestasAquíPolítica de privacidad1y, 0v