msp430 xtal oscillation failure - Page 1
Forum section: electronics / general

author: electrolust
author_rank: Unknown
timestamp: December 15, 2016, 12:38:34 am
content: I'm having a problem with an msp430g2221 xtal oscillation failure.I'm using the TI MSP-TS430PW14 test board. I've soldered an MS1V-T1K 32kiHz xtal on the board (there's a spot already there for it). I got the xtal from a launchpad kit. The xtal wants 12.5pF load, which I have selected on the MCU (internal load capacitance). I assume this is 2x 22pF caps, that plus the stray capacitance will get close to 12.5pF.I'm using "internal" power source (USB/FET supplied), at 3300mV. I can't get the board to work with external power for some unknown reason.The xtal starts up fine, and quickly (few ms). If the CPU is in LPM0, everything is fine. If I select LFXT1 (xtal) for ACLK and route ACLK to P1.0, I can see the 32768 (exact) Hz signal. If I enter AM, just a while(1) loop, I take an NMI for oscillator fault. If I have ACLK on P1.0 I can see that the xtal does go berserk. If I re-enter LPM0, the xtal restabilizes. I'm running MCLK at the calibrated 1Mhz frequency. It also fails if I run MCLK at the lowest frequency (RSELx=0, DCOx=0, MODx=0).There are 10uF tant and 100nF ceramic bypass caps near VCC on the test board.Here is my scope trace. Ch.1 is ACLK/P1.0 and ch.2 is VCC. Note the ringing on BOTH channels!A 4ns rise time calls for 87.5Mhz scope bw (.35/rt). I have a 200Mhz scope with 350Mhz passive probe. The probes are compensated correctly. If I probe my function generator at 1kHz and 8.4ns rise time (fastest it can do), I get a pristine signal, no artifacts and right at 8.4ns rise time. So I don't think that the ringing is an artifact of probing.Note also the faint trace on ch.2 showing evidence of bad power supply ripple. It looks to be on the order of 1V. wow.Also, this isn't an artifact of putting the ACLK/xtal signal out onto P1.0. If I don't route the signal to any pin, I still get the osc fault in AM.As noted above, I am unable to run the board on external power with the FET attached. But if I disconnect and just run it as a standalone board, with a good lab power supply, I still get the osc fault when I enter the while loop. I tried at 3.3V, 4.5V and 5.0V.Another curiosity is that the loop that waits for the xtal to stabilize is itself a while loop. Why does that loop exit ok without fault and then it goes on to fault when I enter the next while loop? The real code (as opposed to my reduced test case) waits to the xtal to stabilize then goes on to configure USI. That part works. After that I enter a delay loop and that's when it fails. I don't understand what would be the difference between tight looping and some other sequence of instructions, that would make a difference. Perhaps the loop instructions require few cycles and gives less time for power to stabliize?I tried 2 different g2221 chips and they both exhibit the same behavior.

author: electrolust
author_rank: Unknown
timestamp: December 15, 2016, 09:18:05 am
content: Here's the schematic for the test board. Note that my probe points are at the J1 header. J4 is not connected. For VCC, I'm probing "off to the side" of the VCC pin connection to the power rail and the bypass caps. That shouldn't matter should it?

author: electrolust
author_rank: Unknown
timestamp: December 15, 2016, 07:05:53 pm
content: So I'm thinking I must be picking up the VCC noise?I do see that on the test board, which is 2 layer, they don't follow any of the slaa322c (ie, their own) recommendations for PCB layout. The traces are "long" (approx 3cm, unequal length AFAICT) with lots of vias, no guard ring and no ground island. The optional external cap lands are not equidistant.Without any "production" or even lab experience here, just based on what I've learned from the interwebs and this, my first experiment with a xtal, I'd say the board design is poor and that's why it fails when the CPU gets more "switchy".But, this fails the benefit of the doubt test. I mean this is a$90test board fromTI. Why even put a spot for a xtal on the board if it's unusable in practice.I already have a PCB made for my actual project. I'll populate some minimal components on the board (MCU, bypass caps, xtal) and see if I experience the same results.In the meantime, please chime in with any other suggestions.

author: electrolust
author_rank: Unknown
timestamp: December 15, 2016, 11:40:28 pm
content: Quote from: electrolust on December 15, 2016, 07:05:53 pmMy actual PCB worked. So I did get a valuable first hand education in PCB layout technique (about noise in general as well as xtal-specific), but I can't begin to express how disappointed I am in TI.

author: electrolust
author_rank: Unknown
timestamp: December 16, 2016, 07:17:56 pm
content: Ugh. Well my minimally populated board did work. But when I fully populated it to "complete" the project, it no longer works. I trip the fault when the CPU is busy, 100% of the time, just like with the TI test board. The clock does recover when the CPU goes idle, just like with the test board.I have a ground island under the crystal, a guard ring, no lands for external caps, very short traces (3mm or so) to the crystal, symmetrical layout, no traces crossing under or nearby.No one has any ideas on this? To summarize it, I think I have 2 basic questions. Why is my crystal layout not good enough, and why is there so much noise to begin with!I went with a crystal in the first place, instead of an oscillator module, because I couldn't find a module at 32k (must be 32k) and with gullwing leads that I can hand solder.

author: Cervisia
author_rank: Regular Contributor
timestamp: December 16, 2016, 08:09:29 pm
content: QuoteThis sounds as if there is something wrong with your unknown power source.QuoteThis sounds as if there is something wrong with your unknown power source.

author: Fred27
author_rank: Unknown
timestamp: December 16, 2016, 08:29:13 pm
content: There are a lot of things you've not ruled out before blaming TI. I've never heard of anyone have similar issues so perhaps there is something simpler going on that a bad IC design that just happens to have just impacted you.How's your code? Have you tried one of the simple examples TI give in MSPWare to rule out incorrect configuration? Have you tried a different xtal in case that's faulty? Or external load capacitors on the TS430 board?

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 02:03:16 am
content: Quote from: Cervisia on December 16, 2016, 08:09:29 pmWhen I use an external power source (with the FET disconnected), I'm using a Sorenson XEL power supply. I haven't independently measured it's capabilities but it's not a garbage supply.Should I maybe try a battery?Quote from: Fred27 on December 16, 2016, 08:29:13 pmThis guy who is my goto guru also has this sentiment but doesn't have an answer otherwise either.QuoteI basically copied the simple example code. I've tried 2 xtal from 2 manufacturers. MC and Citizen. Note again, the crystal starts up very easily and runs at precisely 32768 Hz. I'd expect (maybe I'm too noob to know better) that if there were a load capacitance problem it would be exhibited in slow startup and noticeable frequency error.

author: Monkeh
author_rank: Super Contributor
timestamp: December 17, 2016, 03:35:12 am
content: Show your exact code, and your layout.

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 09:53:11 am
content: The code is as simple as you would expect.Code:#include <msp430.h>int main(void) {WDTCTL = WDTPW | WDTHOLD; // stop watchdog timer// port initialization (all out low)P1DIR = 0xFF; P1OUT = 0;P2DIR = 0xFF; P2OUT = 0;if (CALBC1_1MHZ == 0xFF) // if calibration constant erased ...while (1)LPM4; // ... the endDCOCTL = 0; // select lowest DCOx and MODx settingsBCSCTL1 = CALBC1_1MHZ; // set DCODCOCTL = CALDCO_1MHZ;// xtal setupBCSCTL1 &= ~(XTS | DIVA_3); // LFXT1 LF; ACLK/1 (these are default)BCSCTL3 = LFXT1S_0 | XCAP_3;// allow time for xtal to start (typical measured ~7ms)unsigned int i = 65535; // 4.25s @ measured ~65 us per loopdo {IFG1 &= ~OFIFG; // clear OFIFG__delay_cycles(50); // min 50 us delay per slau144} while (--i && (IFG1 & OFIFG));volatile unsigned int n = 65535 - i;__no_operation(); // n can be inspected hereIE1 |= OFIE; // handle xtal fault in NMI#if 1__delay_cycles(2000000UL); // fault#endifLPM0;}#pragma vector=NMI_VECTOR__interrupt void nmi_isr(void) {P1OUT |= BIT0; // LED on}If you change '#if 1' to '#if 0', there is no fault.I attached a diagram of the TI test board. It doesn't show traces but it's good enough to get the idea. There are actually 2 parallel locations for the xtal. The square outline as well as the area where the xtal symbol is seen. That area where the symbol is, is where the MC MS3V-T1R crystal fits. It isn't shown very well in the diagram. It has extremely small lands for the wire connections and a very small area to solder the case of the crystal to GND.

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 10:03:04 am
content: Quote from: Fred27 on December 16, 2016, 08:29:13 pmOf course there are tons of things I've ruled out. That's why post#1 is so long, I've tried to explain how any number of simple things that could be wrong, aren't. I wish instead of just making that statement you would actually describe at least one  thing I should rule out.I also find it highly suspect that this would be some TI problem. No one, no one, has described this problem online on any forum or mailing list, including on the TI forum. It really seems that it must work, that it must be something I am doing.However I just cannot figure out what I have done wrong, or even what else I should do to find the problem. AFAICT I've basically done everything that is recommended when using a xtal.

author: Fred27
author_rank: Unknown
timestamp: December 17, 2016, 10:08:26 am
content: Quote from: electrolust on December 17, 2016, 10:03:04 amIf you quoted the paragraph after that, it's fairly obvious I list 4 things for you to try.Being rude is a quick way to dissuade people from making the effort to help you. Good luck finding the problem.

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 10:14:16 am
content: Here's a thought.When it was working with my minimally populated board (my own board design cf. the TI board), I was just applying 3.3v with my lab power supply.When I fully populated the board and it stopped working, I was applying 5V and the MCU was getting 3.3V power from an on-board TPS71533 voltage regulator, bypassed with 10uF ceramic and 100nF ceramic caps. The 100nF is a few mm from the MCU VCC pin, on the other side of the board through a via, grounded to an internal ground plane through another via.I'm reluctant to start getting into a discussion of my own board design unless we agree that the TI test board is bad somehow and actually not expected to work. I just thought the power supply difference between the 2 cases was interesting data.

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 10:18:06 am
content: Quote from: Fred27 on December 17, 2016, 10:08:26 amSorry about that, I did all those things except the external caps. I didn't try external caps as it would imply the internal caps are broken, which seems absurd. I did those all before coming here for help.I did miss that entirely because of your statement that I haven't ruled out many things, when in fact I have ruled out many things. Which I thought was rude and dismissive. It's just late for me here, again sorry about that.I actually did answer your questions already as well. So I don't even know why I chose to backtrack again on it. yeah, getting very late for me ...

author: electrolust
author_rank: Unknown
timestamp: December 17, 2016, 06:13:23 pm
content: hmmContinuing the line of thought from #12, the oscillator circuit is a resonant analog circuit, yes? Bad power supply ripple probably has a poor effect on that. So, agreeing with Cervisia, maybe I do have some power supply problem. I'm quite surprised that the power supplied by FET board (3.3V from USB, battery powered laptop) would be so bad?I will revisit 2x3 configurations and see what happens.my pcb / TI test pcb5v power through regulator / 3.3v power "direct"test pcb: with/without jtagbut even with a slightly dodgy power supply, wouldn't you expect that the 10uf and 100nF caps take care of that? That's the point isn't it?

author: Monkeh
author_rank: Super Contributor
timestamp: December 20, 2016, 07:06:55 am
content: I was unable to replicate any issues in a brief test with a G2553.You may want to experiment with the load capacitance, but as I recall my test crystal wants 12.5pF and I couldn't upset it with XCAP_0..

author: DTJ
author_rank: Super Contributor
timestamp: December 20, 2016, 09:43:51 am
content: You mentioned 'a spot to solder the crystal case ground to' a few posts back.Are you soldering to the case? We did this on a msp430 - 32768 crystal board and had oscillator problems. We abandoned the gnd soldering to the case and the problem went away.

author: electrolust
author_rank: Unknown
timestamp: December 22, 2016, 02:39:55 am
content: In a new test (with TI board) I discovered that the VCC noise is unrelated. If I don't output ACLK, VCC is stable, even when in AM (executing __delay_cycles()). So the VCC ringing is triggered by having a signal output ... I guess that makes sense. But without any output whatsoever, with a stable VCC, I still got OFIFG. So at least I eliminated VCC and bypass caps as the source of this problem.As I went to test my own PCB I found I could not trigger the fault. I also found I never saw an LED b/c I only turn it on in the case of fault. I wasn't sure it was working at all. I added code to turn the LED and ACLK on for 1s at startup. Then off for 1s, then clear any errors and continue as before. Running this new code on the TI board, no failures!Was I just not letting the crystal stabilize long enough? slau144j says 50us is "minimum" so that's what I went with in my stabilization loop. And it worked -- I'd go through a number of loops (50us at a time) and after it exited stable, if I immediately went to sleep it would stay stable. I wonder if 50us is actually not a good value, and the crystal needs to be stable for much longer, under CPU busy conditions, not just in LPM0.I'll try a few more experiments. I don't have a particular startup time requirement so I'll see if there's a threshold (other than slau144j 50us) of stability/instability.DTJ, thanks I'll consider not soldering the case.

author: DTJ
author_rank: Super Contributor
timestamp: December 22, 2016, 06:14:07 am
content: See page 7, there's a sentence about soldering xtal cans to ground.http://www.ti.com/lit/an/slaa322c/slaa322c.pdf

author: electrolust
author_rank: Unknown
timestamp: December 22, 2016, 10:16:59 am
content: Doesn't it say, DO solder the housing to ground?The Citizen crystal I'm using has this spring clip over the case. So the case itself is protected from the solder heat since you only solder the clip.For the TI board (the one that is failing), the Micro Crystal does not have this feature and I did solder directly to the crystal case.

author: electrolust
author_rank: Unknown
timestamp: December 22, 2016, 10:50:02 am
content: Did all the errata sheets just disappear from the TI website?I was going to comment on errata XOSC8. I thought it might have been my problem but then I saw it only affects rev D of the G2231 whereas I have rev E (current is G, why I only have E? old stock I guess).There seems to be only 1 other MCU that is TSSOP14 w/ SPI, F20xx. That would be a dropin replacement for the G2231. But I saw earlier today in its errata that it has the same 2 crystal-related errata, XOSC5 and XOSC8.I just now went to download the errata sheet, and it's gone. No link on the MCU page, and google search for a direct link works but TI says file not found. WTF.

author: electrolust
author_rank: Unknown
timestamp: December 22, 2016, 09:35:54 pm
content: Quote from: electrolust on December 22, 2016, 10:50:02 amErrata links are back. How very annoying.

author: electrolust
author_rank: Unknown
timestamp: December 22, 2016, 10:19:02 pm
content: Problem solved. In my startup loop, I wasn't waiting long enough for the crystal to stablize.slau144j 5.2.7.1 says to wait 50us, although the example code there doesn't show how long it is waiting (it waits for 255*3 cycles but the clock speed isn't documented). The clock would have to be running at 15.3Mhz for the 255*3 cycles to be 50us. At 1.1Mhz (PUC default) it is 700us.The MSPWare sample xtal code for G2221 (msp430g2xx1_LFxtal_nmi.c) waits for 4096*3 cycles @ ~1.1Mhz, about 11ms. WOW. That's an order of magnitude more than the slau144j sample code (assuming 1.1Mhz) and two orders of magnitude more than slau144j actually documents. That sample code itself sucks though, they reset OFIE inside the NMI handler, a no-no per the documentation as it can lead to infinite recursion.I was waiting just 50us, per the documentation. I found the following timing:delay status50 FAIL 100%1000 FAIL 100%1500-4000 100%->10%5000 PASSAs I increased the delay from 1000us to 4000us, I would get less and less percentage failures. At 5000us it passed every time, as long as I cared to test. In my final code I will give it a 2x safety factor and wait for 10000us, close enough to the MSPWare code.What a horrible horrible problem. Poor and misleading documentation is the worst. I still am curious about the VCC ringing but I will start a new topic once I can get my head around bypass caps a little more.Here's the code that ultimately works. On the TI test board, P1.0 is routed to the on-board LED but it's jumpered. P1.0 is the ACLK output so I had to jumper P1.1 to the LED. The ACLK stuff is not required to see the problem though.Code:/** ofifg.c** MSP430G2221** OFIFG testing** I/O connections:* P1.0/ACLK -> ACLK/crystal output* P1.1 -> LED output*/#include <msp430.h>volatile unsigned int toggle = 1;int main(void) {register unsigned int i;WDTCTL = WDTPW | WDTHOLD; // stop watchdog timer// port initialization (all out low)P1DIR = 0xFF; P1OUT = 0;P2DIR = 0xFF; P2OUT = 0;// Set DCO to calibrated 1 MHz.if (CALBC1_1MHZ == 0xFF) // if calibration constant erased ...while (1)LPM4; // ... the endDCOCTL = 0; // select lowest DCOx and MODx settingsBCSCTL1 = CALBC1_1MHZ; // set DCODCOCTL = CALDCO_1MHZ;// xtal setupBCSCTL1 &= ~(XTS | DIVA_3); // LFXT1 LF; ACLK/1BCSCTL3 = XCAP_3;P1OUT |= BIT1; // LED on at startP1SEL |= BIT0; // ACLK on// allow time for xtal to starti = 65535;do {IFG1 &= ~OFIFG; // clear OFIFG__delay_cycles(5000); // min 50 us delay per slau144j 5.2.7.1} while (--i && (IFG1 & OFIFG));volatile unsigned int n = 65535 - i;__no_operation(); // n can be inspected hereIE1 |= OFIE; // handle xtal fault in NMIwhile (1) {if (toggle)P1OUT ^= BIT1; // toggle LED__delay_cycles(1000000UL); // 1s busy-wait}}/* oscillator fault */#pragma vector=NMI_VECTOR__interrupt void nmi_isr(void) {P1OUT |= BIT1; // LED ontoggle = 0; // and stay on!}I kind of doubt this information will actually be helpful to anyone, since I can't find a single other person on any forum or list complaining about this. I guess if you just cribbed the MSPWare code it works, so there you go.The real lesson is, never trust the documentation.