SPRUII0F May 2019 – June 2024 TMS320F28384D , TMS320F28384D-Q1 , TMS320F28384S , TMS320F28384S-Q1 , TMS320F28386D , TMS320F28386D-Q1 , TMS320F28386S , TMS320F28386S-Q1 , TMS320F28388D , TMS320F28388S
The I2C slave can extend the transaction by pulling the clock low periodically to create a slow bit transfer rate. The I2C module has a 12-bit programmable counter that is used to track how long the clock has been held low. The upper 8 bits of the count value are software programmable through the I2C Master Clock Low Time-out Count (I2CMCLKOCNT) register. The lower four bits are not user visible and are 0x0. The CNTL value programmed in the I2CMCLKOCNT register has to be greater than 0x01. The application can program the eight most-significant bits of the counter to reflect the acceptable cumulative low period in transaction. The count is loaded at the START condition and counts down on each falling edge of the internal bus clock of the master. Note that the internal bus clock generated for this counter keeps running at the programmed I2C speed even if SCL is held low on the bus. Upon reaching terminal count, the masterstate machine forces ABORT on the bus by issuing a STOP condition at the instance of SCL and SDA release.
As an example, if an I2C module is operating at 100-kHz speed, programming the I2CMCLKOCNT register to 0xDA translates to the value 0xDA0 since the lower four bits are set to 0x0. This translates to a decimal value of 3488 clocks or a cumulative clock low period of 34.88 ms at 100 kHz.
The CLKRIS bit in the I2C Master Raw Interrupt Status (I2CMRIS) register is set when the clock time-out period is reached, allowing the master to start corrective action to resolve the remote slave state. In addition, the CLKTO bit in the I2C Master Control/Status (I2CMCS) register is set; this bit is cleared when a STOP condition is sent or during the I2C master reset. The status of the raw SDA and SCL signals are readable by software through the SDA and SCL bits in the I2C Master Bus Monitor (I2CMBMON) register to help determine the state of the remote slave.
In the event of a CLTO condition, application software must choose how the application intends to attempt bus recovery. Most applications attempt to manually toggle the I2C pins to force the slave to let go of the clock signal (a common solution is to attempt to force a STOP on the bus). If a CLTO is detected before the end of a burst transfer, and the bus is successfully recovered by the master, the master hardware attempts to finish the pending burst operation. The behavior of the bus varies depending on the state of the slave after bus recovery. If the slave resumes in a state where the slave can acknowledge the master (essentially, where it was before the bus hang), it continues where it left off. However, if the slave resumes in a reset state (or if a forced STOP by the master causes the slave to enter the idle state), it may ignore the master attempt to complete the burst operation and NAK the first data byte that the master sends or requests.
Since the behavior of slaves cannot always be predicted, it is suggested that the application software always write the STOP bit in the I2C Master Configuration (I2CMCR) register during the CLTO interrupt service routine. This limits the amount of data the master attempts to send or receive upon bus recovery to a single byte, and after the single byte is on the wire, the master issues a STOP. An alternative solution is to have the application software reset the I2C peripheral before attempting to manually recover the bus. This solution allows the I2C master hardware to be returned to a known good (and idle) state before attempting to recover a stuck bus and prevents any unwanted data from appearing on the wire.