@@ -32,7 +32,14 @@ In order to use properly the I2C bus a pull-up circuit should be implemented. Th
# _Deadlocks are a feature, not a bug!_
Kidding, they are not. Unluckly the I2C bus can get in a locked state in particular conditions. These cases, their origin and the solutions provided in the driver will be explained in the following paragraphs.
Kidding, they are not. Unluckly the I2C bus can get in a locked state in particular conditions. If we are in the situation where the slave is pulling down the SDA but is no longer receiving clock signals, the slave won't ever stop pulling SDA down, causing all the other devices to see the bus as busy. This means that no device can become a master, so on the SCL line nobody will issue the clock cycles the slave is expecting.
This could happen when the state machine inside the slave is messed up due to lost clock cycles; in real life this could happen for:
- A reset of the master without a power-cycle;
- A glitch on the SCL line, causing a loss of at least one clock cycle;
- The breaking/disconnection of the SCL line;
- Master peripheral deadlock:
- Slave bus deadlock:
\ No newline at end of file
The locked state manifests as in the following image, so with the SCL line released (high state) and the SDA line pulled down (low state).
The recovery of the locked state is performed doing the CPR to the slave, so literally forcing a set of clock cycles on the SCL line (changing the SCL pin to the OUTPUT mode and forcing high/low the line at the right frequency). This injects to the slave the necessary clock cycles in order to end the current transaction and restore to idle mode.
