Go Down

Topic: Atmega328 custom board - Erratic Behaviour (Read 2765 times) previous topic - next topic


Hey Everyone.

Bit of Backstory (skip to the problem if you prefer)

My group and I are building a micromouse for a university project.
We have built a PCB based on the SMD AtMega168 and have been developing for some time. Going reasonably well.

We recently got back our new board and populated it with an AtMega 168 again but found its behaviour to be erratic. After extensive code testing and going crazy, it seemed that we were running out of ram, so we upgraded to the AtMega328. Our problems however, continued.

The Problem

We have tested the exact same code to run flawlessly on the old board, but the exact same code on the new board is unpredictable.

Sometimes, the mouse will execute most of the movements we program. Reset and try again, and it may only move one square.
Reset and try yet again, and it may not move at all. No programming inbetween, just resetting (we also tried completely powering off each time)

There appears to be some kind of hardware issue with the new board.
The board came from the same schematic as the old board with only very minor wiring changes. One thing that I noticed was a decoupling capacitor for the micro is now nowhere near where it should be (thanks to autoroute).
Could that cause these issues?

Also tried a 2200uF cap on the 5V rail to see if that helped. It didnt.

Also also tried testing the motor controller (as it was upgraded from an L293D to an SN754410) and checking the crystal on a scope, it seems to be fine, hitting 20MHz on the dot.

Here are some photos of what we're dealing with, just so you can see.

Any help on what we can try would be appreciated as we are all about to go insane.

Thanks in advance!

Team gadget


You should post a schematic and picture of the bare board (top and bottom)
It is hard to give suggestions without seeing the design.

Each decoupling cap should be very close to the IC it is decoupling.
What does your reset circuit look like?
I would check the power supply and the reset line with an oscilloscope.

(* jcl *)


Ground loops?
Floating inputs?

As stated, post your design details and maybe something will pop out.



Oct 23, 2009, 08:39 am Last Edit: Oct 23, 2009, 08:47 am by thoed Reason: 1

Also also tried testing the motor controller (as it was upgraded from an L293D to an SN754410) and checking the crystal on a scope, it seems to be fine, hitting 20MHz on the dot.

What crystal are you checking for 20mhz? The chip can handle 20mhz, but if you're using some libraries and some sketches.. you'll get some whack behavior! Especially when dealing with servos/anything that requires precise timing.
Try using a 16mhz crystal and see if that fixes it.

A schematic would be very useful! But I'm curious as to if you have a pull-up resistor on reset? Not having one can cause the crazy resets, and I can't tell just from lookin at the board.


Hey Guys.

Thanks for the replies!

Since posting before, we have tried putting a combination of a 0.1 and 1 uF cap on the microcontroller, as well as a 1uf cap on the battery input to the motor controller, also tried adding an additional 470uF to the 5V rail near the motor controller as well as a 2200uF cap on the raw power input. All to no avail.

We have since noticed another gift from autoroute, that the right motor PWM track snakes its way through/under the crystal and its decoupling capacitors...
We have just tried running with the internal 8MHz oscilator and early tests prove promising, but we cant be sure yet.

As requested, here are the schematics:

If you want a PDF version of the PCB with infinite zoom (but i dont think any labels) you can grab it at:


Thanks again for the responses, we will soldier on testing...

Team Gadget


Oct 23, 2009, 12:36 pm Last Edit: Oct 23, 2009, 12:41 pm by jluciani Reason: 1
The board needs to be routed properly. You can not route traces underneath
the XTAL. It looks like there are numerous traces crossing the XTAL lines
which is sensitive to noise coupling.

You should remove the XTAL and the XTAL caps and set the ATmega to the
internal oscillator and test the rest of the board.

There are no mfg pns listed on the schematic. Linear regulators are sensitive to
the type of capacitor used. I would check that as well. I am not sure how much
current you are trying to pull from the regulator or the input voltage but
there is not much heatsinking. There should be a ground plane near the regulator
to provide a low impedance connection for the capacitors. This section
needs to be routed properly too.

The XTAL is the main problem.

(* jcl *)


You're also missing decoupling caps between Gnd and Vcc and AGnd and AVcc on the AVR.  These should be placed in close proximity to the IC's pins.


I agree with other posters, two biggest issues:

Crystal should have been mounted physically very close to the AVR crystal input pins with no other traces near it.

.1 mfd caps should be mounted right at the Vcc and Avcc pins to ground on the AVR chip.



Hello again everyone.

Sorry for the lul in response, but product hand in was pretty consuming, many of us lacking in serious amounts of sleep now.

That said, thanks for the replies. Our testing with the internal oscillator enabled, lead us to find that problem with the tracks near the crystal.

After rerouting the motor PWM pins away from the crystal, we finally got a micro controller that was stable! Huge Relief.

As for the decoupling caps, we retrofitted them to the board with no effect on stability, however in future, things are going to get the hell decoupled out of them, with less autoroute...

All the development with the new board went well and Gadget (the mouse) was handed in this morning and we were all quite happy with it.

If anyone is interested I could post up a video of how she runs...

Big thanks to retrolefty and jluciani for regularly posting to help out!

Go Up