No se reconoce la dirección del esclavo I2C (a veces)

Question

Estoy tratando de comunicarme con una FRAM conectada remotamente (FM24C04 de Ramtron) usando I2C. Esta memoria está incrustada en una placa que puede ser insertada y retirada en cualquier momento al/del sistema (la comunicación se termina correctamente antes de retirar la memoria).

El problema es: justo después de insertar la tarjeta que contiene la FRAM, a veces No reconoce la dirección.

Mediciones de señales

He medido las señales para ver qué pasa y parece que los tiempos están bien en ambos casos (funcionando y sin funcionar).

Comunicación I2C correcta (lectura de 3 bytes):

Dirección I2C FRAM no reconocida (la dirección del esclavo se envía correctamente):

Acciones ya realizadas para solucionar este problema (sin éxito)

• Retraso añadido tras la inserción de la tarjeta con la FRAM incorporada para garantizar que se respete la secuencia de alimentación.
• Generación de parada de I2C tras la detección de una dirección de esclavo no reconocida

Configuración del bus I2C

• Un maestro (microcontrolador STM32F205 de ST)
• Tres esclavos (EEPROM 24AA1025 de Microchip, RTC DS1339C de Maxim IC y la FRAM remota FM24C04 de Ramtron
• Se utiliza un desplazador de nivel I2C (MAX3373E de Maxim IC) para permitir la comunicación entre el maestro y la FRAM
• Frecuencia del bus ajustada a 100 kHz

---

EDITADO (2013-04-17)

En primer lugar, gracias a todos por sus comentarios.

Como hay muchas sugerencias, aquí está la descripción de las investigaciones que he hecho.

Esquemas

La siguiente imagen muestra un esquema simplificado del bus I2C:

Las señales I2C_SDA e I2C_SCL se conectan directamente al microcontrolador y las señales FRAM_SDA y FRAM_SCL se conectan a la FRAM. Tenga en cuenta que las señales SDA y SCL conectadas a la FRAM se filtran utilizando ferritas BLM18 de Murata.

La FRAM se conecta de la siguiente manera:

• NC (pin 1) -> no conectado
• A1 (pin 2) -> GND
• A2 (pin 3) -> GND
• VSS (pin 4) -> GND
• SDA (pin 5) -> FRAM_SDA
• SCL (pin 6) -> FRAM_SCL
• WP (pin 7) -> GND (no protegido contra escritura)
• VDD (pin 8) -> +5V

Descripción de la tarjeta FRAM

Esta tarjeta es una tarjeta "similar a la ISA" que sólo incorpora la FRAM.

Investigaciones

Reducción de la frecuencia

Hice pruebas con la frecuencia SCL ajustada a 50kHz y 10kHz. Medí la señal SCL con un osciloscopio para asegurarme de que estaba en la frecuencia esperada.

Estas modificaciones no resolvieron el problema. He comprobado los tiempos y están dentro de las especificaciones de la hoja de datos de la FRAM.

Garantizar la secuencia de alimentación

@jippie.

1. El cambiador de nivel I2C se pone en modo de tres estados antes de insertar la tarjeta que incorpora la FRAM. Las señales FRAM_SDA y FRAM_SCL se ponen a nivel bajo.
2. Tras la inserción de la "tarjeta FRAM", se añade un retardo de 100ms para garantizar la estabilización de la alimentación (se requieren al menos 11ms antes de la primera condición de arranque según la hoja de datos).
3. Se activa el cambiador de nivel I2C.
4. Se añade un retardo de 1ms para asegurar que se activa el cambiador de nivel I2C y que las líneas se suben (~4us requeridos por la hoja de datos). Las señales FRAM_SDA y FRAM_SCL son pull up.
5. Se accede a la FRAM.

Las señales FRAM_SDA y FRAM_SCL se han medido después de cada paso.

El problema sigue existiendo.

Condición de parada/arranque en lugar de arranque repetido

@gbarry.

Intenté poner un tope antes del inicio repetido durante la transferencia de bytes. He medido la transferencia de bytes con el osciloscopio: la condición de STOP seguida de la condición de START está bien.

Por desgracia, esta solución no resuelve el problema.

Pensamientos

Este problema se produce justo después de conectar la tarjeta que incorpora la FRAM. He ejecutado unos cuantos miles de accesos de lectura con éxito (direccionamiento y lectura de esclavos) después de que la "tarjeta FRAM" esté insertada y correctamente direccionada.

Cada vez me suena más a un problema de hardware. Pero no sé si podría estar relacionado con el cambiador de nivel I2C o con los otros esclavos del bus I2C.

¿Tiene alguna otra idea o sugerencia?

---

EDITADO (2013-04-18)

El problema parece estar resuelto

He sustituido el conector del módulo FRAM y he encontrado la manera de hacer mediciones directamente en el FRAM. Parece que todo funciona bien con este nuevo conector.

Haré más pruebas para estar seguro de que el problema proviene de una mala conexión.

Answer 1

Aunque dices que tus comunicaciones están correctamente terminadas antes de la inserción o extracción, puede valer la pena probar esta solución, ya que hay una situación en la que el bus I2C puede dar problemas después de un reinicio de sólo uno de los dispositivos en el bus.

Antes de inicializar el hardware I2C maestro, configure SDA como entrada y compruebe si SDA está bajo.

Si es bajo, entonces ponga el pin SCL en alto.

A continuación, conmuta el pin SCL a bajo y alto hasta que SDA se ponga a alto (es decir, desconecta los bits restantes que los periféricos puedan estar aún intentando enviar). Esto no puede tomar más de 8 ciclos de reloj - si lo hace entonces hay algún otro problema.

No puedo garantizar que esto resuelva tu problema, pero sí resolvió el mío.

Answer 2

Dado que el problema, cuando se reproduce, es un fallo permanente que sólo se borra quitando y volviendo a poner el dispositivo, entonces es una de dos cosas: el dispositivo entra en un mal estado del que sólo se recupera con un ciclo de alimentación, o hay un mal contacto.

Si el dispositivo entra en un mal estado del que se recupera en un ciclo de alimentación, puedes tener un circuito adicional que permita a tu MCU apagar el dispositivo. Entonces, el firmware, al no obtener reconocimiento del dispositivo, puede ejecutar un procedimiento de recuperación por el que apaga el chip durante algún tiempo, lo vuelve a encender y lo vuelve a intentar.

Si se trata de un contacto deficiente, tal vez haya que examinar la fiabilidad del conector y encontrar algo mejor. Si usas el mismo conector para hacer más de estas placas, podría haber problemas en el campo. En cualquier caso, puede haber un procedimiento humano para manejar la situación. El operario que trabaje con el dispositivo tiene que ser consciente del posible problema de la inserción de la tarjeta, y de que puede ser necesario volver a colocarla para que funcione correctamente.

Su dispositivo principal podría tener una forma de emitir una alarma que indique que no puede hablar con el FRAM: un LED de "problema" en un panel y/o un pitido o lo que sea. O a la inversa: alguna luz que se encienda y que indique al usuario que el FRAM ha sido aceptado y se ha establecido la comunicación. Si la FRAM está lejos del dispositivo maestro, la luz puede estar situada en el módulo de la FRAM: otro chip I2C que acciona un LED.

Answer 3

¿Hay alguna posibilidad de que haya algo más tratando de hablar con esa placa? Tuve un problema así una vez; pude obtener un ack el 60% de las veces, pero no recuerdo haber podido ver una colisión. Sospecho que el i2c que me proporcionaron estaba aislado de alguna manera del bus interno real. Podía ejecutarlo continuamente, y sólo dejaba caer el 30% de los mensajes. El problema desapareció en el momento en que empezamos a hablar directamente con el dispositivo (una fuente de alimentación) sin la intervención de la "placa base".

No veo una secuencia de parada después de su error NAK. Supongo que tienes un breakpoint que detiene el programa en ese punto.

Por último, si crees que eres el único que va en el autobús, puedes intentar sustituir el arranque repetido por una parada/arranque. He visto dispositivos (especialmente FPGAs personalizadas) que no sabían muy bien cómo manejar el RS.

[En respuesta al comentario]: Hay muchas cosas que no has dicho sobre la placa FRAM, como por ejemplo si es sólo memoria o un subsistema completo. Pero si puedes poner el 'scope justo en los cables del dispositivo i2c que te está dando problemas, y sigues viendo lo que aparece en la foto, entonces yo descartaría la interferencia. El I2C es lo suficientemente simple como para que si ves las señales correctas en la entrada, entonces el chip debería funcionar correctamente a menos que tenga un problema interno.

En particular, querrás ponerte en el lado de la FRAM de ese cambiador de nivel. Es más probable que se produzca una interrupción de la señal que algo que normalmente se consideraría una colisión.

Señalaré que un ciclo NAK es indistinguible de un chip que simplemente no está ahí. Las EEPROMs hacen esto para indicar que están ocupadas. Busqué el tiempo de escritura en la FRAM y es más rápido que un solo bit de datos i2c... así que eso no es un problema.

Answer 4

Para el FRAM:

• conecte primero GND y Vcc;
• entonces asegúrese de que A1, A2 y WP tienen el nivel correcto;
• sólo entonces conectar los pines de datos.

Conectar otras clavijas que no sean las de alimentación antes de que el chip se encienda puede causar problemas.

Answer 5

10k me parece un poco grande para tus pullups, y tus bordes de ataque parecen lentos. Reduzca las resistencias a unos 3k y vea si eso ayuda.

Además, ¿por qué la tensión de desconexión se desvía con el tiempo?