Safe Operating Area - Program Memory Corruption

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

In the datasheet for the XMEGA-A1U, it specifies a "Safe operating Area" in the figure maximum frequency vs Vcc.  This implies that a minimum voltage of 2.7V is required for a ClkCPU of 32MHz, or a maximum ClkCPU of 12MHz when operating at 1.6V.  What would the consequences be of operating outside the safe area?  e.g. operating from 1.8V with a ClkCPU of 16MHz.  I have tried this and it seems to work OK, but have seen some instances of program memory corruption.  Obviously it is not good practice to operate outside the Safe Operating Area, but would like to know if anyone else has experienced program memory corruption as a result of this, or anything else.

Thanks.  

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

For one off "home" projects you can push most silicon way beyond the design limits. I think AtomicZombie ran experiments where he ran Xmega (in theory 32MHz max) at 64MHz and on the whole it still worked. (though you may need additional code to watch out for things going wrong!).

 

But if this is a chip choice for a product design it would be commercial suicide to ever drive a chip beyond any of it's specified limits. You would spend your entire budget servicing warranty returns!!

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

garyqiq wrote:
I have tried this and it seems to work OK
??? This does not look ok to me:
garyqiq wrote:
but have seen some instances of program memory corruption
garyqiq wrote:
Obviously it is not good practice to operate outside the Safe Operating Area,
Exactly.
garyqiq wrote:
but would like to know if anyone else has experienced program memory corruption as a result of this,
Why? Is it just about criousity? Then go ahead, but it is not worth my time to deliberately build unreliable circuits. One of the things I'd expect to happen is that your whole uC stops working on a warm sunny day. There are soo manythings to build and fun things to do with uC's. Most people at least have the intention to build something with a bit of reliability...

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Feb 7, 2018 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note also that I think it might be things like EEPROM writes that start to fail first so some parts of the program may appear to be working but if an important EEPROM write is then corrupted the immediate damage may not be so immediately obvious.

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

Runnig out of spec. I really like this :

 

https://hackaday.com/2009/06/27/...

 

They power a tiny with a coil on two IO pins :)

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

Low voltage can result in memory corruption, as you have found. The faster you run, the higher the risk of memory corruption as voltage falls. So running out of spec means you take this risk of flash memory corruption.

 

You can do things to limit the chances of corruption happening, such as setting lock bits or the NVM flash write disable bit. A very stable power supply (lots of capacitance near the chip) really helps too. But even then, it's a risk.

 

Mind if I ask why you need to run at the lower voltage and higher frequency? Maybe there is a way around it.

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

since you can't use BOD use a reset chip, so it don't run under the needed voltage.

Don't use a bootloader! (so there no code that change the flash)