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.

MSP430F5438A I2C UCBBUSY

Other Parts Discussed in Thread: MSP430F5329, MSP430F5438A

While setting up UCB1 for I2C master mode, I get an immediate UCBBUSY = 1 setting after clearing the UCSWRST bit.  The SCL line (P5.4) is pulled up in hardware with a 4.7K resistor and I have checked the SCL line with a scope to verify it is @ 3.3V.   Any other suggestions for why UCBBUSY is getting set? 

Setup code is as follows:

  I2C_B1_SCL_SEL_SET;                       // Set SCL pins to module select.
  I2C_B1_SDA_SEL_SET;                       // Set SDA pin to module select.

  UCB1CTL1 |= UCSWRST;                      // Enable SW reset
  UCB1CTL0 = UCMST + UCMODE_3 + UCSYNC;     // I2C Master, synchronous mode
  UCB1CTL1 = UCSSEL_2 + UCSWRST;            // Use SMCLK, keep SW reset
  UCB1BR0 = 200;                             // fSCL = 20Mhz SMCLK/200 = ~100kHz
  UCB1BR1 = 0x0;
  UCB1CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation

 

  • This shouldn't happen. I don't see anythign that would cause this.

    Only that I don't know what I2C_B1_xxx_SEL_SET does. I can imagine what it is intended to do, but what DOES it do?

    Is any of the UCB1IFG bits set?

    Also, sometimes it's the debugger that causes strange symptoms. Without debugger attached, all is running well. SO I usually use a simple port output pin and an LED to signal things, one at a time, until all is working.

     

  • I'm getting the same exact problem. My UCBBUSY bit is becoming set when the UCSWRST bit is cleared. Did you ever figure this out? I'm using B0 instead of B1, but none of the UCB0IFG registered are set, to answer the question by Jens.

  • I am having the same problem with a 430F5310. How was this resolved?

    Thanks.

  • Hi

    I have the same problem on MSP430F5329. I used port mapping and using pins P4.6 and P4.7 as I2C interface on USCI_B1 ( I2C mode )

    Any solutions or ideas are welcome

    BR zorz

  • zorz said:
    I used port mapping and using pins P4.6 and P4.7 as I2C interface on USCI_B1 ( I2C mode )

    Did you unmap the two signals from their original pin (if any)? Strange things may happen if you have an input funciton mapped to more than one pin, even if not 'selected' at this other pin.

  • hi

    i was hoping that this was the solution, but no i have tested this but the bussy is still ON

    BR zorz

  • zorz said:
    o i have tested this but the bussy is still ON

    So maybe a bug in your code. Or in your schematics. No idea.
    Some problems can only be figured out at the physical target object. Sometimes not even then (I once had a PCB that behaved differently than its 199 brethren, and I never figured out why, despite of all measuring - I still have it in the schelf)

  • hi

    i have rechecked the situation and did not find anything wrong. Never the less for now i made a software driver  and it work, if i will have the time i will look for mistake

    thank you for help

    br zorz

  • Hi zorz,

    I am facing similar problem.. I get busy always .. Please let me know if your figured out where the problem is 

    Thanks 

    Ashutosh

  • I am seeing the same problem on MSP430F5438A.  Whether I enable the master receive or send mode, as soon as I clear UCSWRST, the UCBBUSY goes high.  In my case, the SDA and SCL are both 0.

    I tried on 2 different boards.  On 1 board, it worked ONCE, and then never since then.  The only thing I can do next is to get another sensor to talk to, in case the sensor has gone bad.

  • “In my case, the SDA and SCL are both 0.”

    Which is the cause. If the bus is idle, SDA and SCL are both high. If they are not, then the bus is obviously busy. Which the USCI tells you.

    So either there’s something wrong with your port pin initialization, or there is a problem with the external hardware. Do you have the external pull-ups on SDA and SCL? Are they powered? Do you have a common GND for MSP and sensor?
    Does the sensor hold the signals low for some reason? See the sensor datasheet for required operating conditions (e.g. some startup time before the bus can be used, reset signal conditions etc.)

  • Thanks for following up on this Jens.  As I recall, we closed this issue out in another thread.  I expect that my workaround (shaking the SDA and SCL up and down a few times between use) is working fine.

  • Probably, it is enough to do the following:
    SCL  LOW (allow all peers to release their data line)
    SDA LOW
    SCL HIGH
    SDA HIGH (generate a stop condition)
    Sufficiently slow. (>100µs between each step).

    This will force all peers to detect a stop condition.

    It also might be sufficient to ensure a long enough delay between a stop and the following start (due to a silicon erratum, on some MSPs the delay might be too short if controlled by the USCI)

  • That's exactly what I am doing now.  But I thought earlier you were saying that I should toggle back and forth between input (high Z) and output states.  What I am doing currently between each I2C session is:

    SCL and SDA low

    5 us

    SCL and SDA high

    0.5 second wait (through timer interrupt).

    I do this 3 times between each I2C communication.  Seems to be working so far...

  • Yes, in case of I2C, ‘high’ means ‘high impedance with external pull-up’ and not ‘pulled high’.
    So to simulate an OC output, you toggle between low output and high-impedance input rather than low and high output.
    That’s what I was referring to.

    However. What I wrote was a 4-step sequence with 100µs between each step. First SCL low, then SDA low. Not both together. Just to simulate a clock step (where it is allowed for the slaves to change their output state), then a stop condition (when the slaves had a chance to release SDA during SCL low).

    I don’t think a 0.5s delay is really an acceptable requirement. So the minimum solution should be found for a reliable operation.

  • Hi Jens, I did as you suggested.  It still works.  Thanks.

**Attention** This is a public forum