MSP430FR2355: i2c clock stretching...how to use this???

At the MSP430 end, clock-stretching is automatic, and in the absence of UCCLTO your master will wait forever if the slave is stretching.

I found a document "I2C comm guide 2_15" for the K20-K50. Fig 7 indicates that it might stretch the clock for 40ms. In the I2C world, this is really quite a long  time, and longer than any of the UCCLTO timeouts.

If you're using the UCCLTO, I suspect you need to turn it off and hope for the best.

Hi Bruce....

So I am guessing the UCSCLLOW bit is written to by the slave and not the master, is this correct?  

I am using the timeout on CCLTO but I never go in there....The component NACKs the address a few times due to power up but then it acks the address and all data afterwards on both reads and writes....The issue I see is the writes only take if I don't toggle the enable line ....I say 'don't take' only bcz a post read of that register yields default values EVEN though the component ACKs everything.....I tried slowing the clock as I said but to no avail....I was reaching with the UCSCLLOW bit and to be honest am glad I don't have to monkey with that......  I will look at the doc you suggest to see if I can glean anything.....

I have tried lengthening both the front and back end of when the enable starts and stops but to no avail...I presume clock stretching maybe isn't important if I can read and write at 100khz with the enable always being on??? (your thoughts here)

Steve

The document I found doesn't mention an Enable line. Is that like a Chip Select? (CS does appear on some few I2C devices.) It may not even apply to your device, but I don't know which that is. I'd say go with what works.

My document also mentions (Sec 3.6) that it will NACK if it's Busy ("This is not an error").

Sorry....part is 
https://senseair.com/products/power-counts/sunrise-hvac/

It uses an enable....35ms supposed minimum wait time...I have tried 61ms on front and back end of enable but no avail....Like I said if I enable during configuration and then do not turn off enable I can read and write to the registers.  

JD....

I have attached a doc with lots of pics....pretty self explanatory....You will notice :

Pics without toggling enable --- these look good

Pics toggling enable waiting 35ms --- device does not NACK I presume bcz it is awake --- here reads do NOT match writes

Pics toggling enable waiting 15ms --- device NACKs address until awake then ACKs all others ---- also here reads do NOT match writes

Things to note....On toggling when enable pulled low I notice data comes low then clock creating a start....Lines stay low until you initiate a later read or write upon which enable goes high, clock goes high then data goes high wait 35 or 15 ms and get first start to do transaction.

Last pic shows that even with the lines being held low I seem to be able to read READ only registers on the device....The device has a block of READ ONLY and then a block of READ/WRITE....not sure the data is good as they don't suggest any default values ....all I know is in the R/W register section I always get either FF or 00 returned when reading with enable toggling.

CO2_I2C.docx

TDE7318 (rev 11) p. 12 makes EN=0 sound like a fairly heavy hammer ("all volatile memory is lost"). I imagine that's where your register settings are going.

Yes, there is a cognitive dissonance with the flowchart on p. 13, though it does mention "sensor state data from previous", so maybe that's where the registers get (re-)loaded.

It seems like you want to keep EN=1 all the time, at least until you have the device more or less tamed.

Hmmm...Yes I was using the doc flowchart and definitely overlooked that statement.....But with that said I was using 3.3V from the MSP430fr2355 dev bd to power both VDDIO and VBB AND the pullup resistors on the line....I was gating EN from the MSP.  See top figure p. 6 of TDE7318 only diff was MSP is driving ENABLE.  DVCC is the output of the regulator and according to p 12.

"When EN-pin is driven low, the internal voltage regulator powers down the circuitry and all volatile memory is lost. "

In this configuration I was NOT using DVCC ....From the lower pic on p. 6 of TDE7318 I thought DVCC was powering VDDIO which in turn was powering the circuitry.  I believed VDDIO to be power to internal circuitry.....However I am not sure that is correct as PSP12440 p.3 suggests VDDIO is only power to nRdy and TXD/SCL...

I think I will try and do a write and then a read and then a power down to see if results are different....btw my physical configuration now is bottom figure on p. 6 of TDE7318.