MSP430F5438A I2C UCBBUSY always set after UCSWRST cleared

MP said:

P5DIR = COLOR_BUS_SCL + BIT0 + BIT1 + BIT5 + BIT6 + BIT7;

I don't know what's going on. However, this line looks suspicious.

I don't know the actual value of COLOR_BUS_SCL, but it is generally a bad idea to add bit values. OR them instead. Because if by accident, COLOR_BUS_SCL would be 0x02, adding it to BIT1 would result in BIT1 not set at all but BIT2 being set.

General rule-of-thumb: use bitwise operators for operations on bits. '+' is an arithmetic operator for calculations on values.(This applies to all your config lines, not just this one)

It also looks odd that SDA and SCL are on different ports. Ar they really? You don't write which MSP you use, but usually, SDA and SCL are on the same port for the same USCI module.

If you use port mapping controller: do you use any library that might do port mapping too? Port mapping can only be done once. if done, further attempts to map things are ignored until next BOR.

Thank you for replying.

I replaced all my additions with bitwise ORs and the ports are getting configured correctly, though I am still having the same problem.

I am using the MSP430F5438A. Its datasheet lists I2C data – USCI_B1 I2C as being on P3.7 and I2C clock – USCI_B1 I2C as being on P5.4.

I am not using the port mapping controller.

MP said:

the ports are getting configured correctly

Do you configure the ports before configuring the USCI? (else there could be an erroneous transition on the inputs while the I2C state machine is already running)

MP said:

I am using the MSP430F5438A.

You're right, UCB1 is split on two ports on this one. Only UCB1, none of the other modules. And it doesn't have a port mapping controller at all, so the pins are the right ones. (double-checking those things never hurts)

You're right, others have reported similar problems before. Honestly, I never used the USCI for I2C so far. My projects with I2C devices are all based on the MSP430F1611 and I used my own software I2C on it (the USART I2C is too complex for I2C transfers with changing direction and only one or few data bytes per transfer).
So I was unable to provide a solution or to even reproduce the problem.

You could try to use a different USCI (there are four) and check whether it happens too on them.

Hi MP ,

I am receiving similar problem .. Please tell me the solution if you were able to find it.. T

Thanks 

Ash

Hi Guys/Gals,

I'm getting the same problem on a MSP430G2553.  

I'm doing this per the examples

  UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation

And it is causing UCBBUSY to 1

I reset (un-powered) my launchpad as well as the connected slaves and the problem was resolved, but it worries me this might happen in the wild.  (my program will wait/hang until the bus is no longer busy).

So if you find a better solution please share,

Cheers,

Doug

As explained in one of the many other threads, UCBBUSY is set when the USCI detects the bus busy.
This means (besides an own ongoing transmission), the USCI has detected a start condition or has detected clock or data being low. UCBUSY will clear if the USCI detects a stop condition. (or SDA and SCL are high and the USCI is reset).

Thank you very much Jens-Michael

I did search before posting but obviously for the wrong keywords.  Your explanation is logical (and helped my understanding of I2C), I have checked my initialisation and pullups - they are fine.  The fact that a hard reset fixed it makes me believe in the stuck slave scenario so I'll add some simulated start/stops per your suggestion.. (I didn't think to look at the slave but of course in I2C it can be the case)... If I can reproduce it again I'll try to prove this by removing the slave and seeing if the UCBUSY will clear.

Thanks again.

Doug