|
I have been using a set of routines for over a year to read and write to the internal EEPROM memory of a 68HC912DG128A processor. The routines have worked without incident. During the development phase of these routines I thought it necessary to disable interrupts before accessing the EEPROM module to either write or erase any memory. While most of the code is well commented, this one line has no comments. I have reviewed the Rev 3 manual for this MCU and can't find a compelling reason that interrupts must be disabled to ensure EEPROM erase/write success. Is there any reason to disable interrupts during EEPROM erase or write operations? The relevant portion of my code that performs byte write operations is as follows: #define EE_UNLOCK_MASK (0xC0) // Clr all block protection #ifdef __HC12__ #pragma DATA_SEG DATA_EEPROM // Make sure array points to EEPROM for HC12 #endif union { USHORT words[MAX_EE_UINTS]; // Access NVMEM using 16-bit words UCHAR bytes[MAX_EE_UINTS*2]; // Access NVMEM byte by byte } nvmem; UCHAR *b_data, result, lock_hold; ***[SNIP]*** BULKP = 1; // Protect EEPROM from BULK or ROW Erase (1) AUTO = 1; // Auto clear EEPGM on Program Complete BYTE = 1; // Single Byte erase (1) ROW = 0; // N/A for Single Byte mode (0) ERASE = 0; // Configure for EEPROM Programming (0) EEPROT = EE_UNLOCK_MASK; // Unprotect all EEPROM blocks (0xC0) EELAT = 1; // Enable EEPROM WRITE mode Address Latches for(i=0;i<num;i++) { if(*b_data != 0xFF) { // Ignore attempts to write FF nvmem.bytes[index+i] = *b_data++; // Write the Data to the EEPROM Latch EEPGM = 1; // Program the Byte } // Wait for AUTO mode to clear EEPGM - cycle completed // NOTE: This can hang if an attempt is made to program // a protected area of EEPROM!!! use a timeout. // If timeout is used - must write EEPGM=0 and then // write EELAT = 0. to_count = 0xFFFF; // Initialize Timeout Counter for(;;) { if(--to_count == 0) { result = EE_FAILED; EEPGM = 0; // MUST Disable Programming on Timeout!! break; } if(!EEPGM) break; } if(result != EE_OK) { break; } } EELAT = 0; // Enable EEPROM READ mode EEPROG = 0x80; // Reset EEPROG Register return(result); Stephen Killingsworth President, Embedded XLence, Inc. Embedded Systems Engineering Contracting for Perry Slingsby Systems Inc. 561-401-2061 Cell: 561-602-5823 This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Technip-Coflexip nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified |
|
|
HC912 EEPROM Write/Erase vs Interrupts
Started by ●May 12, 2003
Reply by ●May 12, 20032003-05-12
|
At 12:38 AM 5/13/03 +0200, you wrote: > >Is there any reason to disable interrupts during EEPROM erase or write >operations? > Two reasons: One is that the EEPROM's life is shortened by being over-programmed, and an interrupt extends the program cycle. Two, the EEPROM is not in the memory map during the program cycle. I know that _you_ know that, but if the program is large enough or has a long enough life that more than one programmer works on it, the other person may write code that reads the EEPROM during an interrupt. If that interrupt occurs while the EEPROM is being programmed, you can get a problem that is very hard to find. I learned that on the very first HC11 program I ever wrote, and it has stayed with me all these years. Gary Olmstead Toucan Technology Ventura CA |
Reply by ●May 13, 20032003-05-13
|
I have been using a set of routines for over a year to read and write to the internal EEPROM memory of a 68HC912DG128A processor. The routines have worked without incident. During the development phase of these routines I thought it necessary to disable interrupts before accessing the EEPROM module to either write or erase any memory. While most of the code is well commented, this one line has no comments. I have reviewed the Rev 3 manual for this MCU and can't find a compelling reason that interrupts must be disabled to ensure EEPROM erase/write success. Is there any requirement or reasonable argument to disable interrupts during EEPROM erase or write operations? None of my ISRs access the EEPROM memory region. The relevant portion of my code that performs byte write operations is as follows: #define EE_UNLOCK_MASK (0xC0) // Clr all block protection #ifdef __HC12__ #pragma DATA_SEG DATA_EEPROM // Make sure array points to EEPROM for HC12 #endif union { USHORT words[MAX_EE_UINTS]; // Access NVMEM using 16-bit words UCHAR bytes[MAX_EE_UINTS*2]; // Access NVMEM byte by byte } nvmem; UCHAR *b_data, result, lock_hold; ***[SNIP]*** BULKP = 1; // Protect EEPROM from BULK or ROW Erase (1) AUTO = 1; // Auto clear EEPGM on Program Complete BYTE = 1; // Single Byte erase (1) ROW = 0; // N/A for Single Byte mode (0) ERASE = 0; // Configure for EEPROM Programming (0) EEPROT = EE_UNLOCK_MASK; // Unprotect all EEPROM blocks (0xC0) EELAT = 1; // Enable EEPROM WRITE mode Address Latches for(i=0;i<num;i++) { if(*b_data != 0xFF) { // Ignore attempts to write FF nvmem.bytes[index+i] = *b_data++; // Write the Data to the EEPROM Latch EEPGM = 1; // Program the Byte } // Wait for AUTO mode to clear EEPGM - cycle completed // NOTE: This can hang if an attempt is made to program // a protected area of EEPROM!!! use a timeout. // If timeout is used - must write EEPGM=0 and then // write EELAT = 0. to_count = 0xFFFF; // Initialize Timeout Counter for(;;) { if(--to_count == 0) { result = EE_FAILED; EEPGM = 0; // MUST Disable Programming on Timeout!! break; } if(!EEPGM) break; } if(result != EE_OK) { break; } } EELAT = 0; // Enable EEPROM READ mode EEPROG = 0x80; // Reset EEPROG Register return(result); This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Technip-Coflexip nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified |
