La dirección del esclavo I2C no se reconoce (a veces)

Aunque 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 dar problemas después de un restablecimiento de solo uno de los dispositivos en el bus.

Antes de inicializar el hardware del Master I2C, configure SDA como entrada y realice una prueba de SDA baja.

Si está bajo, establezca el pin SCL alto.

Luego, mueva el pin SCL bajo y alto hasta que el SDA se ponga alto (es decir, elimine los bits restantes que los periféricos aún estén intentando enviar). Esto no puede llevar 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 FRAM:

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

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

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

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

¿Hay alguna posibilidad de que haya algo más que intente hablar con esa junta? Tuve un problema así una vez; Podría recibir un acuse de recibo el 60% del tiempo, pero no recuerdo haber visto nunca una colisión. Sospecho que el i2c que me proporcionaron estaba aislado del verdadero bus interno. 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 "panel posterior" intermedio.

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

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 la RS.

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

En particular, desea ingresar al lado de FRAM de la palanca de cambios de nivel. Una interrupción en la señal es más probable que ocurra algo que normalmente se consideraría 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 ocupados. 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 un fallo permanente que solo se elimina al quitar y volver a insertar el dispositivo, entonces es una de dos cosas: el dispositivo está en un estado malo del cual solo se recupera en ciclo de energía, o hay un mal contacto.

Si el dispositivo entra en un mal estado del que se recupera en un ciclo de energía, puede tener un circuito adicional que le permita a su MCU apagar el dispositivo. Luego, el firmware, al no recibir confirmación del dispositivo, puede ejecutar un procedimiento de recuperación mediante el cual apaga el chip por algún tiempo, lo enciende nuevamente y luego lo intenta de nuevo.

Si se trata de un contacto deficiente, entonces quizás tenga que ver la confiabilidad del conector y encontrar algo mejor. Si usa el mismo conector para obtener más de estos tableros, 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 de que es posible que tenga que volver a colocarla para que funcione correctamente.

Su dispositivo principal podría tener una manera de activar 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: se enciende algo de luz, que proporciona al usuario una respuesta de que se ha aceptado el FRAM 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 tratarse de un problema de tiempo.

La hoja de datos enumera dos conjuntos de tiempos, uno para el "Modo estándar" y otro 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, por omitir 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 a 4, asegurarse de estar dentro 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 persiste?

¿Hace h h a 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 hace usted hv 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 se produce un error en SCL que el chip interpretaría como un reloj adicional.