Soy muy nuevo en electrónica y he entrado en el territorio del bus I2C. Quiere comprender el comportamiento de los dispositivos compatibles según la especificación del protocolo I2C.
Una condición según el enlace a continuación es cuando un controlador maestro se reinicia en medio de una transacción. Es decir, el esclavo comprometido no sabe qué hacer ahora.
https://www.i2c-bus.org/i2c-primer/analysing-obscure-problems/blocked-bus/
No entiendo como se cuelgan estas llamadas de bus? El maestro que se reinició siempre podría iniciar una nueva transacción y los esclavos deberían poder leerla.
¿Hay alguna otra forma además de lo explicado anteriormente para provocar un bloqueo del autobús?
¿Puede tal problema ser causado por el controlador de software?
El maestro no puede emitir una condición de inicio o parada mientras cualquier esclavo esté manejando SCL o SDA. Si solo hay un esclavo en el bus, el peor de los casos sería cuando el maestro se reinicia justo después de que el esclavo haya recibido una solicitud de "lectura", estaba en proceso de reconocerlo y todo está configurado para enviar un "0" en respuesta. En ese escenario, el primer reloj avanzaría más allá del acuse de recibo, y los siguientes ocho avanzarían más allá de los bits de datos, y el dispositivo conduciría SDA continuamente hasta que reciba el noveno reloj. Sin embargo, después de que el reloj sube y luego baja por novena vez, el dispositivo hace flotar el bus (si no lo ha hecho antes) para buscar un acuse de recibo del maestro.
Si hay varios dispositivos esclavos, un bus podría bloquearse permanentemente si dos dispositivos piensan que han recibido comandos para leer una cadena de cero bytes, pero (posiblemente porque el maestro se reinició en un momento que resultó en un "runt " pulso en SCL que fue lo suficientemente largo para ser visto por un esclavo pero no por el otro) los dos esclavos liberan el bus en diferentes momentos cuando buscan confirmaciones del maestro.
Eugenio Sh.
TonyM
el fotón
causa última