I have a off grid lighting product deployed in rural Tanzania that has been experiencing a high rate of MCUs getting fried.
I suspect it is being driven primarily by overvoltage on Vcc (which I am dealing with by switching from buck converter to linear regulator), but I am also starting to wonder if these MCU BBQs are being caused by strange analog front end stuff with my design. Before I post all the details, here are the questions I'm hoping the community here can help me with:
- If I select AREF to be the internal 1.1V bandgap reference, do I fry the MCU when I apply more than 1.1V to an ADC pin?
- If I use an LC filter on the AVcc input (as directed in datasheet), can I fry the MCU (particularly if I'm enabling/disabling the ADC frequently -- like say 4 times per second)
- What do you think is the most likely cause of the failures I have been seeing reported (see pictures below).
I recognize this post may be viewed by others as an engineer trying to get another to do my work for me, and if you feel that way then keep in mind its for a good cause (rural lighting to the poorest villages in Tanzania). All I'm looking for here is a yay/nay about whether you think I'm on the right track in my hunt for the strange events that are causing the magic smoke to escape from my MCU.
Thanks in advance!
Schematic, PCB footprint
ATMEGA328PB running at 8MHz (internal) with following peripherals connected:
- UART communications
- External pullups
- 1k series input resistance
- Momentary Pushbutton
- Active 5V (direct) input
- 10M pulldown
- 4 Analog inputs
- Fed from quad op amp (voltage followers with high-impedence voltage dividers driving inputs)
- also a current sense op amp
- Some FETs
- Control external loads
- One FET is high side switch that turns on/off Vcc to op amps
- 32.768 kHz external crystal
- 4 LEDs run off of the i/o pins of MCU
- 15 mA each (60 mA when all are turned on)
My BBQ'd MCUs
Who doesn't love the smell of burning silicon?
Can you tell anything about how the MCU failed when you simply look at the corpse of one? It definitely seems like burn marks are usually aligned with the location of Vcc or AVCC pins, more or less..
- Overvoltage on Vcc (Buck converter output spikes)
- I am already addressing this in next iteration of my PCB by using a linear regulator instead of buck converter
- Overvoltage on ADC pins
- According to datasheet, max ADC pin voltage is Vref
- In my application I am using internal 1.1V bandgap of MCU as AREF
- This suggests that I am in violation if any ADC pin sees more than 1.1 V, right?
- Overvoltage on AVcc (LC filter inductive spiking?)
ESD via discharge through plastic pushbutton plunger into MCU pushbutton detect pin
- Overvoltage on UART lines
- Seems like unlikely cause because I have 1k series resistors here
- I have tested shorting UART lines to 12 V but observe no MCU BBQs
Overvoltage on ADC pins
I think I may be in violation of the max allowable voltage on an ADC pin when I apply power to my op amps, because when they get their 5V rail "turned on" (via high side FET), they will probably have their outputs saturated which will result in overvoltage and/or latch-up conditions as described in this analog semiconductor app note. This means that my op amps may be supplying 5V signals to my ADC pins. Would that result in the MCU frying?
Does the Vin < Vref condition mean that if I configure Vref to be AVcc instead of 1.1 internal bandgap that I can simply switchover Vref and suddenly be in compliance with datasheets ADC ratings?
Overvoltage on op amp input pins
I am also in violation of the input voltage range of the op amps because when I stop supplying voltage to the op-amps +5V rail, the voltage at the non-inverting terminal of each op amp is still as high as 1 V...
Could this be involved in frying MCU?
LC Filter on AVcc
I have implemented a LC filter as per the suggestions of the datasheet on my AVcc supply, but now I'm wondering if that is another example of "bad datasheeting" for the ATMEGA328PB, as has been discussed elsewhere
Here is what the datasheet says on the subject on LC filter on AVcc. Doesn't make it sound optional, does it?