Possible causes to erase data in microcontroller EPROM?

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

Hi guys,

This problem is very concerned by me and my company's customer. They claimed that my company do some mistake about all the data in a few microcontrollers were clean out to 00, all addresses.

My product is a transciever, laser. 2.5Gbs data transfer rate.

Is there any chance from ESD issue?

Or there are something else can accidentally wipe out the EPROM memory.

Best Regards,
Komgrit S.

"Chill out with Atmel Corp."
- Scud88.

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

Do you disable interrupts when you read and write the eeprom?

Imagecraft compiler user

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

I'm not sure

it's mass manufacturing products. We use customer's design evaluation board to talk and read and write to the modules. And all of them have not had this problem before until now, i believe. And it used serial programming firmware.

So what if the interrupts was disable when reading or writing from the module? Could this be the cause.

"Chill out with Atmel Corp."
- Scud88.

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

Do you have a working brownout detection on your board? Very often corrupted EEPROM is caused by a controller misbehaving at voltages below it's specified minimum voltage. Almost anything may hapen in this case.

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

Can you trace all units that have exhibited this problem to a batch or a cut off date at which the problem started? If so have a look at an older and newer board to play spot the differance.
As well as a physical check have a look at the setup flags and power up reset time out. If there is an external undervoltage detection test it. In fact ramp the voltage up and down to make sure things to as expected.

Keep it simple it will not bite as hard

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

So this is your companies product, go ask the guy that wrote the program to look and see if the interrupts are shut off while reading and writing eeprom. And all the other suggestions seem good to me also.

Imagecraft compiler user

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

I don't think he's necessarily talking about EEPROM corruption.

Quote:
And it used serial programming firmware.

Sounds to me like he means code memory. Scud88, can you clarify for us?

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

Acually, I have experienced something similar (if it is the flash memory we're talking about..).

I did some experementing with the 2313 a while back and didn't bother to use pullup on the reset pin, just a wire manually connected either to VCC or GND. Sometimes it worked fine but after resetting a couple of times it stopped working, a read of the chip showed that it was totaly blank! reprogramming helped but it was erased again after a while. A pullup resistor solved the problem.

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

bobgardner wrote:
So this is your companies product, go ask the guy that wrote the program to look and see if the interrupts are shut off while reading and writing eeprom. And all the other suggestions seem good to me also.

Thanks,

I would ask him if he were at the company longer. it's too late. But this thing just happened once, first time, and according to many production everyday with thousands of modules shipped to our customer. I think the programming software is working well.

"Chill out with Atmel Corp."
- Scud88.

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

peret wrote:
I don't think he's necessarily talking about EEPROM corruption.
Quote:
And it used serial programming firmware.

Sounds to me like he means code memory. Scud88, can you clarify for us?

I am sorry for my bad telling story skill.

Here I try one more time.

Our product is laser transiever, telecommunication. And it need to program its firmware to EEPROM before testing and shipping to customer. This EEPROM is in-chipped memory.

We were doing thing alright until now, I recieve a feed back from our customer telling that a few modules doesn't have any thing in the EPROM, they claimed everything is blank, 00 in all addresses. This data comes from testing process to set up the working environment compensation values for laser transmitter and reciever. They are temperature, current, voltage and other stuffs.

It never happened before.

what I think right now it could be the cause is low voltage while programming or testing steps.

"Chill out with Atmel Corp."
- Scud88.

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

CountZero, all that I can think of is that the RESET pin was momentarily pulled very high (to initiate the parallel programming or similar) and that wiped the chip. Since I got a few chips hanging around, I could do some tests in my free time, I suppose. Thoughts?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

If these are calibration values in EEPROM and not firmware in Flash, it is likely that this is the problem refered to in https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=27157
To avoid this problem,
1) avoid EEPROM location zero,
2) disable interrupts during EEPROM accesses and
3) set the EEPROM pointers back to zero after each use (read and write).
However, if you don't have access to the firmware source, you'll have to disassemble the hex file to find out what they did.
C.H.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

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

abcminiuser wrote:
CountZero, all that I can think of is that the RESET pin was momentarily pulled very high (to initiate the parallel programming or similar) and that wiped the chip. Since I got a few chips hanging around, I could do some tests in my free time, I suppose. Thoughts?

- Dean :twisted:

Hi!

That is what I thought of too, touching a scope probe usually showes a lot of 50Hz(among others..) noise and if the pin has a high enough impedance this might be enough to trigger programing mode.

This was just my first attempts of AVR programming with some LEDs blinking and such on a breadboard and a pullup solved the problem, so thanks for your offer but for me it's not essential to dig further. I have moved on to a STK500 for prototyping and I no longer use antennas( ie short wires ) without pullups for inputs.

/Daniel

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

Nice. I've recieved a kudos STK500 and some sample chips a few weeks ago from ATMEL and i've been looking for some ideas for an interesting project. It's annoying really, to have all the hardware yet none of the ideas. I think i'll go poke around the Conell site.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

CountZero wrote:
I did some experementing with the 2313 a while back and didn't bother to use pullup on the reset pin, just a wire manually connected either to VCC or GND. . . . A pullup resistor solved the problem.

The ATtiny2313 specification indicates that RESET/ has is a pullup resistor Rrst (30K, min and 60K, max). I just measured the pullup on an ATmega128 to be 43.3K (right in the middle of the spec). It seems that a pullup on RESET/ is not necessary.

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

Quote:

It seems that a pullup on RESET/ is not necessary.

It is up to you. For "real" production designs, 40k and no cap is a recipe for disaster under real-world conditions.

Do yourself a favor and use 10k or 4k7 pull-up plus .1uF cap, and use brown-out detection either internal or external.

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.