25/04/12

eZ430 - RF2500 I2C NOT WORKING - MSP430 Ultra-Low Power 16-bit Microcontroller

QuestalacopiacachediGoogledihttp://e2e.ti.com/thread/534102.aspx.un'istantaneadellapaginavisualizzatail21apr201208:33:07GMT.Nel frattempolapaginacorrentepotrebbeesserestatamodificata.Ulterioriinformazioni Versionesolotesto

New Post
Samples & Purchase Cart | Contact Us | TI Worldwide: United States | my.TI Login

Search by part number or keyword All Searches TI Home > TI E2E Community > Support Forums > Microcontrollers > MSP43016-bit Ultra-Low Power MCUs > MSP430 Ultra-Low Power 16-bit Microcontroller Forum > eZ430 - RF2500 I2C NOT WORKING

TIE2ECommunity
Details
123 Views 1 Reply 2 Subscribers 155 days old

Join or Sign In with my.TI Login

Search Community
Everything This Forum Advanced Search

GO

Options
Subscribe via RSS Send to friend

Tags
ADC10 BSL CC430 CCE CCS ez430 ez430-RF2500 Flash I2C IAR launchpad MCU microcontroller Microcontrollers msp 430 MSP430 MSP430 microcontroller MSP430F2274 MSP430F5438 MSP430F5xxx MSP430x2xx SPI UART USB USCI

MSP43016bitUltraLowPowerMCUs
Welcome to the MSP43016-bit Ultra-Low Power MCUs Section of the TI E2E Support Community. Ask questions, share knowledge, explore ideas, and help solve problems with fellow engineers. To post a question, click on the forum tab then "New Post". Discussion on MSP43016-bit Ultra-Low Power Microcontrollers.

webcache.googleusercontent.com/search?q=cache:jxAUF2tcIHIJ:e2e.ti.com/thread/5

1/3

25/04/12

eZ430 - RF2500 I2C NOT WORKING - MSP430 Ultra-Low Power 16-bit Microcontroller

Get this RSS feed

Home

eZ430RF2500I2CNOTWORKING Announcements
rated Forum by 0 users 2 Followers 1 Reply | Design Notes

Posted by Nelson Pina on 18 Nov 2011 12:21 PM

Hello everyone,

Prodigy 10 Points

I'm using the eZ430 - RF2500 development kit, and i need to interface one Humidity sensor (SHT25) with the MSP430F2274. I'm trying for 2 weeks now, and I'm not able to communicate with the sensor. The same sensor works fine with Renesas micro controller, so the problem is really with the MSP430F2274 micro. I have the 2 pull-up resistors (10K Ohm), and I always get trapped in the cycle that verifies the ACK of the START CONDITION. Another thing that i notice is that the SCL and the SDA lines are not with the same tension, SCL with 2.9V and SDA with 1.9V. Before the START they should be booth in hight level right? My code is simple this for trying to get the ACK from the sensor, and i never pass the "while(UCB0CTL1&UCTXSTT) " condition, the sensor never send the ACK:

voidmain(void) { WDTCTL=WDTPW+WDTHOLD BCSCTL1=CALBC1_8MHZ DCOCTL=CALDCO_8MHZ

/*ConfigureI2C*/ P3DIR|=0x0F P3SEL|=BIT2|BIT1 UCB0CTL1|=UCSWRST UCB0CTL0=UCMST+UCMODE_3+UCSYNC UCB0CTL1=UCSSEL_2+UCSWRST UCB0BR0=0x50 UCB0BR1=0 UCB0I2CSA=0x80 UCB0CTL1&=~UCSWRST IE2=UCB0TXIE+UCB0RXIE

/*TransmitData*/ UCB0CTL1|=UCTR UCB0CTL1|=UCTXSTT while(UCB0CTL1&UCTXSTT) UCB0TXBUF=0xFF while(UCB0TXIFG==0) UCB0CTL1|=UCTXSTP }

If anyone can please analyse this and help me I will be very thankful,

Best Regards, Nelson Pina

I2C, MSP430 microcontroller, MSP430F2274, msp 430

Reply

webcache.googleusercontent.com/search?q=cache:jxAUF2tcIHIJ:e2e.ti.com/thread/5

2/3

25/04/12

eZ430 - RF2500 I2C NOT WORKING - MSP430 Ultra-Low Power 16-bit Microcontroller

{0}
All Replies

Posted by Jens-Michael Gross Guru 82385 Points replied on 21 Nov 2011 7:49 AM
Nelson Pina: never pass the "while(UCB0CTL1&UCTXSTT) " condition, the sensor never send the ACK: If the slave doesn't ACK, the USCI will continue, clear UCSTT and set UCNACKIFG. If UCSTT doesn't get cleared, there is only one reason: the I2C clock is suspended for some reason. Ther eare two possible resones: 1) the clock source of the USCI is not running (e.g. SMCLK is stopped) or 2) the I2C SCL lien is held low (clock stretching). If SCL is low, this may be because of a missing pullup, a port pin misconfiguration or because the slave holds it low (e.g. because it is not ready yet for the transfer, 'hold master' feature of some slaves, generally called 'clock stretching'). Pullups are there, as you say, port configuration looks right (P3.1/P3.2). SMCLK should be running from DCO (8MHz), I2C clock is 100MHz then. There is, however, something completely different: You set UCB0TXIE and UCB0RXIE. THis measn, when TXBUF is empty or RXBUF is full an interrupt is triggered. Yet you don't seem to have an ISR nor do you need one (you do the job in polling mode). So the moment you set UCSTT, UCB0TXIFG is set and an itnerrupt is triggered. A breakpooint on teh while loop will be triggered because it is triggered the very moment UCSTT is set and the interrupt occurs. But then the ISR is called, the processor jumps into the wild (there is no ISR), and the while is never executed at all. Instead the MSP will eventually reset due to vacant memory violation or such. In addition, the next while is a NOP. UCB0TXIFG is a constant and has a value <>0, the the while will always immediately end. The correct loop test is while(!(IFG2&UCB0TXIFG)); However, in your test code, UCTXBUF is almost instantly empty agian after you pushed 0xff to it, because you wait for UCSTT beign clear before you write to it, so its content can immediately be forwarded to the output shift register. So the while loop will exit anyway (even if the correct one is used) in this case, and the code would work. But you'd run into trouble when you try to expand it later. _____________________________________ Before posting bug reports or ask for help, do at least quick scan over this article about reporting bugs. Its content applies to any kind of problem reporting. 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.

rated by 0 users

Reply

{0} Jens-Michael Gross Answered (Not Verified)

Page 1 of 1 (2 items)

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. Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice. Products | Applications | Design Support | Sample & Buy TI Worldwide | About TI | Contact Us | Investor Relations | Press Center | Corporate Citizenship | Careers | Tags | my.TI Login | All Searches | Site Map Copyright 1995-2012 Texas Instruments Incorporated. All rights reserved. Trademarks | Privacy Policy | Terms of Use

webcache.googleusercontent.com/search?q=cache:jxAUF2tcIHIJ:e2e.ti.com/thread/5

3/3