Can Flash memory erase itself

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

I had made a elecricity control box and sold a few. The code uses AD converter directly coupled to mains line, using 470K as limiting resistance. Mega8535 chip. A few variable are stored in EEPROM for field changing.
I used CVAVR to code the chip and programed the fuse bits for no boot,no read memory etc.
Each system uses 3 (1 for each Phase)- the system is on main 24/7 except for power faileres. One day (about 4 month from deployment) one of the box was not working. I cheaked the circuit seemed to be fine so i reprogramed it - the whole thing was fully functional again. I have never had a problem like this before can you please guide.

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

Shame you didn't read before write then you could have compared and absolutely verified if the code image was damaged and perhaps more importantly, how?

If you have SPM instructions in the chip (i.e. a bootloader) then if code runs rogue it could hit this and self program.

If you don't have BOD set there are reports of flash having been damaged (though more usually EEPROM)

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

Brown out was enabled, not using bootloader in any way. and it was Flash which got erased. Actually I was not expecting it to work so just programed, sorry did not read. -just i was not using watchdog either

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

Without BOD enabled, the parts are sensitive to glitches on VDD. Said can cause all sorts of deviations from normal operation, including partial or complete erasure of FLASH. :-(

"It's easier to ask forgiveness than it is to get permission" - Admiral "Amazing" Grace Hopper.

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

I don't think that I've seen flash memory erase itself, as with most NAND flash memory implementations, the flash memory control state machine is required to erase it (and 'erased' means all 1's (0xFF). I HAVE certainly seen rogue code manage to change 1s to 0s, as it is often possible to make a "1" into a "0" with a write instruction, but cannot make a "0" into a "1" without other flash controller sequences involved.

While the flash isn't "erased", the values have certainly been changed, so the end result is still bad.

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

I'd guess that the EEPROM contents got corrupted which made the program in flash appear to fail. Do you checksum/CRC the EEPROM's contents?

You said the A/D is directly coupled to the AC mains wire. Is the ground for this thing tied to an AC neutral or what? And what do you do to keep big voltage spikes out of the AVR?

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

Mains neutral is tied to 1.25V so +- 300V X 2^.5 appears as +-1.25 V hence I can callculate true RMS of input voltage. Only 470K + small resistance do the trick. Have been using same in another project using mega48V, for 1 year, only not using EEPROM in that, never had a problem there.
The fact that mega48V is 5V tolrent and works till 1.5V and AD internal reff is 1V and that project does not use EEPROM - just one of this has something to do.
* if my Chip was fried due to high voltage I would understand but this was odd.
* EEPROM contents contain Desired voltage, system responce time etc. There values 0 to FF does not chage behavier and certainly not flash erase.

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

I worked at a job where we used a battery-backed Mostek RAM to hold data. The device was in a subway, and every now and again the saved "money collected" value would get screwed. My fix was to keep three copies of the data, and to periodically ensure all three were the same. If one value was different from the other two, it got set to agree with them. If all three were different this caused the machine to stop operating. (It was a token-selling machine, and clerks were also in the area to sell tokens 'normally.')

Looking back, we probably should have protected the data and power lines, but being fresh out of tech school, I trusted the engineer in charge.

Also, the three locations were not "multiples" of each other: that is, addresses like $8000, $9000, and $A000 were not used. It would be more like $8000, $90B1, and $A364.

--Rich

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

The ATmega parts are susceptible to FLASH erasure if the VDD is allowed to raise or fall slowly, BOD is not engaged and an external reset circuit is not provided. I have seen it repeatedly. Some environments are worse than others for this - I presume because of noise and or power supply ramp rates.

A similar, known issue for Atmel, is a high voltage present on RESET when powering up activating the erase process as part of an incorrent entry into HV programming mode. You are supposed to wiggle pins to get this to happen, but there is a problem with the design.

At any rate, use the BOD or provide an external supervisory chip. Or both. It certainly is cheaper than fielding a service problem.

"It's easier to ask forgiveness than it is to get permission" - Admiral "Amazing" Grace Hopper.

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

Thanks Microsuffer, its a great leed. I have changed BOD from 2.7 to 4V as I was using 16MHz device accedently (not L 8MHz).
I have also put a RC on Reset, May be i can use a zener protection too.
I am also using a zero crossover with clipping & clamping diode, may be there is a sudden jerk of voltage which can bring reset to high voltgae. Increasing the value of limiting resistance may also help.
But i do not understand externalchip solutions can anyone guide.
But again since more than 100 boxes are ready, till date little failer rate yet, I think the above said should solve.
Thanks for all replies.

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

gosain_sanjay wrote:
The code uses AD converter directly coupled to mains line, using 470K as limiting resistance.

If the 470k was the only protection against 230V, I fear it was fully insufficient.
Any resistor has a stray capacitance, which may feed noise directly from mains line into the micro and influence or damage it.

Please watch, spikes of 2000V are not uncommon on the mains line.
Also typical SMD resistors are only 200V proved.
There are nice protection resistors from Vishay (3000V).

I would suggest an 1M/3000V resistor to mains, then 5V-Zener to GND with 10nF in parallel and a further 100k in series to the ADC input.

Peter

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

gosain_sanjay wrote:
programed the fuse bits for no boot,no read memory etc.

clawson wrote:
Shame you didn't read before write

With the lock bits programmed, how would you read the contents of the AVR before reprogramming?

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

Microsuffer wrote:
A similar, known issue for Atmel, is a high voltage present on RESET when powering up activating the erase process as part of an incorrent entry into HV programming mode. You are supposed to wiggle pins to get this to happen, but there is a problem with the design.

Will the reccomended diode in AVR042 from /RESET to VCC not prevent this from happening?
AVR042: AVR Hardware Design Considerations http://www.atmel.com/dyn/resourc...
When VCC is discharged, the cap at the reset pin will also be discharged through the diode. Of course the /RESET pin can still be a diode foraward voltage above the VCC pin, but this isn't enough to enter high voltage programming is it?

Reset circuit as rccomended by Atmel in AVR042:

gosain_sanjay wrote:
I have also put a RC on Reset, May be i can use a zener protection too.

Have you also added a diode from /RESET to VCC as reccomended in AVR042? Otherwise you might accidentally enter high voltage programming mode as described above.
What vaues did you use for R and C?

gosain_sanjay wrote:
Thanks Microsuffer, its a great leed. I have changed BOD from 2.7 to 4V as I was using 16MHz device accedently (not L 8MHz).

What voltage do you run the AVR at?
nd at what frequency? Do you use the internal oscillator or an external xtal/resonator?

Can you post a schematic of the power supply for your AVR?