Error de bit I2C ACK

Estoy usando un SMT32F030R8 para comunicarme a través de I2C con otros dispositivos, y el problema es que estoy capturando una falla en el bit ACK de I2C. Como se muestra en la imagen, al final de uno de los bytes, la línea de datos debe permanecer baja porque ha sido reconocida por el esclavo; sin embargo, el SDA sube y se lleva rápidamente a GND nuevamente.

ingrese la descripción de la imagen aquí

Lo primero que pensé fue que podría haber algún problema de sincronización, pero probé diferentes frecuencias y configuraciones de configuración y retención de datos y sigue ocurriendo el mismo problema. Lo que estoy pensando ahora es que esto es el resultado de un retraso del esclavo para bajar la línea SDA (aunque ya ha reconocido el byte).

¿Alguien ha tenido el mismo problema y ha encontrado la respuesta?

He visto personas que sugieren agregar capacitancia a la línea, pero eso no resuelve el problema, solo lo oculta.

Configuré los puertos I2C como de drenaje abierto sin pull-up interno y agregué resistencias pull-up externas de 10k. He capturado el mismo tipo de problema con diferentes dispositivos y no es algo que suceda para todos los bytes.

Si necesitan más información o tienen alguna sugerencia, por favor háganmelo saber.

No sabemos absolutamente nada sobre el diseño y los componentes de su hardware, ¿cómo se supone que debemos señalar los errores allí?
¿Experimentas problemas de comunicación? ACK se muestrea en el borde positivo de SCL y esto parece estar bien aquí.
Publique un diagrama de su configuración I2C, incluidos todos los dispositivos que tocan el bus, pull ups y capacitores. ¿Se está cronometrando el fallo?
¿Ves algún error de bit?

Respuestas (1)

Lo que describes parece normal. Si el último bit de datos en un byte es bajo, el maestro debe conducir SDA a lo largo del ciclo alto-bajo de SCK que sigue a ese bit. Durante el siguiente ciclo alto-bajo de SCK, el maestro deberá liberar SDA y el esclavo deberá controlarlo, pero entre los dos ciclos alto-bajo, el maestro y el esclavo pueden controlar o liberar SDA arbitrariamente de cualquier manera que deseen. consideran necesario. Si el esclavo no comienza a conducir SDA rápidamente, debe mantener SCK bajo hasta que lo haya hecho.

El circuito bus-master del STM parece liberar SDA inmediatamente después del flanco descendente de SCK, antes de que el esclavo haya comenzado a afirmarlo, pero eso no es un problema ya que el esclavo comienza a afirmar SDA mucho antes del siguiente flanco ascendente de SCK.

Esto es bastante correcto. Se espera que el esclavo libere SDA (permítale flotar alto) tan pronto como SCL caiga al final del ack. Al observar el nivel de 0, verá que está un poco por encima de cero cuando el esclavo mantiene presionado SDA para el ACK, y justo en 0V cuando el maestro lo mantiene presionado. Como dice supercat, el maestro puede hacer lo que le dé la gana con SDA mientras que SCL es bajo, y con implementaciones poco golpeadas, puede subir y bajar más de una vez...
... y es solo en el flanco ascendente de SCK cuando se lee el estado de la línea SDA.
@HenryCrun: si el esclavo es capaz de mantener presionado SCK, también tiene el tiempo libre para hacer lo que quiera con SDA siempre que mantenga presionado SCK.
supergato: gracias por la respuesta. Todo eso tiene sentido para mí. Simplemente estaba preocupado porque el software Saleae estaba leyendo muchos de ellos como un byte +NACK, lo cual no es correcto. Como @CL también mencionó, el bit ACK solo se registra en el borde ascendente de SCL, por lo que esta es una mala interpretación del software Saleae. En cualquier caso, pedí asegurarme de que este comportamiento no fuera inusual. Muchas gracias por la pronta respuesta constructiva.
Error de bit I2C ACK
RespuestasAquíPolítica de privacidad1y, 0v