AVR circuit resets on its own and inconsistent oscillator

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sure this is probably related to heat, but I'm not sure how to alleviate it. I have an ATMEGA64 driving a whole bunch of darlington arrays (ULQ2003). When using my wall wart, this circuit works fine, when using a 12V car jumpstart box, it works for about a minute before I start getting odd behavior. After the first time the circuit resets on its own, it starts resetting more and more frequently.

There are four separate 7805 regulators (each is decoupled w/ a 0.1 uF ceramic cap) on the board. Each one drives a separate piece (they're not in parallel). The inputs of all the switched loads and the ULQ2003 darlington arrays are tied in to one of three 7805s, the fourth 7805 drives the microcontroller circuit. All grounds are connected. To turn on one item in the circuit, an output pin of the MEGA64 drives the base of a darlington in one of the arrays.

While the 7805s get hot to the touch, I can still touch them without burning myself. When on the wall wart, I measure 7-8 volts at the 7805's inputs and about 4.4 at their output. On the battery (I don't think it's very good), it's about 10V at the input, and about 4.5V at the output. These voltages seem to remain consistent, even when the mcu starts resetting, so I don't know if it's due to a brownout or not.

Like I said, it works flawlessly on my wall wart, but craps out on the battery. I assume it's that the battery can supply more current, and things are going into thermal shut-down, but the voltages that I'm measuring don't seem to indicate this.

If anyone has any suggestions, I would greatly appreciate it.

-Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
When on the wall wart, I measure 7-8 volts at the 7805's inputs and about 4.4 at their output. On the battery (I don't think it's very good), it's about 10V at the input, and about 4.5V at the output.
Have you tried heatsinking the 7805? Also for normal 7805s (not the low dropout version) you need a MINIMUM of 2.5 V between input and output so the 7V above may be asking for trouble. One more thing, check for ripple with the battery charger as the voltage may fluctuate if there isn't enough filtering. Apart from that you should be able to feed well above 10V to the regulators provided that you don't go above the maximum ratings.
The 4.4 and 4.5V at the outputs seems fishy, the minimum output should not be below 4.75V for a 7805.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, you might try reading the MCUCSR register after one of the resets. This will tell you which of the resets got you. Just from the description, I would suspect the brown-out reset. I'd be surprised if the 7805's are going into thermal shutdown if you can still touch them. They can get VERY hot and still operate (125C).

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Turns out that it was a poor connection. I'm using a car booster pack as my power supply. I was getting only a power-on reset. I also was surprised to see that the MCU would start with a brownout condition on the wall-wart -- I guess from power ramping up.

I've still seen some really weird oscillator behavior. One of the functions of my device scans LEDs and does some animation. Sometimes the animation will go at varying speeds, or even stop completely, but the scanning still appears to take place, and a watchdog reset is not engaged. This doesn't appear to be a firmware issue at all, as it's very inconsistent (it can run for hours with no problems, but if I reset it, it may start screwing up immediately) and my firmware is very simple.

I've come to the conclusion that I will use external oscillators on all of my new devices. While an internal oscillator is nice on a breadboard, I feel that it makes for risky development, and causes difficulty when your fuses get corrupted. I could only imagine how badly you could screw up a production run by misprogramming a fuse and killing your clock.

-Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
...I could only imagine how badly you could screw up a production run by misprogramming a fuse and killing your clock. ...

Ummm--no matter what your application, or what the fuse settings, are, a mis-programmed fuse could very well cause the target to be non-operational. I guess that you could argue that an external oscillator (not crystal) might give a valid clock whether the fuses were set for crystal, internal, or oscillator? That would be close; but I'm not going to put oscillators on any of our products, probably.

Another example: Setting brown-out level to 4.3V on a 3V Vcc system. Another: WDTON. Another: Bootloader verctor selection. I'm sure there are many other fuse combinations I could come up with.

Think of it this way: The fuse word(s) are just another couple "flash instructions". If you mis-program any other "flash instruction" your app may not operate at all!

Sure, production "projects" need the correct combination of flash, EEPROM, fuse, and lock settings. But properly set up, programming the proper fuse mask should be no different from a production standpoint than using the correct flash image.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.