Hi,
On one of our product, we have an issue where sometimes SCL is stuck low. I2C Master is the cc3235, slave is the msp430fr5738 (there are 2 other i2c slaves but we have confirmed that they are not the ones holding the line).
We see SCL being held low for an infinite time, and released when the msp is reseted.
It's very difficult to debug because it's affecting only about 3% of devices per year. Fortunately when doing another change the error rate was increased to ~5% per week, so still not easy to reproduce on an instrumented device but feasible.
We are not sure of the root cause yet, we suspect it might be caused by USCI37, from the errata https://www.ti.com/lit/er/slaz391ag/slaz391ag.pdf?ts=1699367487148&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FMSP430FR5738
Our questions:
- Can you confirm that we should detect if the msp is holding SCL by checking UCB0STATW & (UCSCLLOW | UCBBUSY) ?
- Is there an easy way to put the msp in this error mode? This would help us confirm that it is the issue we see, and make the master code more robust as well.
- What is the proper way to reset the bus properly on the msp? We are planning to use the code below.
UCB0CTLW0 |= UCSWRST; // Software reset enabled
UCB0IE &= ~(UCRXIE | UCSTPIE); // Disable RX and TX interrupt
UCB0IFG = 0; //Clear pending interrupts
for (int i = 0; i < 200; i++) // Wait 200ms
{
__delay_cycles(8000); // Wait 1ms, ~1ms because MCLK = 8MHz
}
UCB0CTLW0 &= ~UCSWRST; // clear reset register
UCB0IE |= UCRXIE + UCSTPIE; // Enable RX and TX interrupt
Some infos about our system :
Clock = 8 Mhz
I2C frequency 100 Khz
I hope it's clear enough.
Thanks,
Cédric
