¿El controlador EEPROM I2C se colgó durante la prueba de ESD?

Si bien realmente no podemos saber qué causa su bloqueo, hay un escenario probable en el que probablemente debería mirar primero.

Es probable que un pulso ESD provoque una transición no intencionada en las señales digitales. En un sistema I2C, si ESD hace que aparezca un pulso en SDA cuando el bus está inactivo, esto se interpretará como una condición de inicio. Dependiendo de cómo se implementen los controladores I2C periféricos y uC, podrían esperar indefinidamente a que se complete la transacción iniciada antes de estar listos para ejecutar una nueva transacción (por ejemplo, una generada por su código).

Por supuesto, un pulso adicional en SCL o SDA cuando una transacción I2C está en curso (tal vez detectada por solo uno de los dos chips involucrados) también podría hacer que los dos chips pierdan el rastro del estado de la transacción y causen problemas.

Entonces, si está buscando dónde se podría mejorar su hardware para evitar esta falla, asegúrese de que sus líneas SDA y SCL estén enrutadas sobre planos de tierra continuos, evite una distancia de enrutamiento excesiva y posiblemente reduzca los valores de la resistencia pull-up. También asegúrese de que el uC y el periférico tengan condensadores de derivación adecuados.

Si está buscando soluciones de software para esta falla, si puede detectar la condición de bloqueo, puede intentar restablecer el bloque I2C de uC o enviar pulsos SCL (¿8 o 10 o 16?) con SDA liberado alto para borrar el I2C máquina de estado en el periférico. Esto podría requerir el reinicio de las E/S de uC para que sean GPIO y el bit-banging si el bloque uC I2C también está atascado.

Parece que las condiciones de su prueba están causando que el código del controlador I2C, o el propio módulo I2C, entren en un estado del que no pueden recuperarse.

Intente poner un tiempo de espera en los bucles para detectar una falla; si ocurre una falla, reinicie tanto el hardware como los controladores I2C.

El tiempo de espera más simple de implementar sería contar la cantidad de veces que ha probado las distintas banderas y cuando ese conteo expire, salga con un código de error.

Un enfoque más complicado (es decir, útil) sería monitorear un temporizador de hardware que se ejecuta en segundo plano. Cuando comience un bucle, registre el valor actual del temporizador más el tiempo de espera que desee; verifique el temporizador al comienzo de cada bucle y, si excede su valor precalculado, salga con un código de error.

¿Qué podría salir mal con el controlador (bus MSP430F6438 I2c) o el esclavo (EEPROM basado en I2c), lo que hace que el código se cuelgue en uno de los bucles que verifica el bus ocupado, la bandera de tránsito, reconoce la bandera recibida?

Es difícil saber qué hace que su sistema se cuelgue. Pero puedes hacer algo para averiguar dónde cuelga el código. Si es posible, puede imprimir algún mensaje de depuración en la pantalla o en su PC mediante USART u otra interfaz. Puede agregar alguna "sonda" en su código, cuando ingresa una función o ingresa un ciclo, imprime algún mensaje en su PC, luego puede saber dónde cuelga el código.

Sin embargo, es un buen hábito agregar tiempo de espera a un bucle que puede "muerto".

Ordenar el código escamoso. Si el código se bloquea debido a una circunstancia imprevista, modifique el código para que se atienda la circunstancia imprevista. Como último recurso, intente con un temporizador de vigilancia de hardware, aunque esto solo funcionará (sin cambio de código) si hay algunas líneas externas que pueden decodificarse que indican el problema. También podría considerar alguna protección/filtrado EMI en el cableado interno y tal vez incluso echar un vistazo al plano de tierra alrededor del micro y la EEPROM.