AtMega 162 EEPROM Corruption

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
AndyG
AndyG's picture
Level: Hangaround
Joined: Mon. Jul 28, 2003
Posts: 334 View posts
Location: Manchester, UK
#1
Posted by AndyG: Wed. Nov 9, 2005 - 11:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I have a product based on an AtMega 162 that has a number of configuration tables held in the internal EEPROM. Specifically this is a stepper motor controller for a fruit machine (one-armed bandit) which can spin up to 8 reels.

As the reels spin, the MCU has to keep reading from EEPROM to determine the number of milliseconds until the next change of stepper motor phase.

A single byte of the EEPROM is getting corrupted occasionally over a power cycle. Curiously, this byte is the byte that determines the standard period between phase changes for normally spinning reels. That means it is a single byte of EEPROM that is being read up to 8 times during a 16 millisecond period.

I know that the most likely cause of this is a software error and that we softies are all too keen to want to blame the hardware, but I have checked the code very carefully and cannot see any practical circumstances in which I could write to the EEPROM at all under these conditions.

Does this potential corruption ring any bells out there?

Thanks in advance,
Andy G

If we are not supposed to eat animals, why are they made out of meat?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
reynaert
reynaert's picture
Level: New Member
Joined: Wed. Nov 9, 2005
Posts: 4 View posts
Posted by reynaert: Wed. Nov 9, 2005 - 11:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've read somewhere that location 0 in the EEPROM has a tendency to get corrupted on power cycles or glitches or something like that. Anyway, if you're afraid that repeated reading is the cause, why not keep that byte in SRAM, or in a register ?

Top
AndyG
AndyG's picture
Level: Hangaround
Joined: Mon. Jul 28, 2003
Posts: 334 View posts
Location: Manchester, UK
Posted by AndyG: Wed. Nov 9, 2005 - 12:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, but I already knew about the location 0 problem and specifically ignore thast location.

Although you are right, I could keep THIS value in RAM, the problem is that I have tables held there and don't have enough RAM space to hold the tables. We do intend to re-spin the design to a bigger AVR, but that will take a little while.

My worry is that if this is a genuine hardware problem, then I will see the same effect with the other parts of the tables; it's just that this will happen less frequently.

Thanks for the suggestions, though.
A

If we are not supposed to eat animals, why are they made out of meat?

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 38918 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Nov 9, 2005 - 03:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the brown-out detector enabled? If not, re-run the tests with internal or external brown-out detector.

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.

Top
sutton
sutton's picture
Level: Posting Freak
Joined: Tue. Oct 30, 2001
Posts: 1848 View posts
Location: Manchester England
Posted by sutton: Wed. Nov 9, 2005 - 04:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try leaving the address reg for the eeprom at 0 after each operation.

Keep it simple it will not bite as hard

Top
AndyG
AndyG's picture
Level: Hangaround
Joined: Mon. Jul 28, 2003
Posts: 334 View posts
Location: Manchester, UK
Posted by AndyG: Sat. Nov 12, 2005 - 09:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I'll give that a try.

Sorry about the lighting response - I got distracted for a couple of days.

Andy

If we are not supposed to eat animals, why are they made out of meat?

Top