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.
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.
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
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.zorz said:I used port mapping and using pins P4.6 and P4.7 as I2C interface on USCI_B1 ( I2C mode )
hi
i was hoping that this was the solution, but no i have tested this but the bussy is still ON
BR zorz
So maybe a bug in your code. Or in your schematics. No idea.zorz said:o i have tested this but the bussy is still ON
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.
**Attention** This is a public forum