This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Jace-san.
Thank you for your kindly reply.
I understood tIFCLK.
Please let me ask an additional question about the Bus Busy.
I understood the Busy Bit should work as normal and is independent to this bug.
It is described as I2C bus "stall" at the next received byte when this problem occurs.
So, I think I2C status become Bus Busy while this I2C bus Stall. Is this correct?
Or CPU freezes when the CPU access the I2C register?
Best Regards,
Taka
Hello Taka-san,
The Busy Bit during I2C operations is set when a START condition is seen and is cleared after a STOP condition is detected. So if you were to have a bus stall between these, the Busy Bit should still be set.
The CPU is not "frozen" when this errata occurs. Rather, the internal state machine within the eUSCI missed the internal RXRead Flag that signals when the RXBUFF has been read. This is why a second read of RX Buff is a workaround.
Hope this helps!
Regards,
JH
Hi JH-san
Thank you very much for your advice. That has become a great help!
Sincerely,
Taka
**Attention** This is a public forum