|
I understand that in order to program any word or byte into EEPROM, the sector in which it resides must first be erased. But is it true that the erase and program process takes a full 20ms?? And that during this time, no other access can be made to EEPROM... even reading from another sector? From the 9S12DP256 Device Guide, Erase Time for an EEPROM Sector is: t = 4000 / f.nvmop where f.nvmop = 200 kHz Maximum Certainly this must have affected other people... I have lots of fast- loops with real deadlines and simply cannot place everything inside timer interrupts. So now I'm considering writing an EEPROM driver which will buffer any data to be written to EEPROM and control both read and write accessibility... Anyone else have a simpler idea? Have I missed something? The EEPROM routine provided in the reference design actually stalls for 20ms while it waits for the commands to complete. I've managed to pipeline the Sector Modify and Program Word commands and get out of the routine in about 4us... but any read access to EEPROM within the 20ms produces invalid results. Open to any ideas or interested to hear how others have handled this.. N. Skura |
|
|
EEPROM Read and Write Access
Started by ●March 31, 2004
Reply by ●March 31, 20042004-03-31
|
Are you using eeprom for code or data? Is there flash rom on the board also?
Or move a relocatable 'burn a byte' function from rom to ram, jump up into ram to burn a byte, return to flash |
|
|
Reply by ●March 31, 20042004-03-31
|
The 9S12DP256 features: 12 kB RAM 4 kB Flash EEPROM 256 kB Flash ROM I am using the EEPROM for data storage... Used to save user- configurable variables [ie: thresholds and settings] and also to log alarm or fault event data. All code executes from the 256kB flash ROM, so its just a matter of having the EEPROM available for reading and writing whenever I like, as opposed to having to schedule things around this 20ms program/erase cycle. N. Skura --- In , BobGardner@a... wrote: > Are you using eeprom for code or data? Is there flash rom on the board also? > Or move a relocatable 'burn a byte' function from rom to ram, jump up into > ram to burn a byte, return to flash > |
Reply by ●April 2, 20042004-04-02
|
I use a ram image of the contents of the EEPROM and periodicly check for differences. If there are differences then launch the erase/program command using a state maching , just make sure you don't check for differences faster than 100ms or so. I use 1 sec. Any writes or reads from appllication come from the RAM image and eventually get in the NVM. Kevin -----Original Message----- From: nealskura [mailto:] Sent: Wednesday, March 31, 2004 5:14 PM To: Subject: [68HC12] EEPROM Read and Write Access I understand that in order to program any word or byte into EEPROM, the sector in which it resides must first be erased. But is it true that the erase and program process takes a full 20ms?? And that during this time, no other access can be made to EEPROM... even reading from another sector? From the 9S12DP256 Device Guide, Erase Time for an EEPROM Sector is: t = 4000 / f.nvmop where f.nvmop = 200 kHz Maximum Certainly this must have affected other people... I have lots of fast- loops with real deadlines and simply cannot place everything inside timer interrupts. So now I'm considering writing an EEPROM driver which will buffer any data to be written to EEPROM and control both read and write accessibility... Anyone else have a simpler idea? Have I missed something? The EEPROM routine provided in the reference design actually stalls for 20ms while it waits for the commands to complete. I've managed to pipeline the Sector Modify and Program Word commands and get out of the routine in about 4us... but any read access to EEPROM within the 20ms produces invalid results. Open to any ideas or interested to hear how others have handled this.. N. Skura --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu <http://rd.yahoo.com/SIGca8qu6k/M&7637.4673018.5833253.1261774/D=eg roupweb/S06554205:HM/EXP80857719/A45637/R=0/SIGtfh3gpg/*http ://www.netflix.com/Default?mqso`178397&partidF73018> click here <http://us.adserver.yahoo.com/l?M&7637.4673018.5833253.1261774/D=egrou pweb/S=:HM/A45637/randG2545690 _____ > . |
|
|
Reply by ●April 5, 20042004-04-05
|
If you can get away with it, why not write to EEPROM before shutting down? That way, on startup you load your eeprom values to RAM and prior to shutdown you copy the contents of RAM over to EEPROM, so the EEPROM delay never comes into play during operation. John -----Original Message----- From: Longworth, Kevin [mailto:] Sent: Friday, April 02, 2004 4:41 PM To: Subject: RE: [68HC12] EEPROM Read and Write Access I use a ram image of the contents of the EEPROM and periodicly check for differences. If there are differences then launch the erase/program command using a state maching , just make sure you don't check for differences faster than 100ms or so. I use 1 sec. Any writes or reads from appllication come from the RAM image and eventually get in the NVM. Kevin -----Original Message----- From: nealskura [mailto:] Sent: Wednesday, March 31, 2004 5:14 PM To: Subject: [68HC12] EEPROM Read and Write Access I understand that in order to program any word or byte into EEPROM, the sector in which it resides must first be erased. But is it true that the erase and program process takes a full 20ms?? And that during this time, no other access can be made to EEPROM... even reading from another sector? >From the 9S12DP256 Device Guide, Erase Time for an EEPROM Sector is: t = 4000 / f.nvmop where f.nvmop = 200 kHz Maximum Certainly this must have affected other people... I have lots of fast- loops with real deadlines and simply cannot place everything inside timer interrupts. So now I'm considering writing an EEPROM driver which will buffer any data to be written to EEPROM and control both read and write accessibility... Anyone else have a simpler idea? Have I missed something? The EEPROM routine provided in the reference design actually stalls for 20ms while it waits for the commands to complete. I've managed to pipeline the Sector Modify and Program Word commands and get out of the routine in about 4us... but any read access to EEPROM within the 20ms produces invalid results. Open to any ideas or interested to hear how others have handled this.. N. Skura --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu <http://rd.yahoo.com/SIGca8qu6k/M&7637.4673018.5833253.1261774/D=eg roupweb/S06554205:HM/EXP80857719/A45637/R=0/SIGtfh3gpg/*http ://www.netflix.com/Default?mqso`178397&partidF73018> click here <http://us.adserver.yahoo.com/l?M&7637.4673018.5833253.1261774/D=egrou pweb/S=:HM/A45637/randG2545690 _____ > . --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu Yahoo! Groups Links |
Reply by ●April 5, 20042004-04-05
|
Neal, Buffering in RAM is also a good idea because of the EEPROM endurance spec. You might find that if you wrote to the EEPROM on every pass through a tight loop, the lifetime of your equipment would become limited by the EEPROM wearing out. That's why it's common to buffer the rapidly-updated data in RAM and flush it out periodically or at powerdown. For example, if some code wrote to a 812A4 EEPROM location at the minimum interval of 20 ms, it might wear out in 30000 cycles (typical), which is 10 minutes. Ouch! The 9S12DP256 uses a different EEPROM technology, so the endurance spec may well be different (better?), but you get the idea. Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center / CWRU / KG8IH |
|
|
Reply by ●April 5, 20042004-04-05
|
Have you considered an external serial eprom device? ----- Original Message ----- From: John Theofanopoulos To: Sent: Monday, April 05, 2004 10:54 AM Subject: RE: [68HC12] EEPROM Read and Write Access If you can get away with it, why not write to EEPROM before shutting down? That way, on startup you load your eeprom values to RAM and prior to shutdown you copy the contents of RAM over to EEPROM, so the EEPROM delay never comes into play during operation. John -----Original Message----- From: Longworth, Kevin [mailto:] Sent: Friday, April 02, 2004 4:41 PM To: Subject: RE: [68HC12] EEPROM Read and Write Access I use a ram image of the contents of the EEPROM and periodicly check for differences. If there are differences then launch the erase/program command using a state maching , just make sure you don't check for differences faster than 100ms or so. I use 1 sec. Any writes or reads from appllication come from the RAM image and eventually get in the NVM. Kevin -----Original Message----- From: nealskura [mailto:] Sent: Wednesday, March 31, 2004 5:14 PM To: Subject: [68HC12] EEPROM Read and Write Access I understand that in order to program any word or byte into EEPROM, the sector in which it resides must first be erased. But is it true that the erase and program process takes a full 20ms?? And that during this time, no other access can be made to EEPROM... even reading from another sector? >From the 9S12DP256 Device Guide, Erase Time for an EEPROM Sector is: t = 4000 / f.nvmop where f.nvmop = 200 kHz Maximum Certainly this must have affected other people... I have lots of fast- loops with real deadlines and simply cannot place everything inside timer interrupts. So now I'm considering writing an EEPROM driver which will buffer any data to be written to EEPROM and control both read and write accessibility... Anyone else have a simpler idea? Have I missed something? The EEPROM routine provided in the reference design actually stalls for 20ms while it waits for the commands to complete. I've managed to pipeline the Sector Modify and Program Word commands and get out of the routine in about 4us... but any read access to EEPROM within the 20ms produces invalid results. Open to any ideas or interested to hear how others have handled this.. N. Skura --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu <http://rd.yahoo.com/SIGca8qu6k/M&7637.4673018.5833253.1261774/D=eg roupweb/S06554205:HM/EXP80857719/A45637/R=0/SIGtfh3gpg/*http ://www.netflix.com/Default?mqso`178397&partidF73018> click here <http://us.adserver.yahoo.com/l?M&7637.4673018.5833253.1261774/D=egrou pweb/S=:HM/A45637/randG2545690 _____ > . --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu Yahoo! Groups Links --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu ---- -- Yahoo! Groups Links a.. To |
|
|
Reply by ●April 6, 20042004-04-06
|
At 02:32 PM 4/5/04, you wrote: >Have you considered an external serial eprom device? Considering that the original problem was that the writes take too long, a serial device doesn't immediately sound like an improvement. Gary Olmstead Toucan Technology Ventura CA |
|
|
Reply by ●April 7, 20042004-04-07
|
Stephen, Thanks for the advice. The EEPROM is not involved in my tight loops, but rather the problem was that while the software was stuck in an Erase/Program cycle for 20ms, many of my other tasks were not being attended to. My most critical code is inside a timer interrupt, and executes every 100 - 400us, so this was not affected. But I have other tasks, which due to driver issues, must remain in the background loop, and must execute approximately every 1ms. For now, I am mirroring all my EEPROM variables into RAM, and will use a RAM buffer to Erase/Program the EEPROM in an organized manner and thus eliminate the 20ms "wait-for-command-to-finish". Neal. --- In , Stephen Trier <sct@p...> wrote: > Neal, > > Buffering in RAM is also a good idea because of the EEPROM endurance > spec. You might find that if you wrote to the EEPROM on every pass > through a tight loop, the lifetime of your equipment would become > limited by the EEPROM wearing out. That's why it's common to buffer > the rapidly-updated data in RAM and flush it out periodically or at > powerdown. > > For example, if some code wrote to a 812A4 EEPROM location at > the minimum interval of 20 ms, it might wear out in 30000 cycles > (typical), which is 10 minutes. Ouch! > > The 9S12DP256 uses a different EEPROM technology, so the endurance > spec may well be different (better?), but you get the idea. > > Stephen > > -- > Stephen Trier > Technical Development Lab > Cleveland FES Center / CWRU > sct@p... / KG8IH |
