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.

  • TI Thinks Resolved

MSP430F5524: UCBBUSY being continuously set

Intellectual 560 points

Replies: 12

Views: 344

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;

__delay_cycles(1000);

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.

Thanks

Abhisheki2cCode.c

  • In reply to Lixin Chen1:

    Hi Lixin,

    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 .

    Thanks

    Abhishek

  • In reply to Abhishek Veeraraghavan:

    Hi, Abhishek,

    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. 

    Regards, 

    Lixin 

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.