Dirección esclava I2C no reconocida (a veces)

11

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): ingrese la descripción de la imagen aquí

Dirección FRAM I2C no reconocida (la dirección del esclavo se envía correctamente): ingrese la descripción de la imagen aquí

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:

Esquema 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.

johsey
fuente
¿Puedes publicar el esquema? Pruebe una frecuencia de bus más lenta para ver si eso hace la diferencia.
Suirnder
¿Ha ocurrido el problema solo después de insertarlo y no en otros momentos? ¿Qué tan pronto es "justo después"?
Kaz
Además de los otros experimentos, puedes intentar eliminar a los otros esclavos y ver si eso afecta el comportamiento.
Ben Gartner
¿Están los dos pines de dirección correctamente colocados hacia abajo o se dejan flotando?
fm_andreas
@Suirnder He publicado el esquema en mi respuesta.
johsey

Respuestas:

6

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!

Buzby
fuente
No es una mala idea agregar este "algoritmo de recuperación de bus" antes de inicializar el maestro. Lo implementaré. Gracias.
johsey
2

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.

jippie
fuente
2

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?

Scott Seidman
fuente
Reduje las resistencias pull-up a 3.3k y eso no ayuda. No tengo idea con respecto a esta deriva.
johsey
Parece pequeño en la pantalla, pero creo que tiene unos 250 mV. Es posible que tenga un problema de suministro de energía en el lado de 3.3V
Scott Seidman
Tienes razón, la deriva es de aproximadamente 300 mV en ambos lados de la palanca de cambios de nivel I2C. La fuente de alimentación de + 3.3V parece funcionar bien (no hay deriva en su salida cuando se produce la deriva en la señal SCL). ¿Podría estar relacionado con el cambiador de nivel I2C?
johsey
No estoy seguro en absoluto. ¿De dónde viene 3.3V? Convertidor de conmutación? En cualquier caso, es sospechoso. ¿Está dibujando la corriente MÍNIMA requerida por el dispositivo que proporciona 3.3V según la hoja de datos? De lo contrario, cargue su suministro con una resistencia. ¿Qué sucede si espera uno o dos segundos antes de comenzar la comunicación?
Scott Seidman
3.3V proviene de un SMPS (LM3103MH de TI). No soy un experto en fuentes de alimentación, pero como entendí, con este dispositivo, no hay una corriente mínima requerida, ya que puede funcionar en modo de conducción discontinua con una carga ligera. El mismo problema ocurre si espero dos segundos antes de comenzar la comunicación.
johsey
2

¿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.

gbarry
fuente
Solo hay un maestro en el bus I2C y la placa que incorpora el FRAM solo está conectada a este bus. Por lo tanto, creo que no hay posibilidad de que algo más esté tratando de hablar con él. Sí, puse un punto de interrupción antes de la secuencia de parada. Intentaré reemplazar este inicio repetido con un stop / start como usted sugiere y lo probaré nuevamente. Según su hoja de datos, el FRAM debe admitir el inicio repetido. ¿Crees que si aíslo el FRAM (por ejemplo, en un bus I2C dedicado), esto podría resolver este problema?
johsey
El tablero FRAM incorpora solo el FRAM. Es un tablero "similar a ISA". Es difícil medir las señales directamente en los pines FRAM ya que esta tarjeta está incrustada en una pieza de plástico. De todos modos, trataré de encontrar una manera de medir estas señales lo más cerca posible del FRAM.
johsey
Llegar al lado FRAM del U13 sería un gran paso.
gbarry
2

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.

Kaz
fuente
0

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?

Ben Gartner
fuente
Mi dispositivo está en el "Modo estándar" (frecuencia SCL de 100 kHz). De hecho, esta frecuencia está en el borde de este modo. Intentaré reducirlo en un factor de dos y hacer algunas pruebas.
johsey
0

¿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.

gman
fuente
3
¿Escribiste esto en un teléfono celular viejo con solo una interfaz de nueve botones?
angelatlarge
El FRAM utilizado es el FM24C04B . ¿De dónde sacaste esta información sobre la sensibilidad al poder de esta memoria? ¿Me puede dar más entradas? No hay desacoplamiento en el pin 8. El diseño de este módulo se realizó hace unos años y tenemos que consumir toda la producción. Según las mediciones realizadas con el osciloscopio, parece que no hay fallas en la línea SCL cuando el módulo FRAM está conectado y el cambiador de nivel está activado.
johsey
1
Me doy cuenta de que esta respuesta es muy tardía, pero mi información sobre la sensibilidad de Vcc proviene de ser soporte de aplicaciones para Ramtron, hace años. No recuerdo los detalles exactos, pero bajo ciertas velocidades y temperaturas de rampa, el chip esencialmente se bloquea y no permite la comunicación I2C hasta que se enciende con una rampa 'buena'. No tener una tapa de desacoplamiento cerca del chip no es bueno. Puede descubrir que el uso del desacoplamiento 0.1uF vs 10uF cambia la rampa de Vcc donde uno funciona y el otro no. @angelatlarge, sí, lo siento, escribí mi primera respuesta desde un teléfono.
gman