|
Hello all, ??????????? Do I need to disable Interrupt while Erasing and Writing to the EEPROM ???????? Read on if you want to know why this question is being asked. I have a problem that I believe is caused by EEPROM (inside the micro, 68HC11K4) corruption. I believe this because when I uploaded the data placed in the EEROM from the corrupted micro, I was able to see values (0xFF) in memory location which I wrote to. The 0xFF value is NOT part of the values that I write to this memory location. First of all, this corruption occurs randomly. It can not be repeated/recreated at will. Sometimes it takes days to be able to recreate the corruption. When a corruption is present, I'm able to recognize it through a partly garbled message on my LCD and the system lock-up. In trying to investigate the source of this problem, I swapped the corrupted micro into a known working board in the hope that the known working will exhibit the same failure, but this was not the case. Looking through my code, I see that when I Erase/Write to the EEPROM, I'm not disabling interrupt. I read in the HC11 manual that if while writing to the EEPROM, if any part of the main program or an interrupt routine tries to access the EEPROM during this write time, the access will fail. Due to the statement and the erratic behavior that I'm seeing is what made me ask the above question. Regards, Musibau |
|
|
EEPROM corruption
Started by ●March 12, 2004
Reply by ●March 13, 20042004-03-13
|
On Sat, 2004-03-13 at 08:27, Alowonle, Musibau wrote: > Do I need to disable Interrupt while Erasing and Writing to the > EEPROM The rule is that you must not attempt to run code from the EEPROM itself whilst writing to it - because the opcodes read will be garbage (null), causing random code execution - i.e., a crash. So, are you running any part of any interrupt routine from code in the EEPROM itself? Another possibility of which I cannot vouch for the full details - I haven't read the documentation fully or recently - is that an interrupt may occur during the "arming" sequence for EEPROM write, and cause the write to fail. How do these two possibilities reconcile with what you are trying to do? Obviously, you should disable interrupts whilst writing the EEPROM, just for safety, but you then have to consider the consequence of the "latency" of your interrupts being as long as the EEPROM write cycle. Your call! > In trying to investigate the source of this problem, I swapped the corrupted > micro into a known working board in the hope that the known working will > exhibit the same failure, but this was not the case. I'm not sure that is entirely clear ... -- Cheers, Paul B. "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." - Unknown |
Reply by ●March 15, 20042004-03-15
|
Another frequent cause for EEPROM corruption is failure to provide a
reset at power down. It has been pointed out before on this forum that the 68HC11 Reference Manual states that a low-voltage reset chip of some kind is virtually a necessity for a 68HC11 that uses the internal EEPROM. Many users-undersigned included-have learned the truth of this recommendation through bitter experience. Does your data loss occur after the power is shut down, then turned on again? Best regards, Kerry Berland Silicon Engines 2101 Oxford Road 847-803-6860 Fax 847-803-6870 Des Plaines, IL 60018 USA -----Original Message----- From: Alowonle, Musibau [mailto:] Sent: Friday, March 12, 2004 3:27 PM To: m68HC11 (E-mail) Subject: [m68HC11] EEPROM corruption Hello all, ??????????? Do I need to disable Interrupt while Erasing and Writing to the EEPROM ???????? Read on if you want to know why this question is being asked. I have a problem that I believe is caused by EEPROM (inside the micro, 68HC11K4) corruption. I believe this because when I uploaded the data placed in the EEROM from the corrupted micro, I was able to see values (0xFF) in memory location which I wrote to. The 0xFF value is NOT part of the values that I write to this memory location. First of all, this corruption occurs randomly. It can not be repeated/recreated at will. Sometimes it takes days to be able to recreate the corruption. When a corruption is present, I'm able to recognize it through a partly garbled message on my LCD and the system lock-up. In trying to investigate the source of this problem, I swapped the corrupted micro into a known working board in the hope that the known working will exhibit the same failure, but this was not the case. Looking through my code, I see that when I Erase/Write to the EEPROM, I'm not disabling interrupt. I read in the HC11 manual that if while writing to the EEPROM, if any part of the main program or an interrupt routine tries to access the EEPROM during this write time, the access will fail. Due to the statement and the erratic behavior that I'm seeing is what made me ask the above question. Regards, Musibau _____ > Service. |
Reply by ●March 15, 20042004-03-15
|
--- 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. |
