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.
Part Number: MSP430F5524
I am using I2C Module 0 (UCB0) to communicate with two slaves - EEPROM(24LC64) and a temperature sensor(Si7060). I2C Write and Reads from the temperature sensor are being done continuously. Occasional I2C reads are failing as they do not respond in time, but it is okay by me as the next reads work.
But After 10-15 min(one in 10000 or more reads), the UCBBUSY bit gets set. The SDA line is continuously held low. My code is waiting in a while loop for the bit to get cleared which is not happening and thus the code gets stuck. Writes are working fine. I have used the same code which was being used for I2C Module 1(UCB1) which is having no problem.
(1) Why is this happening? I have observed on a CRO that the CLK signal is looking like a sine wave. Is the insufficient hold time leading to the slave pulling the data line low to signal an ACK and never releasing it? In this case changing I2C clock frequency solve the issue, right? Current clock frequency is about 133KHz(16Mhz/120)
(2)When the UCBBUSY is getting set I tried resetting the I2C Module by doing
UCB0CTL1 = UCSWRST;
UCB0CTL1 &= ~UCSWRST;
Though this reset the module and the SDA line back to the high voltage level, this is leading to unsuccessful I2C Reads continuously in certain cases. Is what I have attempted to correct? If not, how else can I solve this problem?
We are in a critical stage during production. Any help would be dearly appreciated. Please find the code attached.
In reply to Lixin Chen1:
That was a good point you made. When I reduced the clock speed from 16MHz to 12MHz, the I2C clock speed had also reduced from 133KHz to 100KHz. To dig deeper, I reduced the I2C clock speed to 100KHz while keeping the MCLK speed at 16MHz. It failed immediately. I hit upon the clock speed being an issue when, with the clock speed being 16MHz, I debugged the I2C code line by line and it didn't fail. If the issue doesn't recur on reducing the clock speed, I'm planning to try further reducing it to 8MHz and if this doesn't work, trying to issue a software reset( using watchdog timer), preferably from the ISR .
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Abhishek Veeraraghavan:
For the case of " I reduced the I2C clock speed to 100KHz while keeping the MCLK speed at 16MHz. It failed immediately", do you know where is the failed place? Is the code hang up at somewhere or I2C communication failed with no ACK or wrong data receiving/writing? If it can be addressed, we can know if the MCLK has something wrong or the I2C communication has something wrong. You can also try another case: MCLK setting to 16MHz, I2C clock setting to 100KHz, reduce the pull-up resistance for the I2C SCL and SDA lines. This can help to address if the I2C communication is wrong.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.