Ok, that's cool, but I didn't say OFIFG was read only, what I said was that XT2OF in FLL_CTL0 was read only and the example from Ti showed it being changed. Most definitely, OFIFG is rw and needs to be cleared in SW. -Mark
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Harry Lemmens Sent: Thursday, June 19, 2003 9:46 AM To: [email protected] Subject: RE: Starting up XT2 (Was: RE: [Mspgcc-users] Re: MSP430F149 & RF RS232 help...) Mark, I agree, the documentation for some of the MSP peripherals is confusing. I just looked at SLAU49B.PDF (section 7.4.4 and section 7.5., and the documentation in 7.4.4 clearly shows clearing the flag (in assembler) see below ... Section 7.5.x also shows the bit as being read/write 2) Clear the OscFault flag. 3) Wait the required delay. 4) Test the OscFault flag. 5) Repeat steps 2 through 4 until the OscFault flag remains cleared. L1 BIC.B #OFIFG,&IFG1 ; Clear OscFault flag MOV #0FFFh,R15 ; Move delay value to register L2 DEC R15 ; Decrement delay value JNZ L2 ; Repeat until zero BIT.B #OFIFG,&IFG1 ; Test OscFault flag JNZ L1 ; Repeat if necessary I vaguely remember following this example. Somewhere in the documentation there is a discussion about what method should be used for oscillator startup detection. Anyway, whatever works. I do remember trying to get a project out that was behaving strangely at power up, and the outcome was that the osc was bouncing, only successfully starting after power had been off for a long time. Since the project was past its deliverable date, the fault needed rectification asap, and the above code did the trick. I also know that if you start the XT2, and just wait for some time, you seem to have a very good chance that the crytal oscillator wll in fact be running. Just trying to find a reference to FLL_CTL0 in the SLAU49B.PDF. It only mentions FLL once, and says "for supported devices"? Whatever, the reason I posted the code was that Helio clearing tried switching straight from the DCO to the XT2 oscillator after switching the OSC, and that would definitely cause the kind of grief he was having ... Cheers Harry -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Mark Stokes Sent: Thursday, June 19, 2003 10:54 PM To: [email protected] Subject: Starting up XT2 (Was: RE: [Mspgcc-users] Re: MSP430F149 & RF RS232 help...) I don't understand why you are testing OFIFG when really, XT2 is all you are interested in. After reading the (Write only)docs, I have come to the conclusion that the method I am using for XT@ stabilization will work fine (and is faster). Here's what I'm using: unsigned long int templong; // Doesn't have to be long // ***** Wait for SMCLK to report no error port2.out.pin5 = 1; // set a bit for test FLL_CTL1 &= ~XT2OFF; // clear bit = high freq xtal on templong = 50000; // loop until flag is clear while ( FLL_CTL0 & XT2OF ) // test high freq osc fault flag if ( !( templong-- ) ) {// Timeout waiting for XT2 // Tell the user about xt2 // error and deal w/ it (code removed) } port2.out.pin5 = 0; // clear that bit Using my scope, it shows this taking about 6.245ms with Fxt2 of 8Mhz. This sounds about right to me. According to the docs, OFIFG is a confusing bit. The manual clearly states: "The OFIFG oscillator-fault flag is set and latched at POR or when an oscillator fault (LFOF, XT1OF, XT2OF, DCOF set) is detected.". So, by testing this bit, you are actually checking all the oscillators, not just the XT2 Osc. Check out the example from TI labeled fet440_clks2.c (part of slac019.zip). I realize this is for the FET440, but the osc's work the same. This example is a bit confusing because B Merritt has decided to consume more current by writing to a read-only bit. That's why I came up w/ this code. The docs also state that these bits are automatically cleared by Hardware, so there is no need to manually clear them. I am also unsure of the desire to simply sit around and wait for a bunch of clock cycles and then test the flag. Seems to me, you want to get things going. If you want to wait some time after the osc is going, then do that after it goes clear, not arbitrarily. Any thoughts? Enjoy -Mark Ti's examples can be found here: http://focus.ti.com/analog/docs/analoggencontent.tsp?templateId=5246&nav igationId=10032&familyId=342&path=templatedata/cm/general/data/200209msp 430codeexamples Or, go here: http://www.ti.com/msp430 and click on Design Resources (left bar) and then Code examples. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Harry Lemmens Sent: Wednesday, June 18, 2003 8:20 PM To: [email protected] Subject: RE: [Mspgcc-users] Re: MSP430F149 & RF RS232 help... You cannot switch directly to SMCLK after turning on XT2. You must wait in a loop testing the oscillator flag. Even after this flag indicates the oscillator is running, you must wait some time as the osc is still "bouncing" around in level as it stabilises. The following I posted several days ago. It is not optimal, but it does seem to get around most HF oscillator problems in an MSP430F149. (in fact, the code is fairly messy) // attach HF crystal (8.000MHz) to XT2IN/OUT BCSCTL1 &= ~XT2OFF ; // enable xtl2 do //wait in loop until crystal is stable { IFG1 &= ~OFIFG; } while(OFIFG & IFG1); // But, the osc has only indicated that it is running, instability is still possible in fact, seen it all the time in prototypes! so ... NeedHFXTAL: for (TimeFix = 0; TimeFix < 2048; TimeFix++) // osc bit indicated ok, now give another few thousand cycles to stabilise { IFG1 &= ~OFIFG; // continuously reset the osc fault flag } if ( (IFG1 & OFIFG) ) goto NeedHFXTAL; // osc fault flag is still set BCSCTL2 = SELM_2 | DIVM_0 | SELS | DIVS_0; // This is 0x88, MCLK & SMCLK to XTL2 The only problem with the above is that failure of the HF oscillator will cause the code above to freeze in an infinite loop. Maybe a loop count should be added, and beyond a certain amount of tries, some fault flag should be set. Cheers Harry -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of helick Sent: Thursday, June 19, 2003 4:29 AM To: [email protected] Subject: [Mspgcc-users] Re: MSP430F149 & RF RS232 help... Oi Pedro, Obrigado por responder. Don't worry about the previous code I posted, I mis-read something and ACLK should not have been used since I don't have an external clock source, it's SMCLK now... The problem I am having now is that I cannot detect any signals coming out of TXBUF0. I plugged it in a logic analyser and nothing comes out. Bellow is my setup() function. I don't quite know what might be wrong, my prof. looked over it and didn't find anything wrong either, hopefully you can. Thank you in advance. -helio ---code bellow------ void setup (void) { //port/pin setup for the specialCOMM P3DIR |= BIT4; P3SEL |= BIT4; // Select pins to alternate function //clock setup BCSCTL1 = 0x04; BCSCTL2 |= 0x88; //INITIALIZE serial port 0 UCTL0 = CHAR | SWRST; // 8 bit chars - leave in reset mode UTCTL0 = 0x20; // uclk = smclk UBR10 = 0x01; // 3.6864MHz/9600bps = 384 = 0x180 UBR00 = 0x80; UMCTL0 = 0x00; ME1 |= UTXE0; // Enable Tx0 UCTL0 = CHAR; // 8 bit chars - take out of reset IE1 |= UTXIE0; //enable Tx0 interrupt eint(); } On Mon, 16 Jun 2003 09:39:25 -0300, Pedro Zorzenon Neto wrote: > Hi helick, > > Some radio require CTS/RTS control pins of RS232. Can you send us a > link to SS900 radio datasheet? > > What is the oscilator you are using in MSP430? external cristal? what > is the frequency? You could try to lower the baud rate to 300bps just > for testing purposes. > > Hope this helps, > Pedro > > On Sat, Jun 14, 2003 at 05:18:36PM -0400, helick wrote: >> Hi all, >> >> I am having a little problem. >> I am using my msp430f149 to go out and get some data out of my solar car >> and transmit it out using a RF data radio which understands rs232. >> The program in this message illustrates how I am trying to acomplish this. >> I created a dummy char array filled with 'a' chars, then I just try to >> send it out. The problem I am having is that the radio does not even >> twitch. I know they are working because I have connected them to a couple >> machines and they talked. >> I did get the ckt working, so I am pretty sure it's a problem with my code. >> >> Anyways, here is what I am using: >> - Newlink SS-900 radio (set to 9600bps) >> - max3233eepp rs232 transceiver >> >> I am thinking that maybe I've set my clk/baud incorrectly for >> 9600bps... >> >> I appreciate any help. >> -helio > > --- cut the code --- > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
