¿Cómo resolver el problema del bloqueo del dispositivo I2C?
En circunstancias normales, el protocolo del bus I2C puede garantizar operaciones normales de lectura y escritura en el bus. Sin embargo, bajo ciertas condiciones anormales, el bus I2C puede estar bloqueado. Por ejemplo, un reinicio repentino del controlador principal, una interferencia en el bus I2C o un suministro de energía anormal pueden causar que el bus I2C se bloquee.
Durante las operaciones de lectura y escritura del dispositivo maestro I2C, el dispositivo maestro controla SCL para generar 8 pulsos de reloj después de la señal de inicio. Luego baje la señal SCL a un nivel bajo. En este momento, el dispositivo esclavo emite una señal de respuesta y baja la señal SDA a un nivel bajo. Si el dispositivo maestro se reinicia de manera anormal en este momento, SCL se liberará a un nivel alto. . En este momento, si el dispositivo esclavo no se reinicia, continuará la respuesta I2C y llevará el SDA a un nivel bajo. La señal de respuesta no finalizará hasta que SCL alcance un nivel bajo. Para el dispositivo maestro I2C, las señales SCL y SDA se detectan después del reinicio. Si se encuentra que la señal SDA tiene un nivel bajo, se considerará que el bus I2C está ocupado y esperará a que las señales SCL y SDA alcancen un nivel alto. . De esta manera, el dispositivo maestro I2C está esperando que el dispositivo esclavo libere la señal SDA y, al mismo tiempo, el dispositivo esclavo I2C está esperando que el dispositivo maestro baje la señal SCL para liberar la señal de respuesta. están esperando el uno al otro y el bus I2C entra en un estado de punto muerto.
De manera similar, cuando I2C realiza una operación de lectura, el dispositivo esclavo I2C genera datos después de responder. Si el dispositivo maestro I2C se reinicia de manera anormal en este momento y el bit de datos emitido por el dispositivo esclavo I2C es exactamente 0, también provocará que el I2C El bus entre en un estado de punto muerto.
Cuando la placa central ARM de Guangzhou Zhiyuan Electronics utiliza equipo IIC, ¿cómo recuperar el punto muerto del bus cuando se encuentra un punto muerto? Los métodos comunes son los siguientes:
(1) ¿Intenta utilizar la entrada de reinicio? el dispositivo esclavo I2C, a partir de las causas del interbloqueo del bus I2C, podemos encontrar que una condición necesaria para el interbloqueo del bus I2C es que el dispositivo maestro se reinicie pero el dispositivo esclavo no se reinicie. Si el dispositivo esclavo usa un chip con una entrada de reinicio, conecte las señales de reinicio de los dispositivos maestro y esclavo juntos. Cuando ocurra un evento de reinicio externo, los dispositivos maestro y esclavo se reiniciarán al mismo tiempo, de modo que se producirá un punto muerto en el bus I2C. no ocurrir. Las deficiencias de este método también son obvias. En primer lugar, la mayoría de los dispositivos esclavos I2C no tienen una entrada de reinicio, lo que limita en gran medida la selección del dispositivo. En segundo lugar, este método no tiene ningún efecto sobre el reinicio causado por el dispositivo de vigilancia integrado.
(2) Conecte las fuentes de alimentación de todos los dispositivos I2C esclavos y conéctelos a la fuente de alimentación principal a través del tubo MOS. El encendido y apagado del tubo MOS lo implementa generalmente el dispositivo maestro I2C. Hablando, los dispositivos maestros I2C son procesadores con unidades informáticas. Las funciones de control se pueden implementar a través del GPIO del procesador. Cada vez que se reinicia el dispositivo maestro, el programa en ejecución controla el GPIO para apagar el MOS, lo que hace que el dispositivo esclavo pierda energía. Luego, después de un retraso, el tubo MOS se enciende para encender el dispositivo esclavo, logrando así el efecto de forzar el reinicio del dispositivo esclavo. Este método puede compensar las deficiencias del primer método, pero aumentará la complejidad del diseño de la fuente de alimentación y afectará la integridad de la fuente de alimentación durante el diseño del diseño. También requiere cambios en el código de arranque subyacente del procesador, lo que afecta; la versatilidad y portabilidad del software subyacente.
(3) Diseñe la función de vigilancia en el dispositivo esclavo I2C. Cuando el dispositivo esclavo I2C detecta que está en estado de respuesta o que la salida de bajo nivel excede el tiempo especificado, el mecanismo de vigilancia activa y reinicia el dispositivo esclavo I2C. En este caso, no es necesario agregar un diseño de hardware adicional, pero se requiere que el dispositivo esclavo I2C tenga funciones programables, lo cual es más adecuado cuando el dispositivo esclavo es un microcontrolador o CPLD.
(4) Agregue el programa de recuperación del bus I2C en el dispositivo maestro I2C. Después de restablecer cada dispositivo maestro I2C, si se detecta que la línea de datos SDA está baja, la línea de reloj SCL en I2C se controla para generar 9 pulsos de reloj (para datos de 8 bits), de modo que el dispositivo esclavo I2C pueda ser operación de lectura suspendida para recuperarse del estado de punto muerto. Este método tiene grandes limitaciones porque la mayoría de los módulos I2C del dispositivo maestro se implementan mediante circuitos de hardware integrados. El software no puede controlar directamente la señal SCL para simular la generación de pulsos de reloj. Con este método, IO se puede utilizar para simular I2C y el reloj SCL es fácil de controlar.
(5) Agregue un dispositivo de recuperación de bus adicional al bus I2C. Este dispositivo monitorea el bus I2C.
Cuando el dispositivo detecta que la señal SDA está baja durante más del tiempo especificado, genera 9 pulsos de reloj en el bus SCL para permitir que el dispositivo esclavo I2C complete la operación de lectura y se recupere del estado de interbloqueo. El dispositivo de recuperación de bus debe tener una función de programación y esta función generalmente se puede implementar mediante un microcontrolador o CPLD.
(6) Conecte un búfer I2C con recuperación de interbloqueo en I2C.