MSPM0L1303: Regarding I2C

What software is running in the MCU?

There was a bug having to do with SWUEN=1 and clock-stretching (slave-only as I recall); the symptom was that wiggling SCL on an idle bus would lock up the I2C (I2C unit waiting on a clock-request that was already complete).

At one time, the C-series sysconfig would generate code to set SWUEN=0 (it's =1 at reset) with a comment referring to Erratum I2C_ERR_04, which I don't think I've seen published.

The workaround is to call "DL_I2C_disableTargetWakeup(I2C_INST);".

The "institutional memory" is here:

 RE: MSPM0G3507: MCU set as slave, I2C SCL short circuited to GND for about 1 second and then released, SCL cannot restore high level(Urgent call for help!!!) 

[Edit: I just tripped over a description of I2C_ERR_04 in the G3519 Errata [Ref Errata (SLAZ758B) p. 9], which is pretty recent. The workaround suggests using the SCL TIMEOUTA, but my recollection is that the timeout mechanism didn't operate in this case. I (still) think the real solution is setting SWUEN=0.] 

Hey Bruce,

Thank you for your response.

I would like to confirm if this is TWUEN not SWUEN?

Bruce McKenney said:

I (still) think the real solution is setting SWUEN=0.

Back in the Ancient Days (a few months ago) it was called SCTR:SWUEN but I see that it has been renamed to TCTR:TWUEN.

It's the same bit -- bit 10 of the register at offset 1258h.

[Edit: SDK 2.05.01.00 doesn't appear to define TCTR nor TWUEN in the CMSIS header (hw_i2c.h); I only see SCTR and SWUEN. If you're using Driverlib the relevant function is DL_I2C_disableTargetWakeup().]