Internal EEPROM value gets changed

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

I am using ATMEGA328pb with external oscillator of 11.0592 MHz (through hole 2 pin). Randomly sometimes. But maximum time we observed this change when the device get power off-on.

In fuse bits I have used BOD at 4.3 v. 

 

And when I used the system on internal oscillator 8 MHz. then this problem got solved.

What would be the reason of this issue? 

Thanks in advance   

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

imrana326 wrote:
I am using ATMEGA328pb with external oscillator of 11.0592 MHz (through hole 2 pin).
Crystal (external oscillators are typically 4 pin)

imrana326 wrote:
What would be the reason of this issue?
Internal 8MHz RC oscillator starts in 6 clocks whereas XTAL crystal oscillator starts in 16000 clocks.

 

"Dare to be naïve." - Buckminster Fuller

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

Are many EEPROM locations changed or just one? A common strategy has been to leave EEPROM location 0x00 blank. This is often done by assigning a variable to that location, then never use it.

 

Big question actually related to one of your other posts.

 

If you are using a crystal, do you have the required capacitors that go with the crystal? These are typically 12pf to 22pf. The precise value depends on the crystal, but 15pf is quite common.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Either Osc will work the EEPROM just fine...you are looking in the wrong place.

 

And when I used the system on internal oscillator 8 MHz. then this problem got solved

You are probably fooling yourself---this is not the issue.   Are you disabling interrupts during your EEPROM writes--that is required

When, exactly, are you normally doing EEPROM writing?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

ka7ehk wrote:

Are many EEPROM locations changed or just one? A common strategy has been to leave EEPROM location 0x00 blank. This is often done by assigning a variable to that location, then never use it.

 

Actually I have used the address 0x00 only. and I have not checked the other values of different addresses.

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

Post your fuse settings used with the xtal, please!

As noted above, xtals take some time to startup and be stable, the fuse settings used are critical.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

 

Either Osc will work the EEPROM just fine...you are looking in the wrong place.

 

And when I used the system on internal oscillator 8 MHz. then this problem got solved

You are probably fooling yourself---this is not the issue. 

avrcandies wrote:
 Are you disabling interrupts during your EEPROM writes--that is required

When, exactly, are you normally doing EEPROM writing?

 

No, I am not disabling the interrupts during EEPROM Write. But just after writing the value I never found this issue. 

But does it required to disable the interrupts while reading EEPROM  value?  

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

ki0bk wrote:

Post your fuse settings used with the xtal, please!

As noted above, xtals take some time to startup and be stable, the fuse settings used are critical.

 

Jim

 

 

Fuse settings

HFuse=0xDF

LFuse=0xDF

EFuse=0xF4

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

No, I am not disabling the interrupts during EEPROM Write

Did you not read the datasheet ?  You MUST disable IRQ's while doing any EEPROM write  

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.

 

Also, do not use location zero, use location 1 instead

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

ka7ehk wrote:
A common strategy has been to leave EEPROM location 0x00 blank.
Fourth and fifth paragraphs are on that issue :

Why are some addresses of the EEPROM corrupted (usually address zero)? | Frequently Asked Questions

 

"Dare to be naïve." - Buckminster Fuller

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

Use these settings:

 

Fuse settings

HFuse=0xDF

LFuse=0xFF

EFuse=0xFC

 

this provides a longer delay upon power up to let the xtal stabilize before proceeding,

and heed the advice  above about disabling interrupts before writing your eeprom value

A code example is provided in the DS for eeprom read/write

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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


First of all thanks for the valuable reply.

 

But in example where they have disabled the Interrupts. 

 

 

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

I think you need to focus on the clock source first.......

With that not running as it should everything is possible.

I think after you have your clock stable and running at the expected frequency you can look further down the line, but the clock is the source of it all running, so when that is not OK the rest can give random troubles.

 

Note that when you took there examples from the Atmel/Micorchip datasheet, they are always a guidance, not a 100% fail safe working solution. If the datasheet stated "disable interrupts" you need to do that it does not mean they will have added this part of the code in the example as it might actually confuse people. That is why you should always read the specific part of the datasheet and then when you cannot get things sorted yourself have a look at the given example code.....

 

but I state it again " Stop thinking about anything else until you have made sure your clock source is OK"

 

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

 

This is from one of the mega88 datasheets (the 48/88/168/328 family)...sometimes datasheet progress is one step backwards!!

 

The following example
shows how this can be used to avoid interrupts during the timed EEPROM write sequence.

char cSREG;
cSREG = SREG; /* store SREG value */
/* disable interrupts during timed sequence */
_CLI();
EECR |= (1<<EEMPE); /* start EEPROM write */
EECR |= (1<<EEPE);
SREG = cSREG; /* restore SREG value (I-bit) */

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Oct 15, 2019 - 07:02 AM