Omitting decoupling caps on atmega328

I’m looking to make a custom atmega328 PCB for led wearable projects. I want to know what negative things I can expect by omitting decoupling capacitors.

The board will have an on/off switch, atmega328 TQFP, ISP programming header, 3 pin jack for the ws2812b strip and a 2 pin jack for battery power - most likely 3x AA or AAA or 18650 li-ion, but possible lipoly or even alkaline or a 2A USB brick. I may also have 1 or 2 momentary buttons and possibly other sensors to detect motion to trigger animation changes. I never plan to drive more than 100 or so led at low brightness and < 30 is more typical.

My goals for this project beyond the actual board are to learn about design tools and process for what I’d call “non commercial” applications such as diy costumes or gifts and led props and toys for play. So I can live with the occasional off color LED or a flicker once in awhile. I also want to simplify assembly (I will be soldering) and BOM and price and board size.

My background is comp sci. I’m totally self taught in electronics. I know the theory for decoupling caps and advice is always to add them and that it’s only 3 more components so save your “just add them” replies blah blah… :slight_smile: So my question is slightly different.

If I leave these out what is the worst that can happen?

If you leave them out, the board may reboot or hang unpredictably (this is the typical failure mode). It may also behave in other unexpected ways. It may work under some circumstances, but not others; this makes it challenging, frustrating, and time-consuming to determine whether a given problem is due to a bug in your code or this hardware issue. It may work with some individual processors, but not others (just because the first one you assembled worked would be no guarantee that the next one would, due to process variation).

I have personally had to throw away custom boards I had ordered and get a new batch made due to improper layout of the decoupling caps. A great deal of time was wasted determining this (the actual problem, as I recall, was that this was before I learned how to do a copper pour / ground plane, and while the capacitor was physically close to the chip, the actual electrical path on the ground side was much longer (in turn due to a change I made late in the design) than it should be). After that time-wasting debacle (it took me a long time to figure out what the problem was), I have not questioned the use of decoupling caps.

But if you want to learn the hard way, be my guest.

Oh - and in the department of worst things - under certain conditions, I have seen a malfunctioning processor do something that sets the whole string of LEDs to maximum brightness on all channels. If that were to happen with some of the power sources you described, it would overload the batteries, which would heat up (potentially causing a fire, if it's an unprotected LiPo). Which, on a wearable, would be particularly problematic.

Just include the caps. You can solder on a lot of decoupling caps in time wasted debugging one issue caused by their absence.

Cool. So.

  • Processor reboots
  • Processor hangs
  • Behavior differences from hardware variation

Would battery power effect the likelyhood vs a wall wart?

I suppose it’s theoretically possible for a microcontroller to send the exact high/low voltage signal at the right timing needed to light every led in a stip to 100% on a failure. But it seems astronomically unlikely. Like asteroid impact unlikely. Have you seen this happen ever? Yikes!

Well, there's also the possibility of memory corruption resulting in more complex broken behavior. Those are just the two most likely cases. Just like how if you write off the end of an array, usually it just reboots, but sometimes you get behavior out of the twilight zone - except that case is deterministic, while problems from missing decoupling are not.

Yes it would, but unpredictably - I couldn't tell you which would be worse, and it would probably depend on the code, load, type of battery, state of charge, and the wallwart you're comparing it to.

Yes, I have seen that happen. I am not sure exactly what conditions led to it, either. It is not the result of a well-formed signal, but some sort of glitch that I don't understand. I have seen it a few times, but never figured out exactly what led to it happening. You must always make sure that turning all the LEDs on 100% does not cause damage to anything

If DrAzzy's warning isn't enough (it should be!), I used to build light controllers around TTL shift registers. Same as you. 'what are all these decoupling capacitors for?'. I now know there is no such thing as too many decoupling capacitors, but there sure is such a thing as not enough. Just put them in. Add some extra ones just in case.

I fully understand you wanting to know "why" rather than just being told to do it.

The digital outputs of the AVR device are a stack of two mosfets - one p channel and one n channel. Their gates are tied together so that a high on the gate turns on the lower mosfet and pulls the output pin to ground. A low on the gate turns on the upper mosfet and pulls the output pin to Vdd. BUT... the high to low or low to high transitions do not occur
instantaneously... they may take tens of nanoseconds. As the gates swing from low to high or high to low, there is a period of time where the gate voltage is BETWEEN Vdd and ground and BOTH mosfets are conducting. This places a short circuit across Vdd and ground for tens of nanoseconds. If the AVR power supply cannot supply the current spike, the Vdd can drop below minimum and either crash the CPU or trigger a brownout reset.

Adding low ESR capacitors as bypass acts like a water tower... supplying the momentary pulse of extra power needed to handle the short circuit.

Note that all switching inside the chip has this momentary short circuit effect, not just the outputs.

Without good bypassing, you would be lucky to even have the chip operate past reset!

And, realize that your LED strip will also put lots of switching noise on the power lines, so without bypass caps, if the CPU doesn't crash itself, the LED strip noise will.

(and for the critics, bypass caps do not "block").

Edit to add: The need for bypassing is almost universal. To prevent switching transients from corrupting a digital circuit or to keep noise out of an analog circuit. Bypassing is not just an "Arduino thing".

You must always make sure that turning all the LEDs on 100% does not cause damage to anything

That's good advice for any engineering... ALWAYS design for "worst case".

Without good bypassing, you would be lucky to even have the chip operate past reset!

If only!

This whole situation would be less of a problem on these forums if the parts never worked without the caps, but they often do work in simple cases, and people write guides and schematics without the caps and post them as tutorials because it worked under their simple test conditions and specific chip.... (as far as I can tell, hardly anyone experienced enough to be qualified to write a tutorial actually wants to do so, hence the abundance of decoupling-cap-less schematics in tutorials).

...but they often do work in simple cases...

Like when bread-boarding. The metal plates in the breadboard provide enough capacitance to take the place of actual capacitors.

I can't find the exact reference now, but I am reminded of a story concerned decoupling capacitors told by Jeri Ellsworth (who achieved some fame for, among other things, fabricating mosfets in a simple home lab using silicon wafers bought on eBay) . She designed a product for a toy manufacturer, basically a Commodore 64 on a single chip, and the manufacturing was done in China. She was called to make an emergency trip over there because deadlines were approaching and quality control reported stability problems appearing in the product. The cause turned out to be that in production, someone decided to try to reduce costs by omitting some, in their opinion surplus, decoupling capacitors.

Some of her videos are quite interesting. Google.

They also interfere with Wi-Fi, as I found out when I first tried using an ESP8266 on breadboard.

On a (sort of) related note, I've found that Arduino boards like the Uno and 2560 are quite sensitive to the oscillator stopping if the board is held in a bare hand.

This is caused by the oscillator fuse bit being set to "low power" instead of "full swing".

On the scope the crystal/resonator runs at about 1V P-P centered between Vdd and gnd, while in full swing mode it is within 100 mV of the rails P-P.

Also, at full swing the oscillator is completely stable even even if the board is handled.

Why a stock Arduino is not set to full swing is beyond me. If a few milliamps are so important, a much better thing to do would be to delete the power indicator LED.

And in case anyone is worried, no, using full swing mode does not "block". :roll_eyes:

Why a stock Arduino is not set to full swing is beyond me.

  1. EMI?
  2. AFAIK newer ATMegas have the full swing option removed. (It is in Errata for Rev K in my version of the Datasheet.)

On a (sort of) related note, I've found that Arduino boards like the Uno and 2560 are quite sensitive to the oscillator stopping if the board is held in a bare hand.

Sweat? Humidity?

I wonder if there's a ground plane under the crystal.