Random numbers appearing in EEPROM

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

Good afternoon clever people...

I have a problem storing and reading data from EEPROM with codevision.

This code is for a machine which feeds material thru and cuts. I store the number of pieces to cut, speed, cut length, and pieces already cut in EEPROM.

Trouble is, occasionally (1 time in 20, maybe?), at switch on, the pieces_done is incorrect - it is replaced with a random number!
The new random number stays for a number of restarts, until it randomly changes again, which maybe implies that it is being written wrong, rather than read wrong?

Interesting point: It's only ever the pieces_done. The other stored parameters never have an error.

Code attached to show my sequence - init with 0 at programming time.

Read from EEPROM at startup, store in variable pieces_done.
variable pieces_done changes during the job, then when the stop button is pressed, it completes the cut, then stores pieces_done into e_pieces_done.
Sound reasonable?


eeprom int e_pieces_done = 0;


void main(void)
{
    setup();

//-- Load stored values from eeprom  
    pieces_done = e_pieces_done;

} //end main


void running(void)
{
  if (stop_pressed == 1)   //stop was pressed, so we should stop the job now
   {
     pieces_done = pieces + 1;          //why +1? cos the first piece been cut!         
     e_pieces_done = pieces_done;       //write to eeprom, in case they switch off 
     mode = WAITING;
     stop_pressed = 0;                  //reset the stop pressed flag
     break;
    }

}// end running

Things I have tried:
When Stop pressed - Writing to eeprom, then delay 5ms, then write again.
At startup - Read, delay, Read again.

None of these were a miracle cure.

Does anyone have any ideas?
Am I missing something obvious?

Thanks!
Pete

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

Which chip?

IIRC some of the early ones had a problem where they would randomly corrupt the first EEPROM location.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

It would appear that the variable is probably held at EEPROM location 0 - often a "problem" location.

Also how are you using BOD?

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

Hi

Thanks for your quick responses!

It's an ATMEGA64.

BOD? If you mean Brownout Detection, its set to the defaults of AVR studio - 2.7v, but not enabled.

How would I tell the system not to use EEPROM location 0?

Thanks
Pete

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

New information - after many switch on/offs, I can see that other stored info is changing too. :-(

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

Quote:

How would I tell the system not to use EEPROM location 0?

C compilers (or their linkers) *may* place variables in the order they are encountered in the source code so:

eeprom char unused_dummy_at_location_0;
eeprom int e_pieces_done = 0; 

could work. But if you only have one EEPROM variable across an entire program there's an almost certainty that the compiler/linker will locate it at 0 so possibly a better strategy is:

eeprom struct { 
  char unused_dummy_at_location_0;
  eeprom int e_pieces_done;
} eevars = {
 0x00,
 0x0000 
}; 

Which means the order of the variables is under your complete control. All that you maybe cannot control is that "eevars" is placed at 0 - but your compiler may have a mechanism to specify that too?

Quote:
New information - after many switch on/offs, I can see that other stored info is changing too.

Now enable BOD (at the correct level for Vcc) and retry that test ;-)

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

petenz123 wrote:
Hi
2.7v, but not enabled.

Have a read of the datasheet for the section "Preventing EEPROM Corruption" and then try turning on BOD.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

clawson wrote:

Now enable BOD (at the correct level for Vcc) and retry that test ;-)

Well well well!

I enabled BOD at 4v.
I am up to about 40 off/on cycles so far, with no apparent dramas!

Thank you so much!

:-)

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

Brian Fairchild wrote:
petenz123 wrote:
Hi
2.7v, but not enabled.

Have a read of the datasheet for the section "Preventing EEPROM Corruption" and then try turning on BOD.

Wow, thanks for pointing me there!

I usually only read the data sheet to find the pinouts, maybe I need to make it my first resource in times of despair!

Quote:
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. Secondly, the CPU itself can execute instructions incorrectly, if the
supply voltage is too low.

My guess would be that the second situation was occurring as there should be no EEPROM writing happening at power up or down.

Thanks heaps!
Pete