6

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?

mFeinstein
  • 4,293
  • 11
  • 45
  • 84
  • "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
  • Post snippet of schematic with just the MCU, or perhaps link to schematic? Or if you can't share thats ok. – geometrikal Dec 22 '13 at 23:17
  • @geometrikal the MCU has 2 pages of the schematic hehehe and still it's not use because there is much connected to it – mFeinstein Dec 22 '13 at 23:26
  • Trying to think outside the box here... there is nothing UNDER the board that could be randomly causing a short? – geometrikal Dec 22 '13 at 23:47
  • Nope, I always run my boards in a isolated surface – mFeinstein Dec 22 '13 at 23:49
  • My new guess is maybe a shoot-trough in the CMOS logic input pins...since there is no bus-keeper in the MCU, maybe one pin is in a leve that can turn an internal short circuit, so I will look the schematics for that now – mFeinstein Dec 22 '13 at 23:50
  • 1
    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 00:16
  • Well, apparently, that's not that unusual. Here's a [video of something similar](http://www.youtube.com/watch?v=BMA7OVjm0HE) I found on YouTube. Oh boy! Electronics never ceases to amuse me. – Ricardo Dec 23 '13 at 00:18
  • @Ricardo, I wasn't driving the LED with the MCU, I was driving an external LED with a MOSFET and the MOSFET was driven by the MCU...yes it kept going but usually as soon as I saw the fire I turned it off...and then on again...and it was like new, no fire, no nothing, running the code as it should... – mFeinstein Dec 23 '13 at 01:00
  • @Ricardo in the video you posted, probably the LED is connected directly to Vcc to show that there is power, and the MCU is not driving it. – mFeinstein Dec 23 '13 at 02:01
  • @mFeinstein Right, that's why I think a video of your stunt would be a hit. – Ricardo Dec 23 '13 at 11:04
  • @Ricardo probably, but still I am not sure how the burning starts so as soon as I figured this out I will let you know. – mFeinstein Dec 23 '13 at 19:24

2 Answers2

3

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.

Turbo J
  • 9,969
  • 1
  • 20
  • 28
  • 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
1

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

enter image description here enter image description here

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)?

alexan_e
  • 11,070
  • 1
  • 28
  • 62
  • 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
  • I am new to the AVR world, thanks for the advice, the PICs datasheets usually have max current table – mFeinstein Dec 22 '13 at 23:44