EEPROM variable : modified by app & read by ISR

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

Hi,
I have an eeprom variable that may be changed in my application and it also (may be) read (only READ not written) by an interrupt.
Question is: do I have to take any precautions in order to be on the safe side?
TIA.

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

I'd disable interrupts while it was being written if I were you as it's going to face the same atomicity issues as any variable or resource shared by main() and ISR(). There are some good articles about atomicity in the tutorial forum.

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

Thanks for advice!
I suppose it makes no difference if that variable is stored in eeprom or ram...

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

Yeah it'd be the same issues if the two codes were accessing PORTB (say). Any "shared resource" needs access protection (unless you can be sure the access is atomic).

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

clawson wrote:
Yeah it'd be the same issues if the two codes were accessing PORTB (say). Any "shared resource" needs access protection (unless you can be sure the access is atomic).

Well, in my code the variable is u8 (unsigned char), but it is stored in eeprom, so... I guess it's not an "atomic access", am I right?

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

That kind of depends on the EEPROM access code. If the ISR is only reading so it cannot "mess up" a write that main() is doing if it happens to interrupt then I guess you probably don't need to worry in fact but I would study the generated asm and look for any potential issues, when looking at the main() code consider what might occur if the interrupt happened between any of the instructions in the write sequence. Is there, for example, a moment where the byte might actually hold 0xFF after being erased but before being rewritten?

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

I'm using CodeVision. To be honest, i rarely peep into generated asm code...
Yet, I guess it is possible to have a 0xFF there. I'll investigate...
Anyway, I think I'll write a safeSetVariableU8(...) function just to be safe :)

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

scuberula wrote:
I'm using CodeVision. To be honest, i rarely peep into generated asm code...
I'm sure you'll find, if you look at the generated ASM (I just have, from curiosity), that CV correctly disables interrupts around EEPROM reading and writing in its low level EEPROM handling routines (and it deals with the watchdog as well)

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

MartinM57 wrote:
I'm sure you'll find, if you look at the generated ASM (I just have, from curiosity), that CV correctly disables interrupts around EEPROM reading and writing in its low level EEPROM handling routines (and it deals with the watchdog as well)

Martin, das ist richtig; i found something like this in the asm file:

                 __EEPROMWRB1:
002057 b79f      	IN   R25,SREG
002058 94f8      	CLI
...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it just one single variable that you read in ISR? In that case I would rather maintain a "shadow" copy of that variable in RAM and do not do any EEPROM from ISR. Otherwise, if interrupt occurs right after the main issued a write, the ISR read will be delayed until the write is complete, i.e., up to a few milliseconds.

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

ezharkov wrote:
Is it just one single variable that you read in ISR? In that case I would rather maintain a "shadow" copy of that variable in RAM and do not do any EEPROM from ISR. Otherwise, if interrupt occurs right after the main issued a write, the ISR read will be delayed until the write is complete, i.e., up to a few milliseconds.

ezharkov, I think you have ESP, you read my mind; I already did that few min ago, as now I need to store more vars in eeprom (structure in eeprom).
Hmmm... now I think I should also add some checksum for this eeprom structure.
:arrow:
On the other hand, if I modify the shadow-var (the one in ram), then I must update the eeprom too, am I right?
So, I cant really get rid of the delay you mentioned before... or am I missing smthing here... :?:

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

I do not do EEPROM access in my ISRs of AVR apps. Why? [nearly] All apps have EEPROM write sequences as well, for parameter update and other purposes.

Now, let's say your ISR fires while an EEPROM write is being carried out. That means you might be sitting in that ISR for several milliseconds to wait for the write to complete before the EEPROM read operation can be done.

So, indeed, I'd vote for the shadow copy.

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.

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

There are no special demands for speed for the application. There is nothing like "time critical" or "real-time" etc.
Yet, it is probably a good practice not to reel eprom vars (now that I have more than 10 members in the eeprom struct + CRC) along the whole code...
So, now that I'm kinda forced to do RAM shadow-copy, I can only hope that I won't have too much problems with the eeprom itself, as I read a lot of scary remarks from fellow freaks having problems with AVR eeproms...
True or just malicious rumors...?
EDIT:
I did enable the BOD & setup bod-level accordingly, I avoided eprom location 0 (necessary?)... what other precautions should I take in order to avoid eeprom corruption? (except those mentioned in datasheet)