Dirección esclava I2C no reconocida (a veces)

Estoy tratando de comunicarme con un FRAM conectado de forma remota (FM24C04 de Ramtron) usando I2C. Esta memoria está incrustada en una placa que se puede insertar y quitar en cualquier momento hacia / desde el sistema (la comunicación finaliza correctamente antes de que se quite la memoria).

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

Mediciones de señales

Medí las señales para ver qué está sucediendo y parece que los tiempos están bien en ambos casos (funciona y no funciona).

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

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

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

• Retardo agregado después de insertar la tarjeta con el FRAM incorporado para garantizar que se respete la secuencia de alimentación.
• I2C detiene la generación después de la detección de una dirección esclava no confirmada

Configuración del bus I2C

• Un maestro (microcontrolador STM32F205 de ST)
• Tres esclavos (EEPROM 24AA1025 de Microchip, RTC DS1339C de Maxim IC y el FRAM FM24C04 remoto de Ramtron
• Se utiliza una palanca de cambio de nivel I2C (MAX3373E de Maxim IC) para permitir la comunicación entre el maestro y el FRAM
• Frecuencia de bus configurada 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 realizado.

Esquemas

La siguiente imagen muestra un esquema simplificado del bus I2C:

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

El FRAM está conectado 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 ISA" que incorpora solo el FRAM.

Investigaciones

Disminuyendo la frecuencia

Realicé pruebas con la frecuencia SCL establecida en 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. Verifiqué los tiempos y están dentro de las especificaciones de la hoja de datos de FRAM.

Asegurando la secuencia de potencia

@jippie.

1. La palanca de cambio de nivel I2C se pone en modo de tres estados antes de insertar la tarjeta que incorpora el FRAM. Las señales FRAM_SDA y FRAM_SCL se bajan.
2. Después de insertar la "tarjeta FRAM", se agrega un retraso de 100 ms para garantizar que la fuente de alimentación se estabilice (se requieren al menos 11 ms antes de la primera condición de inicio de acuerdo con la hoja de datos).
3. La palanca de cambio de nivel I2C está activada.
4. Se agrega una demora de 1 ms para garantizar que el cambiador de nivel I2C esté activado y que las líneas se levanten (~ 4us requeridos por la hoja de datos). Se extraen las señales FRAM_SDA y FRAM_SCL.
5. Se accede al FRAM.

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

El problema aún ocurre.

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

@gbarry.

Traté de detener antes del inicio repetido durante la transferencia de bytes. Medí la transferencia de bytes con el osciloscopio: la condición STOP seguida de la condición START está bien.

Desafortunadamente, esta solución no resuelve el problema.

Pensamientos

Este problema ocurre solo después de que la tarjeta que incrusta la FRAM está conectada. Ejecuté algunos miles de acceso de lectura exitoso (direccionamiento y lectura de esclavos) después de que la "tarjeta FRAM" se inserta y se direcciona correctamente.

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

¿Tienes alguna otra idea o sugerencia?

EDITADO (2013-04-18)

El problema parece estar resuelto.

Reemplacé el conector del módulo FRAM y encontré una manera de hacer mediciones directamente en el FRAM. Parece que todo funciona bien con este nuevo conector.

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

Aunque usted dice que sus comunicaciones están terminadas correctamente antes de la inserción o extracción, puede valer la pena probar esta solución, ya que existe una situación en la que el bus I2C puede generar problemas después de reiniciar solo uno de los dispositivos en el bus.

Antes de inicializar el hardware Master I2C, configure SDA como entrada y pruebe SDA bajo.

Si es bajo, configure el pin SCL alto.

Luego, cambie el pin SCL hacia arriba y hacia abajo hasta que SDA se ponga alto (es decir, desconecte los bits restantes que los periféricos aún podrían estar 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 resolverá tu problema, ¡pero resolvió el mío!

Para el marco:

• primero conecte GND y Vcc;
• luego asegúrese de que A1, A2 y WP tengan el nivel correcto;
• solo entonces conecte los pines de datos.

Conectar otros pines que no sean la fuente de alimentación antes de encender el chip puede causar problemas.

10k parece un poco grande para tus dominadas, y tus bordes de ataque se ven lentos. Reduzca las resistencias a aproximadamente 3k y vea si eso ayuda.

Además, ¿por qué la tensión fuera de la deriva con el tiempo?

¿Hay alguna posibilidad de que haya algo más tratando de hablar con esa junta? Tuve un problema así una vez; Podría obtener un reconocimiento el 60% del tiempo, pero no recuerdo haber visto nunca una colisión. Sospecho que el i2c que me proporcionaron estaba de alguna manera aislado del bus interno real. Podría ejecutarlo continuamente, y simplemente dejaría caer el 30% de los mensajes. El problema desapareció en el momento en que comenzamos a hablar directamente con el dispositivo (una fuente de alimentación) sin el "plano posterior" que interviene.

No veo una secuencia de detención después de su error NAK. ¿Supongo que tienes un punto de interrupción que detiene el programa en ese punto?

Por último, si crees que eres el único en el autobús, también puedes intentar reemplazar el inicio repetido con una parada / inicio. He visto dispositivos (especialmente FPGA personalizados) que no sabían cómo manejar el RS.

[En respuesta al comentario]: Hay muchas cosas que no dijiste sobre la placa FRAM, como si es solo memoria o un subsistema completo. Pero si puede poner el 'alcance justo en los cables del dispositivo i2c que le está causando problemas, y todavía ve lo que se muestra, entonces descartaría interferencia. I2C es lo suficientemente simple como para que si ve las señales correctas en la entrada, el chip debería funcionar correctamente a menos que tenga un problema interno.

En particular, quieres estar en el lado FRAM de esa palanca de cambios de nivel. Una interrupción en la señal es más probable que algo que ocurra que normalmente se consideraría como una colisión.

Señalaré que un ciclo NAK no se puede distinguir de un chip que simplemente no está allí. Las EEPROM harán esto para indicar que están ocupadas. Busqué el tiempo de escritura en FRAM y es más rápido que un solo bit de datos i2c ... así que eso no es un problema.

Dado que el problema, cuando se reproduce, es una falla permanente que solo se elimina al quitar y volver a insertar el dispositivo, entonces es una de dos cosas: el dispositivo está en un mal estado del cual solo se recupera en un ciclo de encendido, o hay poco contacto.

Si el dispositivo entra en un mal estado desde el cual se recupera en un ciclo de alimentación, puede tener un circuito adicional que permita que su MCU apague el dispositivo. Luego, el firmware, al no recibir reconocimiento del dispositivo, puede ejecutar un procedimiento de recuperación mediante el cual apaga el chip por un tiempo, lo enciende nuevamente y luego lo intenta nuevamente.

Si se trata de un contacto deficiente, entonces quizás tenga que mirar la confiabilidad del conector y encontrar algo mejor. Si usa 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 operador que trabaja con el dispositivo debe ser consciente del posible problema con la inserción de la tarjeta, y es posible que deba volver a colocarlo para que funcione correctamente.

Su dispositivo principal podría tener una forma de activar una alarma que indica que no puede hablar con el FRAM: un LED de "problema" en un panel y / o un pitido o lo que sea. O al revés: algo de luz que se enciende, dando al usuario comentarios de que el FRAM ha sido aceptado y se ha establecido la comunicación. Si el FRAM está lejos del dispositivo maestro, la luz puede ubicarse en el módulo FRAM: otro chip I2C que controla un LED.

La naturaleza esporádica del problema sugiere que podría ser un problema de tiempo.

La hoja de datos enumera dos conjuntos de temporizaciones, una para "Modo estándar" y otra para "Modo rápido". Según sus mediciones, parece que está en el límite de los tiempos del "Modo estándar". No puedo decir, al leer la hoja de datos, cómo se coloca exactamente el chip en cualquier modo.

No asumiría que su dispositivo está en modo rápido. ¿Puede reducir los tiempos en un factor de 2-4, asegúrese de estar dentro de los tiempos del modo estándar para el tiempo de espera de la condición de inicio, el período de reloj alto y el período de reloj bajo y ver si este problema aún ocurre?

¿Tienes un 24c04a, b o c? Si es un c04a, era un diseño robusto. La parte b tiene sensibilidad a las rampas de la fuente de alimentación. ¿Qué desacoplamiento tienes en pin8 a gnd? Iba a decir algo sobre los niveles de señal, pero veo que usas un traductor de nivel. Es posible que desee comprobar que no obtiene un error en SCL que el chip interpretaría como un reloj adicional.