I want to communicate an MSP430FR5739 (as the master) and an MSP430G2553 (as the slave) via I2C. I have used a multitude of examples provided by TI (which to my surprise sometimes does not work) and yet I haven't been able to even transmit one single byte from the master to the slave. My final goal is to have two way communication between the two ends.
I'm attaching below the code I'm using for the master. The code I'm using for the slave is provided by TI (mspg2xx3_uscib0_i2c_13.c) . Please let me know what is that I'm not looking at in there. Yes, I have a couple of 10k pull-up resistors attached to the SDA and SCL lines.
Thanks for you help as usual!
Here is my version of the code for the slave.
I don' tknow why you do not send. But I notices several things:
You never clear UCTR after you sent something, so you'll be unable to read form the slave once you sent it something.Also, you never clear the IE bits after the transfer. So after calling transmitI2C_init once, the master will respond to TX interrupts. and after read to RX interrupts. This is not critical since you won't have interrupts when not startign a transfer, but togethe r with the no cleared UCTR, you'll be actually sending when you think you're receiving.
STPIFG doesn't need to be handled. First, you don't have the STPIE bit set and won't get an interrupt for it, but even if you did, reading UCB0IV has automatically cleared the IFG bit trelated to the value it returns. Same for UCTXIFG in TXIFG0 case.
Also, I think you want to wakeup main when you're done sending (byteCtr==0) and not after each single byte you send. So the __bic_SR is in the wrong half of the TX interrupt code.
Then all variables used inside an ISR and outside an ISR must be declared volatile.
Your hardcoded assignment of 1 to UCB0TBCNT isn't a problem too now, but will be once you want to send more than one byte. It shoudl be set in the T/TX function according to the byteCount.
Still I don't see what it isn't sending. What exactly do you observe? No clock on SCL? Does the slave not ACK its address? Does teh master send the byte but the slave doesn't report that it has been received? You should chekc this with a logic analyzer or a scope.
btw, do the two processors have a common GND connection? Besides not having pullups, this is the second-most cause for failure on I2C: the missing 3rd wire in this 2-wire interface :)
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Thanks for your advice Jens, I will modify the code and retest it. Yes, both processors share a common ground.
One thing I did not know and TI has not put anywhere is the fact that on the LaunchPad, the pins corresponding to SDA and SCL are reversed. Thus, P1.6 is actually P1.7 and viceversa. Also, the P1.6 is attached to the LED2 through a jumper. This effectively draws current from the line and never allows it to go up to Vcc. After reversing those pins and disconnecting the jumper between P1.6 and LED2 the communication was successful.
Andres MoraOne thing I did not know and TI has not put anywhere is the fact that on the LaunchPad, the pins corresponding to SDA and SCL are reversed. Thus, P1.6 is actually P1.7 and viceversa.
SDA and SCL are where they are on each individual processor. This has nothing to do with LaunchPad or not. It is pure coincidence that on the two processors you use teh SCL/SDA pins are on P1.6/P1.7. On other processors they are on different pins of P1, or even on a completely different port. Or yopu can (more or less) freely map them to a pin you like.Port pin function and USCI pin function are totally unrelated.
You are absolutely correct. Each processor has their SDA/SCL pins already assigned to specific ports, in this case the MSP430G2553 has them assigned (as you correctly mentioned) on P1.6 & P1.7 respectively. However, it seems that the LaunchPad I have been using has crossed those ports. I have successfully tested it out to check that is actually the case.
Andres MoraHowever, it seems that the LaunchPad I have been using has crossed those ports.
Or do you want to say that on your LaunchPad, SDA is on P1.6 and SCL on P1.7? This would really surprise me as it would prove the G2553 datasheet pinout table to be wrong. Of course that's possible and if this is really true, then the datasheet should be corrected ASAP. But It's not very likely.
On FR57xx, SDA actually is on P1.6, so between the two MSPs, the signals appear 'crossed', but only by coincidence - they could have been on totally different port pins as well.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.