TM4C1294NCPDT: Clock Stretching

Hi Danilo,

  Yes, the TM4C129 MCUsupports clock stretching for its I2C module. Please refer to the datasheet for detail. Below is the excerpt. 

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 Timeout 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 master state 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 was operating at 100 kHz speed, programming the I2CMCLKOCNT
register to 0xDA would translate to the value 0xDA0 since the lower four bits are set to 0x0. This
would translate 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
timeout 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 it intends to attempt bus
recovery. Most applications may 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. Depending on the state of the

slave after bus recovery, the actual behavior on the bus varies. If the slave resumes in a state where
it 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's 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.

Note: The Master Clock Low Timeout counter counts for the entire time SCL is held Low
continuously. If SCL is deasserted at any point, the Master Clock Low Timeout Counter is
reloaded with the value in the I2CMCLKOCNT register and begins counting down from this
value.