MSP430F5308: MSP430F5308 i2c USCI slave Transmit clock stretch issue

Hi, 

Master:  MCP2221 microchip USB to i2c bridge.   Driver is the standard MCP Linux driver.  100khz i2c bus speed.

Slave:  MSP430F5308 @ 8mhz using the USCI peripheral and slightly modified TI sample code.

Test Equipment:  LeCroy Scope with built in i2c bus analyzer.  Ardvaark/Beagle TotalPhase I2c Packet Analyzer.   Effective resistance on the i2c pullups is roughly 2K and the edges look nice and sharp at 100khz, with the i2c waveforms just over 0v and all the way up to 3.3v.

Problem:  When the MCP2221 requests a Slave Transmit of a single 8 byte packet, there is no ACK clock generated by the MCP2221, causing the state machine to break on both sides.  Speed 100khz I2c.  8mhz F5308 clock.  

Analysis:  After extensive troubleshooting, it appears that when the MSP430 is running at 8 mhz, it requires something in the neighborhood of 8us to respond to the incoming 7 bit address +R/W, and then to release the clock (ie - we think the 430 is stretching the clock), when it does release the clock for the MCP to initiate an ACK pulse, the MCP2221 doesn't react correctly and instead of sending the ACK, just starts clocking the Data word.  We hypothesize the 8us is required by the 430 to process "is this address for me" and to interpret the R/W bit.

This only happens on a Slave Transmit, not a Slave write.  When the clock speed of the MSP430 is increased to 16 or 24mhz, the MCP generates the ACK correctly and everything works normally.  There was one observed condition with another programmers code also using the USCI, but on another family of MSP430, where the ACK pulse is 1/4 normal 100 khz pulse width, pointing us toward speeding up the MSP430 clock fixing the issue.  This code was also fixed (ie - the clock pulse returned to normal width) by increasing the 430 code speed and further substantiates the clock stretching theory. 

We ran some tests at higher clock rates on the MSP430 and if the clock speed is increased beyond 8mhz to say 16 or 24mhz, it appears that it takes less time to release the clock in roughly a time delay proportional to the clock speed increase.  This allows greater i2c speeds, however is a workaround for the MCP2221 not accepting clock stretching correctly.

Of course we are working with Microchip to see if we can reprogram the driver of the MCP2221 to play nicer with clock stretching but in the mean time:

Questions:  

1) Any idea why we see the problem on the Slave Transmit and not a Slave Receive?

2) Is the turnaround delay between the Address and the ACK dependent on purely on clock cycles on the MSP430 or is there RC/Analog/Propogation type delay we are dealing with.

3) Is there some setting or code we are missing that would make the MSP430 not insert a clock stretch delay between the R/W bit and the ACK (ie, can we speed up the time it takes for the 430 to release the bus on an I2c slave transmit ACK)? 

Thanks!  Blake