Dirección de esclavo I2C no reconocida (a veces)

Aunque dice que sus 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 reiniciar solo uno de los dispositivos en el bus.

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

Si es bajo, configure el pin SCL alto.

Luego cambie el pin SCL bajo y alto hasta que SDA suba (es decir, desconecte los bits restantes que los periféricos aún podrían estar tratando de 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 resolvió el mío!.

Para la FRAM:

• 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 que se encienda el chip puede causar problemas.

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

Además, ¿por qué el voltaje de apagado se desvía con el tiempo?

¿Hay alguna posibilidad de que haya algo más tratando de hablar con esa placa? Tuve un problema como ese una vez; Podría recibir un ACK el 60% del tiempo, pero no recuerdo haber podido ver nunca una colisión. Sospecho que el i2c que me proporcionaron estaba de alguna manera aislado del bus interno real. Podría ejecutarlo de forma continua, y solo eliminaría 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 "backplane" intermedio.

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

Por último, si cree que es el único en el autobús, también puede intentar reemplazar el inicio repetido con un inicio/parada. He visto dispositivos (especialmente FPGA personalizados) que no sabían muy bien 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 colocar el 'visor justo en los cables del dispositivo i2c que le está dando problemas, y aún ve lo que se muestra en la imagen, entonces descartaría la interferencia. I2C es tan simple que si ve las señales correctas en la entrada, entonces el chip debería funcionar correctamente a menos que tenga un problema interno.

En particular, desea obtener el lado FRAM de ese cambiador de nivel. Una interrupción en la señal es más probable que algo que normalmente se consideraría como una colisión.

Señalaré que un ciclo NAK es indistinguible 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 soluciona al quitar y volver a insertar el dispositivo, entonces es una de dos cosas: el dispositivo está en mal estado del cual solo se recupera en un ciclo de energía, o hay mal contacto.

Si el dispositivo entra en mal estado del cual se recupera en un ciclo de encendido, 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 durante un tiempo, lo vuelve a encender y luego vuelve a intentarlo.

Si se trata de un mal contacto, entonces tal vez deba 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 problema potencial con la inserción de la tarjeta y que es posible que deba volver a colocarla para que funcione correctamente.

Su dispositivo principal podría tener una forma de generar una alarma que indique que no puede comunicarse con la FRAM: un LED de "problema" en un panel y/o un pitido o lo que sea. O al revés: alguna luz que se enciende, informando al usuario de que se ha aceptado la FRAM y se ha establecido la comunicación. Si la FRAM está lejos del dispositivo maestro, la luz se puede ubicar en el módulo FRAM: otro chip I2C que impulsa 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 tiempos, uno para el "Modo estándar" y otro para el "Modo rápido". Según sus medidas, parece que está en el límite de los tiempos del "Modo estándar". Al hojear la hoja de datos, no puedo decir cómo se coloca exactamente el chip en cualquiera de los modos.

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

¿Tienes un 24c04a, b o c? Si es un c04a, era un diseño robusto. La parte b tiene sensibilidad a las rampas 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 verificar que no tenga una falla en SCL que el chip interpretaría como un reloj adicional.