--- In , "Alowonle, Musibau" <Musibau.Alowonle@t...> wrote: > Do I need to disable Interrupt while Erasing and Writing to the > EEPROM ???????? There are several reasons why it is wise to disable interrupts, if at all possible, when performing EEPROM writes. Having been 'burned' at least once by the way that the EEPROM works during a write cycle, I speak here as the voice of (unpleasant) experience. First, and most noticable, is that when a EEPROM write is in progress, the entire EEPROM array is effectively unavailable for read access to the rest of your application. If you have any active interrupt routines that attempt EEPROM reads during a write cycle, the value they will read out will be inaccurate (probably $FF or $00, but don't count on this). Given that I have created applications that (in some cases) simply cannot afford to have interrupts disabled for any significant period of time (10 mS is 'significant' for what I'm talking about here), I have gotten around the problem I mention above by 'shadowing' a part of the EEPROM (that contains variables used by interrupt routines) into a reserved block of RAM, and have created a set of abstract write routines that, when passed a address and a value to write, check the location that is to be written, and if said location falls within the RAM 'EEPROM shadow' window, or falls within the EEPROM address window that is being shadowed to RAM, will write the value to both the appropriate EEPROM and RAM locations. If the address falls within the non-shadowed EEPROM area, it just writes to the EEPROM, and if the address is in the non-shadowed RAM area, it writes to RAM only. By having my interrupt routines always read their critical parametric values from the RAM-shadow area, and using a intelligent memory management routine like I describe above, I can work around the first problem I describe above, and the second major problem (which I describe below) becomes a non-issue. The second major problem associated with EEPROM writing with active interrupts is more insidious, as the 'window of opportunity' for something to go wrong is very narrow. As you may recall (and as outlined on pages 4-11 and 4-12 of the Pink Book), programming a single EEPROM cell is a 5-step operation, consisting of: 1. Set PPROG.ELAT = 1 2. Write desired value to EEPROM address 3. Set PPROG.EEPGM = 1 (leaving ELAT=1) 4. Wait 10 mS 5. Set PPROG = $00 The 'window of vulnerability' where things can go wrong is if an interrupt (that performs a EEPROM read) occurs after step 2 but before step 3. During this time, the device is looking to latch any bus address that references the EEPROM; the last EEPROM address that is referenced before EEPGM=1 will be the address that is written to. Presumably, it is only supposed to be looking to latch WRITE operations, but I think that it will latch address (and corrupt data) from a read operation to EEPROM as well. If your EEPROM-using interrupt occurs within this narrow window, it is quite possible that the wrong information will be written to the wrong EEPROM address. Thus, at a minimum, you must ensure that steps 2 and 3 are done 'atomically'; that is, you should disable interrupts before step 2 and re-enable them after step 3 - or better yet, assuming you have the RAM space for it, utilize the RAM-shadowing technique I described previously. If you group the (relatively few) EEPROM parameters that are required for interrupt usage into a contiguous EEPROM block, and all other variables in a different block (that does not have to be shadowed in RAM), the amount of RAM you have to use to shadow the critical parameters should be fairly small. If interested, I can describe in greater detail as to how I typically manage RAM and EEPROM usage. If done correctly, the whole process can be well abstracted from the rest of the application, and the 'shared/shadowed' area can dynamically grow and shrink without code modification - appropriate use of (assembler) labels allows the management code to adapt to changes without overt programmer intervention in the management routines. |