¿Qué sucede si SCL de I2C está conectado a GND? ¿También arruina el reloj de nuestros controladores?
Estoy usando PIC24 con tres I2Cs. Si uno de I2C, GND y SCL se cortocircuitan. Dejo de obtener los datos de mis registros de depuración.
¿Qué sucede si SCL de I2C está conectado a GND? ¿También arruina el reloj de nuestros controladores?
Estoy usando PIC24 con tres I2Cs. Si uno de I2C, GND y SCL se cortocircuitan. Dejo de obtener los datos de mis registros de depuración.
¿Qué sucede si SCL de I2C está conectado a GND?
El autobús no funcionará. Esto debería haber sido obvio hasta el punto de que esta es una pregunta tonta.
Los datos se transfieren de forma síncrona con el reloj. Cuando el reloj está en corto, no hay pulsos de reloj. Por lo tanto se deduce que los datos no pueden ser transferidos. Una vez más, esto realmente debería haber sido obvio.
Cortocircuitar una línea IIC a tierra no causa daño físico. Esto se debe a que ambas líneas se levantan pasivamente y se bajan activamente. Los dispositivos solo manejan bajo, no alto. No habrá corriente excesiva ni daños.
¿Qué sucede si SCL de I2C está conectado a GND?
El bus I2C no puede transferir ningún dato durante ese tiempo. Esto es similar a una condición válida, pero normalmente de corta duración (vea la discusión sobre "alargamiento del reloj" a continuación).
¿También arruina el reloj de nuestros controladores?
No. El reloj MCU (interno o externo) es independiente de esa señal I2C.
Estoy usando PIC24 con tres I2Cs. Si uno de I2C, GND y SCL se cortocircuitan. Dejo de obtener los datos de mis registros de depuración.
Parece que tal vez usted es un probador, a quien se le ha dicho que simule algunos fallos, incluido el cortocircuito de SCL a Gnd y luego informe si el dispositivo (incluido el registro de depuración) se comporta normalmente. Sería útil si agrega algún contexto a su pregunta sobre por qué está haciendo esa prueba.
Sin embargo, incluso sin más información, es posible sugerir una hipótesis acerca de por qué ves el comportamiento informado.
"Alargamiento del reloj" es una parte opcional de la especificación I2C , donde El dispositivo esclavo puede reducir el nivel de SCL (que en realidad es lo mismo que su prueba), para solicitar al maestro I2C que detenga la actividad del bus I2C. Si el código maestro I2C que se ejecuta en su PIC24 está diseñado para ser compatible con esclavos I2C que realizan el estiramiento del reloj, ese código maestro I2C puede simplemente realizar un bucle (tal vez indefinidamente ) esperando que se libere el esclavo I2C (es decir, detenerse tirando hacia abajo) la señal SCL.
En ese caso, el firmware que se ejecuta en el PIC24 no sabe que el alargamiento del reloj aparente se está realizando al usted cortocircuitando SCL a Gnd y podría continuar por mucho más tiempo que el típico real I2C reloj estiramiento. En una arquitectura de firmware de "súper bucle" muy simple, sin tiempos de espera, etc., esa condición de alargamiento del reloj podría hacer que otras partes del firmware de PIC24 (por ejemplo, el código de registro de depuración) no se ejecuten. Eso explicaría por qué "dejas de obtener los datos de mis registros de depuración". Todo depende del firmware de PIC24.
Resumen : sería posible escribir el firmware de PIC24 donde mantener baja la señal I2C SCL causaría otras partes del firmware (por ejemplo, incluyendo el registro de depuración) para no ser ejecutado.
Debe investigar más el firmware de PIC24 (o hacer que el escritor del firmware lo haga, si esa persona no es usted) para considerar si esta hipótesis es la explicación de su comportamiento observado.