AVRs beyond their specs: Experiments and tests - but not more than 16MHz

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

Hi,

 

I know that their are specs defining the "safe area" of the graph of clock speed versus Vcc and that

leaving that area behind me will not make me happier. ;)

 

But I am curious...

 

What I want to do:

I have an ATmega2560 based board with a 16MHz crystal and too less additional parts as I could

make a boost converter from it... :)

 

The board runs happily with 3.3V...a blink program at 16MHz...which is out of spec.

A blink program is not /that/ a heavy task for a MCU I think, so this may be a lucky coincedence.

 

What kind of program would most likely reveal any weakness of this setup?

Are there already some kind of "burn in" programs around (I dont want to "overclock" in the sense of clockspeed > 16MHz) ?

 

Thanks for any help in advance!

Cheers

mcc

 

 

 

 

 

 

 

 

 

This topic has a solution.
Last Edited: Wed. Sep 20, 2017 - 11:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The point is, outside the datasheet-specified working conditions, the behaviour is undefined.

 

In other words, anything could happen.

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

Hi awneil,

 

thanks a lot for your answer.

 

Ok, more specific:

I want to test, what this certain board will do with a certain program, which pushes the MCU at its limits.

"Blink" as mentioned is not that kind of program.

 

What program should I use instead?

 

Cheers

mcc

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

There's been many threads about "over-clocking" in the past. I think it's usually suggested that EEPROM may be the first thing to go wrong as you wind the clock up but look for posts by AtomicZombie where he has overclocked AVRs to get more VGA graphics resolution from them. I think he's taken them as far as X2 (so 16MHz devices at 32MHz and so on).

 

Obviously you can't do this for a commercial product but it's fine for a bit of one-off experimentation.

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

Hi clawson,

 

as mentioned earlier I dont want to "overclock" and I didn't searched for that keyword since it leads me to

threads about "overclocking" (increasing clock).

Its more an "undervoltage-ish" thing to experiment with.

 

My original question was:

I want to test, what this certain board will do with a certain program, which pushes the MCU at its limits.

"Blink" as mentioned is not that kind of program.

 

What program should I use instead?

 

Cheers

mcc

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mcc wrote:
I dont want to "overclock" 

Eh??

 

But you are overclocking!!

 

"overclocking" is, by definition, running at greater than the specified maximum clock frequency - which is exactly what you are doing:

 

mcc wrote:
with 3.3V...a blink program at 16MHz...which is out of spec.

 

EDIT

 

Last Edited: Wed. Sep 20, 2017 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mcc wrote:
I want to test, what this certain board will do with a certain program, which pushes the MCU at its limits. "Blink" as mentioned is not that kind of program.
Yes it is. The AVR uses no more power to execute any particular opcode. So :

int main(void) {
    while(1);
}

which will basically compile to:

here:
    rjmp here

will use the same amount of power to execute repeated rjmp's as anything else.

 

I suppose you might argue that "switching gates" in silicon takes power so that something like:

int main(void) {
    volatile uint32_t count;
    while(1) {
        count++;
    }
}

will do a repeated sequence of ADD and ADC opcodes (and the RJMP to loop) and the additional gate switching involved in fetching count, doing the ADDs then storing it *might* take a fraction more CPU power to achieve but I defy you to be able to actually measure that - the change will be almost infinitesimally small.

 

This is not like you Windows or Linux machine where real complex tasks cause all four or eight CPU cores to run at full steam - this is an 8 bit AVR with none of the sophistication of Cortex A or Intel 86 processors.

 

The AVR is very simple - it is always running "at full steam" fetching/executing opcodes, however trivial, even NOPs, or it is executing SLEEP and some/all clocks stop. There is no half way house.

Last Edited: Wed. Sep 20, 2017 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reducing the voltage and increasing the frequency basically have the same effect: due to internal capacitance and inductance, signals inside the CPU lose integrity. You can have an idea of what happens looking at some scope traces I posted on a different thread. See how the supposed square wave becomes crap at high frequency?

This will happen inside the device, causing timing errors, 0s and 1s being misinterpreted, etc.

 

Different parts of the device will be more or less vulnerable. For example, maybe SRAM will start giving errors before the CPU core. Who knows?

Normally, math intensive programs are used to test overclocked PCs, so maybe you can find some fractal calculator or pi calculator for AVR architecture?

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

I guess you could write some code that would test whether each instruction was working correctly. Basically a routine which uses as many opcodes as possible and that returns a value which can be tested for correctness. IIRC, Intel had something like that in the self-test diagnostics on their 8-bit development systems.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

More to the point, you'd want to test that each component is working properly; ie, not just the CPU instructions, but also RAM, Flash, EEPROM - and all the peripherals ...

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

clawson wrote:
will use the same amount of power to execute repeated rjmp's as anything else.

;)  Deja vu all over again.  A thread maybe a year or two ago explored whether/which AVR op codes are more "efficient".  I don't remember what the outcome was.

 

It would be interesting to know the purpose of the snipe hunt.  I have many scores of production AVR8 apps, and only a couple run faster than 8MHz.

 

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.

Last Edited: Wed. Sep 20, 2017 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mcc wrote:

as mentioned earlier I dont want to "overclock" and I didn't searched for that keyword since it leads me to

threads about "overclocking" (increasing clock).

Its more an "undervoltage-ish" thing to experiment with.

MCUs have a MHZ-Voltage curve, for any given temperature, so you are overclocking anytime you go ABOVE that curve.]

If the spec says 2.7V, you can get one gain by running 3,3V +/- 1 % or similar tighter spec, and also reduce the TempMax

 

mcc wrote:

My original question was:

I want to test, what this certain board will do with a certain program, which pushes the MCU at its limits.

"Blink" as mentioned is not that kind of program.

Blink is a very basic test, you might want to fill the Flash/RAM with a pattern, and checksum that, to confirm you can READ flash at the speeds you test for.

Next, peripherals may struggle at overclocking, but mostly the slowest part of a MCU is the flash.

 

IIRC the XMega's give am external clock Max of 125MHz provided you also respect the 32MHz Flash speed (ie you must select /4, or slower MCU clock )

I bench-tested an EFM8 MCU once with a 200MHz external clock, and /8 internal to keep the 25MHz flash spec - seemed to work fine, on what was a quick test.

 

Such out-of-zone tests can be useful to confirm design margins, even if you never intend to ship a product running there.

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

It would be interesting to know the purpose of the snipe hunt.

Yes.  But consider that lower VCC also means lower current.  If VCC can be lowered while keeping the CPU clock the same, then the result is lower W/MIPS.  For power-budget constrained applications which are also compute intensive, this measure may be an important factor.  However, AVR is not the ideal architecture for this purpose.  Better to look at something like Ambiq's 32-bit Apollo family, they claim 35μA/MHz @ 3.3V and 24 MHz, for about 116μW/MHz.

 

To compare, the 8-bit m2560 specs 17.5 mA @ 4.5V and 16 MHz, for 4,900μW/MHz, but that does not include the power consumed by the clock source.  The minima is 2.0 mA @ 1.8V and 4 MHz, for 900μA/MHz.  Even if you were to overclock  by a factor of 2, you're still looking at 450μA/MHz, and that's for an 8-bit CPU.  The Ambiq is a 32-bit ARM device, and their claimed 116μW/MHz includes the internal clock.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Sep 20, 2017 - 10:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The original post doesn't mention anything about energy efficiency.

 

One might suspect that that is not the key issue here, as a M2560 would be a very poor choice if the key function of the micro is simply to run a boost converter, as was the only part of this project that was specifically mentioned.

 

Perhaps there is a need for a lots-of-pins and big memory chip that just wasn't mentioned?

 

If I truly wanted a boost converter I'd look at the many chips specifically designed for this purpose.

And if I wanted to design my own I'd look carefully at the 6 and 8 pin Tiny micros.

 

And if I was really using a lots-of-pins and big memory micro, I suspect power savings on this part of the design isn't likely to be a major factor in the overall every usage review.

 

Lots more info needed...

 

JC

 

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

What kind of program would most likely reveal any weakness of this setup?

Aside from the corner cases of some peripherals (EEPROM, Flash Self-programming, crystal oscillator), you're more likely to see random results under variations in temperature or supply voltage, rather than with changes in software.  I think.

 

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

joeymorin wrote:
the 8-bit m2560 specs 17.5 mA @ 4.5V and 16 MHz, for 4,900μW/MHz,

Perhaps a bit unfair, picking a 20-year-old AVR8 model line.

 

If my clean sheet of paper has Mips/watt at the top of the page in large font letters, then indeed I might not pick an AVR8.  While 1/3 of that is still not near your example, that is what I'd expect of my AVR8 designs -- very good performance at a reasonable power draw.

 

So to drag out my car analogy again, I like my mid-sized SUV which has lots of capabilities with reasonable fuel usage.  Can you find a model with less fuel usage?  Certainly.

 

My attempted point earlier is that for most microcontroller apps I've tackled the AVR8 has plenty of horsepower without pushing the supplyV/clock speed curve.

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

joeymorin wrote:
For power-budget constrained applications which are also compute intensive, this measure may be an important factor.
An application can be compute-bound, memory-bound, and/or I/O-bound (all consume current)

W/MIPS is a measure though an alternate for compute is W/CoreMark.

joeymorin wrote:
However, AVR is not the ideal architecture for this purpose.
RF AVR aren't far behind (1.8V core megaAVR); IIRC, XMEGA is next.

joeymorin wrote:
Better to look at something like Ambiq's 32-bit Apollo family, ...
next is SAM L and maybe PIC32 MM and/or recent PIC32 MX (haven't browsed those datasheets)

 


EEMBC

EEMBC

About CoreMark®

http://www.eembc.org/coremark/about.php

...

CoreMark is capable of testing a processor’s basic pipeline structure, as well as the ability to test basic read/write operations, integer operations, and control operations.

...

http://www.microchip.com/design-centers/32-bit/sam-32-bit-mcus/sam-l-mcus

http://www.microchip.com/design-centers/32-bit/architecture/pic32mm-family

Microchip Technology Inc

Microchip

Press Release

Latest PIC32 Family Increases Performance While Reducing Power Consumption

PIC32MX1/2 XLP Family Expands eXtreme Low Power (XLP) Technology to 32-bit Products

Chandler, Arizona

June 19, 2017

https://www.microchip.com/pressreleasepage/latest-pic32-increases-performance-reduces-power

 

"Dare to be naïve." - Buckminster Fuller

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

There are megaAVR, tinyAVR 1-series, and XMEGA AVR application notes with source code for self-test of AVR in household appliances.

AVR tests (mega328PB, tiny817) :

  • CPU registers
  • SP
  • Status register
  • RAM
  • Flash
  • EEPROM
  • Watchdog
  • Interrupt
  • I/O registers
  • Clock
  • ADC

tinyAVR 1-series has CRC on NVM; XMEGA has CRC on all.

 

Microchip Technology Inc

Microchip

AN_7715

AVR998: Guide to IEC60730 Class B compliance with AVR Microcontrollers

12/10/2016

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591300

This application note describes the `Class B` software classification, refering to embedded firmware which is intended to prevent unsafe operation of controlled equipment and provides guidelines for compliance with the `Class B` classification ...

via http://www.microchip.com/wwwproducts/en/atmega328pb

Microchip Technology Inc

Microchip

AN_42008

AVR1610: Guide to IEC 60730 Class B Compliance with XMEGA

07/01/2012

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591027

via http://www.microchip.com/wwwproducts/en/atxmega32e5

The missing XMEGA IEC 60730 source code :

Atmel AVR1610: Guide to IEC 60730 Class B Compliance with XMEGA

Atmel AVR1610: Guide to IEC 60730 Class B Compliance with XMEGA

Atmel AVR1610: Guide to IEC 60730 Class B Compliance with XMEGA
(file size: 367KB, 25 pages, revision A, updated: 07/2012)

IEC 60730 is a safety standard for household appliances that addresses many aspects of both product design and operation. This standard is also referred to by other standards for safety-critical devices, for example, IEC 60335. System-wide compliance with this standard is necessary for an appliance to be certified as safe to operate. This application note is a guide to compliance with Annex H of the standard, which regards electronic controls.

via http://www.atmel.com/products/microcontrollers/avr/avr_xmega.aspx?tab=documents  (pull-down menu, Application Notes)

 

"Dare to be naïve." - Buckminster Fuller

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

The original post doesn't mention anything about energy efficiency.

Seems I've caused something of a diversion.  I was just speculating on other reasons why one might want to probe the edges of the spec.

 

I guess the OP is hoping to be able to use his m2560 as a boost converter?  Unless Doc and I have misunderstood...

 

Surely that's a terrible choice as a controller at the heart of a boost converter, so there must be something else to the story.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]