SLAZ149I October 2012 – May 2021 MSP430F168
I2C Module
Functional
Glitch on SCL between I2C communication cycles can corrupt the state machine in I2C master mode.
When the USART is configured for I2C communication (U0CTL.I2C, SYNC, and I2CEN are set) and the module is configured as an I2C master (U0CTL.MST=1), the I2C module is automatically switched to slave mode following the I2C master's generation of a stop condition. If SCL is then pulled low and released again, the following device behavior can be observed:
1) When SCL is pulled low after the stop condition is generated and while ARDYIFG is not yet set, then ARDYIFG is not set as expected and ALIFG is set. SCL is released. See workaround 1 for details on how to handle this condition.
2) When SCL is pulled low at the same time as ARDYIFG is being set, ALIFG is set and SCL is released. Subsequent communication can result in an immediate ALIFG generation. See workaround 2 for details on how to handle this condition.
3) When SCL is pulled low after ARDYIFG is set but before ARDYIFG is cleared, ALIFG is not set, but SCL is held low by the master. An SCL hang-up condition occurs. See workaround 3 for details on how to handle this condition.
4) When SCL is pulled low after ARDYIFG is cleared, the module operates as intended. The ALIFG flag is not set and SCL is released.
1. ALIFG must be processed. Data bytes are not affected.
2. ALIFG must be processed. Data bytes are not affected. To avoid a second ALIFG, clear I2CEN and re-set I2CEN before new communication begins.
3. Clear I2CEN and re-set I2CEN before new communication begins to clear the SCL hang-up.