¿Se ha bloqueado el controlador EEPROM I2C durante la prueba ESD?

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

Es probable que un pulso ESD provoque una no deseada en la transición de una señal digital. 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 uC y I2C periféricos, podrían esperar indefinidamente a que se complete la transacción iniciada antes de que estén listos para ejecutar una nueva transacción (por ejemplo, una generada por su código).

Por supuesto, un impulso adicional en SCL o SDA cuando una transacción I2C está en curso (tal vez detectada por uno solo 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 podría mejorarse su hardware para evitar este fallo, asegúrese de que las líneas SDA y SCL se enruten sobre planos de tierra intactos, evite el exceso de distancia de enrutamiento y, posiblemente, reduzca los valores de resistencia de pull-up. Asegúrese también de que la unidad de control remoto y el periférico tengan capacitores de derivación adecuados.

Si está buscando soluciones de software para este fallo, si puede detectar la condición de bloqueo, puede intentar restablecer el bloque I2C de la unidad uC, o enviar pulsos SCL (8 o 10 o 16?) con SDA alto a Borrar la máquina de estados I2C en el periférico. Esto podría requerir que se restablezcan los iC de uC para que sean GPIO's y bit banging si el bloque uC I2C también está bloqueado.

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

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

El tiempo de espera más sencillo de implementar sería contar la cantidad de veces que se probaron los distintos indicadores y cuando el recuento 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 se inicia un bucle, registre el valor actual del temporizador más el tiempo de espera que desee; compruebe el temporizador al comienzo de cada ciclo y si supera su valor calculado previamente, salga con un código de error.

  

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

Es difícil decir cuál es la causa del bloqueo del sistema. Pero puedes hacer algo para averiguar dónde colgar 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 un poco de "sonda" en su código, cuando ingrese una función o ingrese un ciclo, imprima un mensaje en su PC, luego puede saber dónde está colgado el código.

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

Ordenar el código escamoso. Si el código se cuelga debido a una circunstancia imprevista, modifíquelo para que se atienda la circunstancia imprevista. Como último recurso, intente un temporizador de vigilancia de hardware, aunque esto solo funcionará (sin cambio de código) si hay algunas líneas externas que se pueden decodificar que indiquen el problema. También puede considerar algún tipo de protección / filtrado de EMI en el cableado interno e incluso echar un vistazo al plano de tierra alrededor de la micro y EEPROM.