possible problems with using the internal osc?

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

Hello,
I am using an atmega32 with the internal oscillator set @ 4mhz. Everything works fine so far: usart @ 9600 baud, bootloader (I think it runs @ 19200), and all other functions I am using. I am using an external 32khz clock xtal for timing functions.

My question: If everything is working fine, is there a reason I should use an external crystal? What kind of trouble has anybody run into usnig the internal osc that I should look out for? Will the micro be less or more ESD sensitive? Is the internal osc unreliable? Will it quit altogether if the ambient temp is below 0c?

Any thoughts and experiences are appreciated. --Karl

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

Read the spec sheet.

The internal RC oscillators are not all that accurate over time, temperature, and VCC. Your serial link may be working now, but if things change, it may stop.

The data sheet also tells you the operating temperature ranges for a given device/speed grade/Vcc.

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

If getting new code into your AVR is dependent on the UART working then it would be bit cavalier to use a clock source that isn't always bound to work. If you are going to stick with the internal RC at least put something in to calibrate it from time to time against a known external timing reference (width of start bit perhaps?)

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

You can check out the application notes page:
http://www.atmel.com/dyn/product...

These application notes might give you some ideas on how to deal with the RC:
AVR053: Calibration of the internal RC oscillator
AVR054: Run-time calibration of the internal RC oscillator
AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC
AVR140: ATmega48/88/168 family run-time calibration of the Internal RC oscillator
AVR308: Software LIN Slave
AVR286: LIN Firmware Base for LIN/UART Controller

These specific application notes should answer any AVR design and crystal questions:
AVR040: EMC Design Considerations
http://www.atmel.com/dyn/resourc...

AVR042: AVR Hardware Design Considerations
http://www.atmel.com/dyn/resourc...

AVR186: Best practices for the PCB layout of Oscillators
http://www.atmel.com/dyn/resourc...

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

Thank for all the responses, especially Mike B. for helping to cull reliant notes to review.

From
AVR186: Best practices for the PCB layout of Oscillators,
and
AVR040: EMC Design Considerations
I read that the external oscillator one of the most sensitive components to noise and ESD. Looks like if I implement
AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC
I should be able to have good usart coms as long as the supply voltage and the temperature hasn't changed appreciably. This should be no problem, since I use the usart for diagnostics and setup routines, and I can just have the calibration occur upon entering that mode.

I remain motivated to avoid using an external crystal since I had a lot of trouble with ESD this winter, and ended up adding zener diode ESD protectors to all inputs an making sure brown out was on, better ground plane and metallic packaging.

I'm actually surprised at how well the internal oscillator has worked for me, I have never had any trouble with the usart communication, I have never adjusted the OSCAL, and the temperatures have ranged from 5c to about 40c, and this has been with a dozen different chips on 3 or 4 different projects.

--Karl

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

??? If you add a 32k crystal, you are adding a crystal. If the goal is good USART comms and perhaps precise internal timekeeping, then you system is less complicated with a "real" crystal.

In either case, if you allow ESD to get to your AVR (and other components) you are going to have problems. Crystal or no crystal. We have no particular problems with AVR crystal clocking even under noise testing. Form my experience I certainly wouldn't fixate on that area. Our grizzled board guy knows how to do that "stuff"--static-resistant drivers/transceivers; optocouplers on inputs where warranted; series resistor and a small cap near the AVR; like that.

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.

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

n81641 wrote:

I'm actually surprised at how well the internal oscillator has worked for me, I have never had any trouble with the usart communication, I have never adjusted the OSCAL, and the temperatures have ranged from 5c to about 40c, and this has been with a dozen different chips on 3 or 4 different projects.

--Karl

Well, "it worked" is not a substitute for "I read the data sheet and did the math".

Why do you think that a tiny fork crystal is somehow more robust than an AT cut crystal?

I would definitely advise that you use the rail-to-rail oscillator configuration, and proper capacitance values, but realistically the watch crystals are going to be more of a problem than the conventional ones, all things being equal. On top of that, you have to do this calibration routine, where if you use the regular crystal, it just works...

I understand your pain with ESD, but I think you're over-reacting.

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

n81641 wrote:

I'm actually surprised at how well the internal oscillator has worked for me, I have never had any trouble with the usart communication, I have never adjusted the OSCAL, and the temperatures have ranged from 5c to about 40c, and this has been with a dozen different chips on 3 or 4 different projects.

--Karl

My experience in previous life is exactly the opposite. Whenever a prototype batch of around 5 board was ordered, about 50% worked with the internal oscillator and the other 50% did not. The boards did have a crystal, but the other guys did not select it, unless serial port did not work.

I just can't believe why they did not enable the crystal as the first thing they got the boards on their hands.

So think hard if you already have a crystal there, that do you want it to be 32kHz crystal with internal RC oscillator, or do you want to use 4MHz crystal (or other crystal) from the start.

There are applications where 32kHz XTAL + internal RC is a must, but is yours.

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

Hi Karl
Put a scope on the 9600 baud serial port and check the baud rate right at power up the first time you turn the system on. Check it an hour latter and I bet you will see the baud rate has changed. Uusually you will see small data errors from this. The problem that usually gets me is the ISP tends to work better with an external crystal. I don't understand this because theroretically an ISP using synchronous data transfer should be imune to this problem.

BTW
If I don't have the cytstal I need, I will usually calibrate the UBRR numbers to the warmed up state. Then I can keep developing while I wait. You just have to remember to wait about 1/2 hour after power on before expecting it to operate properly.

-Karl63

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

Being prone to writing first and thinking later, I was surprised about the last post. There are many opinions about RC oscillator stability. There are various culprits: initial calibration, time, temperature, voltage...

Perhaps Karl, you could put some figures on your experience. I can imagine that several factors can come into play but you only have temperature. Do you live in the Arctic ? Or is the AVR dissipating a lot of heat ?

It should be easy to just measure the period of your cold and hot AVR with a regular XTAL controlled AVR. I definitely would not trust my eyesight to determine the period of an oscilloscope trace.

David.

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

Depends on the scope. :) My trusty old TDS420 can measure very accurately, if you use the 32kSample buffer. Definitely the internal RC drifts, just look at the spec sheet. They tell you just how bad it can get.

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

Well, of course the clock crystal is a another sensitive thing, so yes, my ESD argument makes no sense if I'm not removing all crystals.
This thing is in a box outside, but doesn't use the USART once it's installed, only initially, on the bench, to enter parameters into the EEPROM. Once I'm done with the design, no more bootloader. I'll expect the internal RC to vary with temperature and supply voltage per the data sheet. It will probably see -10 to 50 C. Even if the internal oscillator changes by a factor of 1.5 in the field, the thing would still be OK.

What I conclude from the replies is that the internal RC oscillator does preform just as the datasheet says, but depending on the initial calibration and the temp and supply voltage, the USART may not work.

Thanks for all the input! --Kar