Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Strange problem in AVR !!

Status
Not open for further replies.
Hi, in our company they developed a large LED display that shows some words , when it works for 24 hours , it works fine but when they close the power supply , the EEPROM in the AVR realeses the words , and the avr needs to be reprogrammed again ... i wonder what could be the problem ?
 
Obviously a glitch is getting into the EEPROM and damaging the contents.
When the voltage gets low, the microcontroller starts to do funny things. Try a different microcontroller and if that fails, use a different type from a different manufacturer.

Another thing to do is keep the microcontroller powered up via a separate power supply and see if the microcontroller is at fault or if the glitch is coming from the external circuitry.
 
Last edited:
I suggest that you reread the datasheet. My Atmega128L processors have been doing fine for at least 18 months without an issue.
 
Are you constantly writing to the eeprom for some reason? If you're just reading from a table you shouldn't be able to damage the eeprom even with a sudden power outage. If you're in the middle of a write to eeprom though you'll corrupt an entire block when the power goes out if you don't stop eeprom writes before the power goes out. You didn't really supply enough information to trouble shoot the problem more than wilde guesses as that is not normal behavior something must be abnormal, so you'd need to post all your code and a schematic of the circuit it's in.
 
Is your program using address 0 of the eeprom? If it is, change your code to begin @0x0001 in the eeprom.

In some AVR devices, when the reset activates during a write to the
internal EEPROM, the EEPROM Address Register will be set to zero (0x000).
The result may be seen as corruption of both the location being written, and
of location zero (0x000).

During periods of low VCC, the EEPROM data can be corrupted because the
supply voltage is too low for the CPU and the EEPROM to operate properly.
These issues are the same as for board level systems using EEPROM, and the
same design solutions should be applied.

An EEPROM data corruption can be caused by two situations when the voltage
is too low. First, a regular write sequence to the EEPROM requires a minimum
voltage to operate correctly. Second, the CPU itself can execute
instructions incorrectly, if the supply voltage is too low.

EEPROM data corruption can easily be avoided by following this design
recommendation:

Keep the AVR RESET active (low) during periods of insufficient power supply
voltage. This can be done by enabling the internal Brown-out Detector (BOD).
If the detection level of the internal BOD does not match the needed
detection level, an external low VCC Reset Protection circuit can be used.
If a reset occurs while a write operation is in progress, the write
operation will be completed provided that the power supply voltage is
sufficient.

What all this means is: If you can't guarantee power, you have to make sure
that the part is kept in RESET when it is outside of spec. You can do this
using the internal BOD, but this will not take care of the case when an
EEPROM write has already began when the part loses power. Thus you must also
make sure to write to the EEPROM only when you're sure to have power.

It is not enough to write to the EEPROM during "safe periods" and leave the
BOD disabled, though: If the part gets outside spec it can begin executing
erratically, and the program counter could conceivably jump to the part in
the code in which the EEPROM is written.

These are not bugs but intrinsic demands of the EEPROM.

Interrupts are not disabled automatically, but the customer is urged to take
care of the following during EEPROM write (the order of steps 3 and 4 is not
essential):

1. Wait until EEWE becomes zero.
2. Wait until SPMEN in SPMCR becomes zero.
3. Write new EEPROM address to EEAR (optional).
4. Write new EEPROM data to EEDR (optional).
5. Write a logical one to the EEMWE bit while writing a zero to EEWE in
EECR.
6. Within four clock cycles after setting EEMWE, write a logical one to
EEWE.

Caution: An interrupt between step 5 and step 6 will make the write cycle
fail, since the EEPROM Master Write Enable will time-out. If an interrupt
routine accessing the EEPROM is interrupting another EEPROM access, the EEAR
or EEDR Register will be modified, causing the interrupted EEPROM access to
fail. It is recommended to have the Global Interrupt Flag cleared during all
the steps to avoid these problems.


Here are some other appnotes to read:
**broken link removed**
https://www.electro-tech-online.com/custompdfs/2009/03/doc1051.pdf

What i would do is program the code in the avr, and do not program lock bits. Run it in your circuit until the corruption happens. (power the circuit up & down many times until it happens, it will happen) Then read the eeprom to see exactly which location is being erased or corrupted. I'll be willing to bet its location 0x0000 in the eeprom, I have seen it many times before. It usually happens upon startup, while voltage is still climbing, or not at its peak.

I once wrote a small routine to read location 0x0000 in the eeprom (at startup), if it was 0x00, re-store the data to a default setting (just so the flash would not have to be re-programmed) This would allow the program to repair itself and proceed, whenever an error should occur.
 
Last edited:
Clearly JohnSmith123 knows how to read a datasheet. Would that the OP could learn to do the same.
 
Last not least you could store the data in an external EEPROM which is deselected upon power failure (VCC <= 4.5V). After power is restored it might be activated loading its data contents to the internal EEPROM before program execution.

To avoid unneccessary reloading you might add a plausibility check before doing that. (A simple multiplication check with the result zero will indicate that reloading is necessary.)

Boncuk
 
So, the first thing to do is turn the device off and see if the micro is corrupted.
Then separately power the micro to see if it is getting spikes, or if the micro is at fault.
Then you can determine what next to do.
 
You should put a thermocouple on the part and monitor temp with PS closed. Perhaps your exceeding the temp spec of the part.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top