AVR Overclocking - MPU block survey

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

I've searched for "overclocking" and found a few posts, including one from Atmel Norway saying don't do it, it's very naughty :twisted:.

BUT, there are different sections of the MPU which may cope differently with higher clock rates. When I get a bit of spare time, I was going to test a Mega88 at increasing clock speeds, testing if possible where problems start to crop up.

The data sheet says: "The calibrated RC Oscillator is used to time Flash (and EEPROM) accesses." so perhaps increasing clock speed does not affect Flash or EEPROM programming.

My guess is that it would be the CPU which would stand the most overclocking, and that the peripherals such as USART, ADC etc. will start to fall over first. Has anyone else done any experiments?

I don't need to overclock anything right now, but I was just curious as to how much "headroom" there might be.

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

With semiconductors, there's process variation when the chips are fabricated. The manufacturer allows for this as he needs to get the best yield (number of good chips per wafer) as well as being able to guarantee that the chip will work to the quoted specs over the quoted temperature and voltage range. So there's always a little bit of headroom - but this may vary from chip to chip. Atmel don't think it's naughty to overclock, they just don't recommend it. There's been a few people that have done tests and I think it is the cpu/flash that falls over, but then how do we know what fails? I dare say Atmel have done these tests and have statistical proof and know exactly what fails.

Me, I have my hands full with making sure my software and circuits work as expected without living on the ragged edge by exceeding specs.

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

To really test for over clocking failures, you need to also do tests at the environmental temperature extremes and the Vcc extremes. Both low and high. Then add in things like maximum pin current loading for all ports while testing. Still since you probably lack the data to apply your test results to the chip manufacturing tolerances/variables, you will only really get to know the individual chips you physically test. If this is true, then you need to apply a conservative margin to any measured test limits, since you will not have any idea if your measurements are absolute minimum limits below which any chip will work or if they are maximum extreme limits where only a few chips will work.

I'm all for doing it. In fact it will probably be fun for you. Just don't expect to create the AVR tell all over clocking Rosetta stone unless you can take your testing all the way :wink:.

I have always felt that over clocking is acceptable in any hand tuned/maintained one of or hobby project (without factory support or warranty of course). However, if you are designing a product for sale then over clocking should absolutely be avoided. Any current or future problems with over clocking instability/malfunctions, but the AVR still meets ATMEL published specifications, are exclusively the product designer's fault and not ATMEL's fault.

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

This past week I got my servo controller working - except for a small software glitch. I was curious to see if I could shorten the PID loop update time. I replaced the 18.432MHz crystal with a 24.6MHz crystal. Once re-tuned, the PID worked even better then with the lower frequency.

The servo controller incorporates the 10 bit Fast PWM out of OCR1A - non interrupted. It also uses IRQ0 & IRQ1 to translate an optical velocity/position encoder. TIMER0 is used for the PID loop update time - interrupted is 100uS. And, the ADC, is used to determine the target velocity and is interrupted at Fosc/128.

At 24.600MHz, there were no observable ill effects. In fact, like I said, there was an improvement in system performance. Though, in contrast to the whole AVR controller, I'm only using about 15% or so of the total AVR hardware. But understand that even with the performance improvements, I fell back to 18.432MHz.

The next thing I'm going to activate will be the WDT, as I don't think my mill will tolerate a servo motor in runaway at 100 inches per minute. In addition, I'll be activating USART0, with a Tx & Rx buffer and associated interrupts.

So, I think that the AVR has a fair amount of overclocking head-room. But I wouldn't recommend over-clocking. There is a specification in the design for a reason. Yes, I did perform an experiment with over-clocking but... But I will not use over-clocking in a formal design - even for personal use. If I need higher processing speed, I'll move to another class of controller

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

I have heard, in the past, that one of the first things to be effected by over-clocking is EEPROM writes at temperature extremes.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:
I have heard, in the past, that one of the first things to be effected by over-clocking is EEPROM writes at temperature extremes.

Jim

Yeah, I heard that too. I'm hoping to try some experiments eith EEPROM at elivated clock speeds someday. Though, it would be best to have an environmental chamber to collect accurate data.

Maybe whip up an old toaster oven with a small temperature controllers (Omron, or something similar) and use it. Actually, I recently read an article in some trade magazine about this very topic.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

I have run the "L" version of AVRs at double the rated frequency before without any problems. For example, I have run an ATmega16L-8PC at 16 MHz with a 5V supply for a few days till I obtained the ATmega16-16PC instead.

I have a feeling the L and non L parts are really the same thing, they just go through difference quality control checks.

One time, I also ran a 16 MHz AVR at 27 MHz. Although, it was not 100% reliable at this speed. However, it did get the job done for the experiment I was working on at the time.

For a real product, I agree that over clocking is a bad idea.

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

i wonder if the clk quality is kept good, as in the rise and fall times are very sharp then it may be possible to actually take the freq a lot higher. than say the usuall crystal we would use.

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

luvocean1 wrote:
i wonder if the clk quality is kept good, as in the rise and fall times are very sharp then it may be possible to actually take the freq a lot higher. than say the usuall crystal we would use.

That could be a factor.

Just realize that, with the faster edges, also comes more power usage to get those edges to rise and fall faster.

But I'd also suspect that the internal topography play a large part in the equation. As the transitions start approaching the wavelength of the interconnecting pathways within the micro-controller, things will also begin to fall apart.

And too, I'm sure that good bypassing and a stable power-supply will also add benefit.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:
i wonder if the clk quality is kept good, as in the rise and fall times are very sharp then it may be possible to actually take the freq a lot higher. than say the usuall crystal we would use.

The crystal oscillator is meant to be a sinewave! It gets squared up internally so regardless of the external clock 'quality', it would amount to zero difference.

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

microcarl wrote:
I replaced the 18.432MHz crystal with a 24.6MHz crystal.

microcarl, it appears you are still overclocking with the 18.432MHz crystal, are you not? I thought the m128 only allows up to 16MHz?? Just curious...

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

welshzadok wrote:

I don't need to overclock anything right now, but I was just curious as to how much "headroom" there might be.

Maybe with overclocking you can gain about 20% more.
But I found, with reviewing and changing the program flow you can gain many more, sometimes 1000%.

So overclocking was never an option for me, the advantages vs. disadvantages ratio was risible.
Until now, a second view on the software helps me many more. Typically it increases speed and decrease memory consumption simultaneously.

Peter

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

Quote:
I have heard, in the past, that one of the first things to be effected by over-clocking is EEPROM writes at temperature extremes.

As the AVR generations have evolved and max speeds have risen, current models time EEPROM writes separately:
Quote:
The calibrated Oscillator is used to time the EEPROM accesses.

Now, the EEPROM reads halt the processor for 4 cycles; perhaps that is not long enough when going at whoopeee speeds?

Remember that the datasheet numbers are at the extremes of temperature and voltage. I wouldn't expect a 20MHz part at room temperature and decent Vcc level to drop dead at 20.01 or 20.1 or 21. or even 24.

Didn't someone post a while back on this, and cranked up Vcc levels as well?

If we make the assumption that Atmel uses about the same flash in its microcontrollers, then I think there is an upper limit perhaps in the high 20s of MHz on the flash read. I'm basing this on the max on the SAM7 series which is like 30MHz IIRC without wait states. You might have to ISP at a slower rate, too--perhaps a good use for CKDIV8.

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

Carl: Does the serial work ok at 24.6mhz, or you dont use it in this app?

Imagecraft compiler user

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

There are a few semi-commercial products over-clocking at least the mega8 from 16 mz to 20. IIRC AVRcam for one. http://www.jrobot.net/Forums/vie...
Good thread thanks,
John

Resistance is futile…… You will be compiled!

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

If you are to adhere to the datasheet, you can't run 16MHz on a 16MHz avr. Take the M16: Minimum tclcl is 62.5 ns. Since the clock source will have jitter, say, 100ps, minimum oscillator period will be 62.7ns=15.95MHz. So with a 16MHz xtal we're violating that parameter 50% of the time.

The sweet spot for the 2002-dated M16 I played with was 4.3V; eeprom worked up to 30-some MHz, correct execution up to 48MHz heated, and 10-15MHz higher when cooled to about -35C. My clock source was an RF signal generator, and my interest was wether the one-off lab experiment could be expected to stay working at 18.414MHz long enough for me to get my data.

Perfect decoupling is good, and it should be QFP or smaller package when trying this; The identical parts in PDIP I tried were not cooperative.

The old pre-cmos 8051's didn't have this much margin either, 50% on a really good day, usually less. The 16MHz cmos types were worse, 20MHz and you shouldn't expect more.

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

Quote:
Since the clock source will have jitter, say, 100ps,

"Will"?!? Not >>my<< clock, sir. ;) Only Atmel's internal oscillators.

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

Here's a way to look at 100ps since some people don't have a feel for it (where did they grow up? Earth?):

At 16MHz, with a 2.5Vpk sine (5V full swing), the slew rate at center voltage crossing is 2*pi*16MHz*2.5V= 0.25V/ns.
Multiply by 100ps, and you get 25mV. That is noise required to get 100ps phase noise. Not very big is it? The newer AVRs with less oscillator swing are, by definition, worse.

theusch: In that case I want to beg some components off of you. The courier will be arriving by black helicopter shortly..

Edit: The latest improvement on my TIC circuit has yielded 10ps RMS resolution. One can see strange things at such resolution, like when I pull on the signal cable and it gets just slightly longer..

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

Your hand adds picofarads to the cable and the propagation velocity goes from .7c to .6c?

Imagecraft compiler user

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

Quote:
theusch: In that case I want to beg some components off of you. The courier will be arriving by black helicopter shortly..

Sure--they won't be as inexpensive as a crystal, though. ;)

[Like the 16MHz AVR is going to drop-dead at 16.05MHz. And note that the jitter needs to be on both "edges" as the duty cycle does not need to be near 50% if we are playing datasheet games. :lol: ]

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

I have run the 324p and 644p up to 30MHz with no problems at all during some ugly video test I was doing. For kicks, I left the 324p running at 28Mhz for several days, and there was no extra heat generated or glitches in the video.

I did not use the EEPROM, but did use the SRAM to almost 100% during these tests (read and writes).

I also did this with a clock module.

The 324p would not get to 40Mhz, although the code did seem to work properly at 32Mhz, but this was only a short test.

I wonder how far the XMegas can be pushed?

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

AtomicZombie wrote:
I have run the 324p and 644p up to 30MHz with no problems at all during some ugly video test I was doing. For kicks, I left the 324p running at 28Mhz for several days, and there was no extra heat generated or glitches in the video.

I did not use the EEPROM, but did use the SRAM to almost 100% during these tests (read and writes).

I also did this with a clock module.

The 324p would not get to 40Mhz, although the code did seem to work properly at 32Mhz, but this was only a short test.

I wonder how far the XMegas can be pushed?

Brad, you're going to give Lee nightmares, causing him to toss & turn all night, making him even grumpier then I am!

I can hear him now... "You young'ns always have to make things go so fast! Can't you just run things like us old fogies do - DEAD SLOW ?"

I also tried running the Mega644 at 30MHz, it wouldn't run correctly. But then too, I was using the STK500 as the hardware platform. The Mega644 did run correctly at 24.??? MHz in the STK500, including an HD44780 text based LCD. I haven't tried this with the STK600 yet, but I will.

So, maybe there is some limiting factor with the STK500 that prevented 30MHz operation. Or, you got lucky and got hold of a controller that will run at the high end of the "Illegal Specification ", and I got one in the mid-range.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:
Brad, you're going to give Lee nightmares, causing him to toss & turn all night, making him even grumpier then I am!

1) I'm >>already<< much grumpier than you are.
2) I'm all for cranking things up to whooppee--in the privacy of your own bedroom.

Even for Evil Geniuses (Genii?) there can be pitfalls. Even when Brad or Jesper or whomever posts an overclocked, well-tested, "hobbyist" project it may not be able to be reproduced with the next batch of the same AVR model.

Quote:
You young'ns always have to make things go so fast!

It is usually "You kids always have to go so fast right away. " That is in many threads where a relative newbie had a project lash-up and has the AVR clock speed as well as USART/SPI/ADC also cranked to the max. And never 'scopes the signals to look for ratty edges and noise and the like. Use a magic crystal frequency for the desired baud rate? Not.

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

theusch wrote:
Quote:
Brad, you're going to give Lee nightmares, causing him to toss & turn all night, making him even grumpier then I am!

1) I'm >>already<< much grumpier than you are.


I seem to get more complaints then you get... It must be because I'm a true Yankee, and you're just a "Cheese-head " from Wisconsin. :lol:

theusch wrote:
2) I'm all for cranking things up to whooppee--in the privacy of your own bedroom.

Maybe if I tell my wife that you approve, she'll be a little free'r with that "Whooppee !"

microcarl wrote:
You young'ns always have to make things go so fast!

theusch wrote:
It is usually "You kids always have to go so fast right away. " That is in many threads where a relative newbie had a project lash-up and has the AVR clock speed as well as USART/SPI/ADC also b]cranked [to the max[/b].

I'm usually pretty good about this. I'll usually go for the "High Side " once I've gotten the thing working fairly stable.

theusch wrote:
And never 'scopes the signals to look for ratty edges and noise and the like.

The first piece of test equipment that is turned on when powering up my bench is my Oscilloscope. It's just too damned convenient, not to use.

theusch wrote:
Use a magic crystal frequency for the desired baud rate? Not.

I think you know that using a magic crystal frequency is my preference as well - seeing as I have hopped on that rant on many occasion. That and the topic of over-clocking.

But that doesn't mean that I don't like to push the limit, just to see what rules I can get away with breaking.

I mean, who else do you know that would deliberately attempt to destroy an STK500, for the sole satisfaction of seeing what I can get away with... And I still use that same STK500, to this day.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

If you have your scope and it is a fancy scope, you just need to look at the STK500 onboard clock.

I would guess that this is your limiting factor. The manual says that it should be good to 20MHz. 30MHz is considerably higher.

David.

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

david.prentice wrote:
If you have your scope and it is a fancy scope, you just need to look at the STK500 onboard clock.

A little derogatory??? I guess that all depends exactly on what fancy means.

david.prentice wrote:
I would guess that this is your limiting factor. The manual says that it should be good to 20MHz. 30MHz is considerably higher.

Ah, but the AVR data-sheet also sets the upper frequency limit for the AVR too! But Brad was able to clock his AVR at this "Considerably Higher " frequency.

And, as my 30MHz testing was done on the STK500 that I beat the shit out of, perhaps the fact that this particular STK500 won't run at 30MHz is simply due to the fact that I actually did stress some component/s to the point of degrading them.

Or, maybe it's simply the fact that the components making up my STK500 are components from a lot that simply won't run at the "Extremes " and the components making up Brads STK500 (if he even tried the 30MHz test on an STK500) are from a lot that will run at these "Extremes ."

But to be sure, it's not really important enough for me to waste even one nanosecond on...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

STK500 clock limits??? Well, I guess I can see that. Plugging a leaded crystal into the socket doesn't make for the most realiable setup for one. And there is circuitry between the crystal and your AVR. What other limitations would an STK500 have? All it is is power supply(s) and sockets.

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

theusch wrote:
STK500 clock limits??? Well, I guess I can see that. Plugging a leaded crystal into the socket doesn't make for the most realiable setup for one. And there is circuitry between the crystal and your AVR. What other limitations would an STK500 have? All it is is power supply(s) and sockets.

I'm thinking that maybe the way the sockets are laid out. If there are a lot of stubs, they could be creating a lot of reflections which will severely degrade the CLK signal.

But as I said, I really don't care, as I usually run my STK500 at or below 20MHz.

And with the arrival of the STK600 and AVRJTAGice-MK2 on my bench, the STK500 will probably end up on the shelf, until I'm moved to give it to someone here on the AVRFreaks.net forum.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

If the problem is one of slew rate, I can recommend using some high-speed switches like the SN74LVC1G3157 or SN74LVC2G53 from TI. They can recondition a signal pretty nicely, with typical switching speed 0.5ns and 6 ohm on resistance... There are a lot of other switches out there that could do the job and will give you crystal clear edges on the output..

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

I only did the overclocking for kicks, and would never use it on a final project, even just a one-off for private use. Yes, overclocking is for clowns, and it hurts to be a clown. It is fun to punish them, though!

My video system is running at 20MHz, but when I was trying different sync schemes, the ability to reach over 30MHz was nice.

I only use the STK500 as an ISP. I always program the AVRs on my breadboard, and always use clock modules, never xtals.

I think the extra drive of the 5 volt clock oscillator is what allowed me to reach 30Mhz.

Next time I am really bored and feel like torturing another 324p, I will try this and report back....

Up the voltage to 6 or 8 volts, drop on a 40MHz clock module, and flash 32 LEDs during full read and writes to SRAM.

Each time, a checksum will be calculated and the program will continue until failure - if there is one.

I will put my money down that the 324P will run the program error free at 40MHz using 8-10 volts for 24 hours.

Maybe I will make a video of the test, and keep upping voltage and speed until the magic smoke is released. Oh, what fun!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

bobgardner wrote:
Carl: Does the serial work ok at 24.6mhz, or you dont use it in this app?

As a matter of fact, 115.2K BAUD worked just fine at the magic 24.??? frequency.

But it's been nearly a year now, since I played with this and I've forgotten a lot of the details.

Maybe one of the previous posters (Brad, maybe) is correct - crank VCC up to about 6 VDC and use an external clock, rather then an external crystal. Let the smoke bellow and observe the wonders of stressing technology beyond it's limits.

I've always like destructive testing, especially when there's smoke, a kaboom, and then kaput!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:
I've always like destructive testing, especially when there's smoke, a kaboom, and then kaput!

Carl: "The Original Dragon Slayer!", and part - time MythBuster! :D

JC

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

STK500:
When you test in an STK500, at least the dataflash-bearing version and no-datalash versions I have, you have already invalidated the test:
Put a scope on VCC to the AVR, set it to 2ms/div, trigger on 3V rising, and turn on the STK500 powerswitch. Due to appnote-engineering, VCC rises to 7V during power up. The LM317 responsible for VCC sources 5mA into an LM358, and when not yet powered, it will not sink. So from the very start one exceeds the absolute maximum ratings.

If you program your part in an STK500 behaving like the ones I have and then use it in a product, the part sitting in that product will have been beyond absolute maximum ratings, and may have suffered permanent, creeping damage.

AtomicZombie:
I must be a clown then:-). On some projects I find it so very useful to ramp VCC, clock, and temperature in and out of spec on the prototypes. It brings out evidence of margin problems, usually the result of 'we can fix the timing constraints later' followed by 'now it works, ship it', then followed some time later 'Now we have 30% yield and they are failing in the field'.

You will likely find that the optimum voltage for your part is below the absolute max ratings. Raising the voltage is not free, timing wise.

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

Just for your information, I have 2 projects running since 2 years 24h/24h with a Mega324 clock at 32Mhz, you just need a external full swing TTL output oscilator.

But don't do this for a comercial product...

Yours truly,
Sylvain Bissonnette
www.microsyl.com

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

Very inspired. Are you willing to share some source code and your schematic setup, Maybe a tutorial?

~William