# Can a wrong crystal oscilator capacitor burn the MCU?

Short story:

I am using an Atmel AT32UC3C2512C MCU and I selected a 20MHz crystal oscillator for it and two NP0 10pF capacitors. I was in doubt between 10pF, 15pF or 22pF, so I decided to start with the smaller one. Can this burn a MCU?

Long story:

The PCB is really a high density one and I use all of the 64 pins so I can't place the whole schematic and PCB in here. In the first time I turned the circuit on the LED connected to a GPIO turned on (which I think it wasn't supposed to do so, since usually the pins comes as inputs from the factory and the LED needed a HIGH output to turn on) and was very dimm...after some research in the immense datasheet it appears that I placed the LED in a pin that can't handle a LED (Murphy strikes again)...in my defense, the datasheet didn't provide enough information on pins current, the only hint I have for this is the drive strength of the pin and some examples, but no real data is provided.

I removed the LED and after playing a little in Atmel Studio the MCU burned...surprisingly it kept running! So I was able to code more and still with the MCU catching fire several times, it kept running. So after a while it just burned for good (usually reconnecting the power made it stop catching fire and operate as it should, but after a while, just by connecting the battery will make it light up and pop smoke).

So no surprises there, the LED pin couldn't handle too much current so I probably burned the port and the MCU became unstable. So I replaced the MCU for a new one....and in the first programming session it burned too! A brand new one! No LED connected to the wrong pin....all pins set as inputs with pull-ups...the fire (yellow glow light with smoke) started in the vicinity of the MCU's internal regulators pins, which are just on the side of the oscillator pins. I checked all voltages and the rails are clean and stable. I can program the MCU, and run it fine using the internal oscillator, but sometimes, randomly it catches fire, so I am afraid of turning it on every time! It's like "Russian roulette".

So my current guess is that maybe the crystal's capacitors made the MCU unstable, or the small burned pieces of flux from the previous MCU that I couldn't remove are acting as stray components and changing the behaviour of the MCU.

I checked all the pins before turning on for possible shorts with the next pin and all were clean. Have anyone else used this MCU and experienced something like it?

EDIT 1:

It's a wild guess but it could be it so I would like to hear opinions about it: I have some pins connected to N-MOS Transistors pulled down by 10k resistor, so if the MCU came from the factory with all it's pin pulled up as inputs (and the datasheet states that the internal pull-up resistors can range from 2k to 16k) so the pin could be placed at 2.5V and since there is no buskeeper this could have destroied the port.

It's a wild guess because the fire didn't came from this pins but from the internal regulator pins and the Vcc connected to another port (the LED port, which makes sense for the first MCU but not for the second)...comments?

• "So I was able to code more and still with the MCU catching fire several times, it kept running." hahahahaha cool :D ... If you remove the external oscillator and run off the internal does it still burn up? I think you have to post your schematic. Use DMM to see if any port pin has a short to ground. – geometrikal Dec 22 '13 at 22:44
• Have you actually probed the oscillator pins? – Matt Young Dec 22 '13 at 22:50
• @geometrikal as I said in the text, I am running in the internal oscillator (the second MCU never got to run in the external). All pins were inputs with pull-ups so even if they were shorted to ground or Vcc they should have survived...and yes it's a very roboust MCU I can say hahaha And my schematics are 5 pages long :( – mFeinstein Dec 22 '13 at 23:06
• @MattYoung, I disabled the external oscillator so when I probe them there isn't anything to see...I am afraid that maybe it overloaded the MCU and made it unstable for future use, even with the pins disabled...it's a wild guess...but I dont have much... – mFeinstein Dec 22 '13 at 23:08
• That's impressive! The MCU cought on fire and kept a LED lit? I've never seen anything like that! You could film it and post the movie somewhere. That would be a hit on YouTube. Seriously! – Ricardo Dec 23 '13 at 0:16

the fire (yellow glow light with smoke) started in the vicinity of the MCU's internal regulators pins, which are just on the side of the oscillator pins.

This is why labratory power supplies have a current limiter...

You have a very strong short, most likely a VCC pin connected to GND or a GND pin connected to VCC. Shorting a GPIO usually does not (much) damage because of R_DSon in the GPIOs driver. Triple-check your schematic an layout for errors with power pins.

• Is it there a difference between "VCC pin connected to GND" to "GND pin connected to VCC"? :P jk....I have the MCU connected to a LDO which does current limiting in 250mA so this is what is probably saving me from a total destruction...but I triple checked (with a DMM also) and cant find anything...and if this was a strong short, it will burn every time, but it's almost never, and totally random. – mFeinstein Dec 22 '13 at 23:20

In the first time I turned the circuit on the LED connected to a GPIO turned on (which I think it wasn't supposed to do so, since usually the pins comes as inputs from the factory and the LED needed a HIGH output to turn on) and was very dimm...

That is the effect you get when you connect the Anode of the LED to a pin configured as input with the pull-up resistor enabled, the current that is sourced through the resistor is enough to dim the LED.

the datasheet didn't provide enough information on pins current, the only hint I have for this is the drive strength of the pin and some examples, but no real data is provided.

In the datasheet in the electrical characteristics it says

which I thing describes the pin driving capability pretty well.

Regarding the effect or the crystal, I don't see a way for what you describe to cause a problem that can lead to the destruction of the chip.
I think your problem may be caused by overloading the I/O pins, have you used proper resistors in all the devices that are connected to the I/O pins (like transistors, LEDS etc)?

• Good, I didn't thought about the pull-ups being factory enabled...still it was very dimm and short before the third fire the led turned off completely, so I reconnected the power and it was dimm again...I don't know if this help in the diagnostics hehe – mFeinstein Dec 22 '13 at 23:12
• Also, I was expecting a Current Table, and this is a Voltage table with current references for the measurements results. Which means it's not an absolute maximum, it just says "hey if you consugme 3.5mA I assure you the pin will have at least 4.5V" but what it I consume 5mA? See it's more like an example....anyways, I know I should have guided myself by this table, but the datasheet was so long I missed it because I only saw it was a voltage reference table and didnt payed much atention to the currents in the side...my bad I know :/ – mFeinstein Dec 22 '13 at 23:16
• Yes, I have resistors for all the MCU pins connected to external stuff and still it catched fire with no activation of nothing...all pins were defined as inputs with pull-ups – mFeinstein Dec 22 '13 at 23:22
• I am thinking maybe the lack of a buskeeper made the CMOS pins shoot-throug...just thinking... – mFeinstein Dec 22 '13 at 23:26
• @mFeinstein Voltage table with current references That is not what the table says, if you have seen the graphs included in other AVR devices then you know that as you sink/source more current the voltage starts to rise/fall. The table takes as High state acceptable voltage drop the Vdd-0.8v and as acceptable Low state voltage rise the 0.5v and specifies the output current that cause this effect. By the way you shouldn't really use any value near the absolute max ratings of the mcu. – alexan_e Dec 22 '13 at 23:27