• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 80 subscribers
  • Views 1016 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5514: I2C bus is busy for a long time when Master0(UCB0SCL, UCB0SDA) is being used.

chethan kumar10
Prodigy 30 points
Part Number: MSP430F5514

Hi

We are using I2C communication. Earlier we were using Master1(UCB1SCL, UCB1SDA) which was working fine. Now we are trying to use Master0 (UCB0SCL, UCB0SDA) at P3.0, 3.1 with one slave. In the code, in the case of a timeout before the slave responds, STOP is sent to the slave. We wait until bus is free and then return. The bus is busy for a long time before eventually getting released. 

UCB0CTL1 |= UCTXSTP;
while (UCB0STAT & UCBBUSY){};  //getting stuck here for a long time
return I2C_TIMEOUT;

Could you let me know why the bus might be busy? Is there a difference in configuration for the two masters that needs to be done?

(This is the first time I'm posting a question on this forum. Pardon me for any mistakes, and let me know if more information is needed).

  • 0
    TI__Genius 14755 points

    Hello,

    Considering that the USCI_B0 and USCI_B1 modules are identical in terms of functionality according to the register descriptions in the device user's guide, there should not be any difference in terms of performance between the two.

    In order to successfully switch from one module to the other, you must comb through your application to make sure that all references to "UCB1" are correctly modified to "UCB0" in addition to making sure that the port pin initialization is correctly modified. Once the software has been ported, the hardware surrounding the chip needs to be changed according to the new pins being used.

    Knowing that it was working fine with the previous version of your application using USCI_B1 leads me to believe that some aspect of the HW or SW porting has gone wrong.

    Best regards,

    Matt

  • 0 in reply to Matt Calvo
    Intellectual 560 points
    Hi Matt, It was me who had asked the question. Apologies for the delay in replying. ( The TI website did not allow a registering of a new user the other day - a bug? - and I was forced to ask the question from my account. You were right. For Master 0, there were no pull-up resistors. This was leading to UCSCLLOW to being set high for a while. Once it got low, the UCBBUSY also got low.

    I tried to alleviate this problem by using internal pull-up resistors despite the fact that they could only be used for GPIO pins. On doing this, I observed the following result. Immediately after the Start condition was sent, the UCNACKIFG got set. It was getting set even when the corresponding interrupt flag was disabled.

    Is this simply because of using internal pull-up resistors with a specialised peripheral function? (P3SEL |= 0x11)
    Is there any way to use it this way?

    Thanks
  • 0 in reply to Abhishek Veeraraghavan
    TI__Genius 14755 points

    Hello,

    Yes the site was likely temporarily down while you were trying to register, sorry for the inconvenience!

    It is always recommended with our MCUs to use external pull-up resistors on the I2C clock and data lines in order to ensure proper handling of the open-drain signal and to have the ability to tailor the pull-up strength based on the capacitance on the lines. Please refer to this e2e post for more information regarding why we recommend using external pull-up resistors, as explained by Priya in the responses.

    Customers have found that sometimes the I2C communication will work using the internal pull-up resistors, and sometimes it wont. There are many factors that can affect the proper operation of I2C communication, one of them being the size of the pull-up. In the case of the MSP430, its around 35kOhms which may be too large for your setup. Here is another e2e post exploring this concept.

    Best regards,

    Matt

  • 0 in reply to Matt Calvo
    Intellectual 560 points
    Hi Matt,

    Thanks for your reply. I had read one of the posts earlier and have now read the other one as well.

    My question is, is it even theoretically possible to use internal pull-up resistors with a specialised peripheral function? I saw that somebody had done it by using it with GPIO pins where he had written all the code to handle the information, send raw data, check for ACK etc. instead of using

    Is the behaviour I am observing(receiving UCNACKIFG) simply because of the factors you have mentioned - large pull-up resistor size, length of the trace lines, bus capacitance - or could it be a bug(unlikely I know given that this is a TI product)?
  • 0 in reply to Abhishek Veeraraghavan
    TI__Genius 14755 points

    Hi,

    According to the device family user's guide for MSP430F5xx devices, it is theoretically possible to activate the pull-up resistor circuit even when a specialized function is selected for the pin:

    This is due to the fact that P3REN and and P3OUT directly control the switch and mux logic that enable the pull-up/pull-down.

    Regardless of this being the case, it is still highly ill-advised to use the internal resistors for the I2C signal pull-ups because it could result in invalid signals on the I2C bus due to rise times that are too slow. This could result in error flags, such as the one you are seeing with the UCNACKIFG. The scope shot below shows our I2C example communicating between 2 Launchpads with internal pull-ups enabled and you can see that the analog waveform is barely rising fast enough to make the communication work.

    Any I2C speed faster than what is depicted would likely cause the communication to fail. Any inquiry about bugs can be found in the device's errata sheet. There you will find all of the documented bugs for the device you are using and potential workarounds if available.

    Best regards,


    Matt 

**Attention** This is a public forum