Application Note: EEPROM Emulation on the Z51F3220

Application Note: EEPROM Emulation on the Z51F3220

Application Note EEPROM Emulation on the Z51F3220 MCU AN036501-1013 Abstract This application note provides a method for utilizing a segment of the Z51F3220 MCU’s Flash memory to emulate the functionality of an EEPROM device. The data written to Flash remains protected from power loss and inadvertent writes, because special instruc- tion sequences are required to write or erase Flash memory. Note: The source code file associated with this application note, AN0365-SC01.zip, is available free for download from the Zilog website. This source code was compiled using the Keil μVision4 and Small Device C Compiler (SDCC) v 3.1.0 tools. The Keil μVision4 develop- ment tool is available from Keil; the SDCC v3.1.0 tool is included in version 2.1 of the Z8051 Software and Documentation set, which is available free for download from the Zilog Store. For this source code to work properly with other Z8051 MCUs, minor modifi- cations to the source code may be required. Discussion This section describes the Flash memory spaces of the Z8051 MCU, including a virtual EEPROM emulation technique. Z8051 Internal Flash Memory The on-chip program Flash memory in Zilog’s Z8051 MCUs feature nonvolatile, linearly- addressable, Flash memory with in-circuit write/erase capability. This Flash memory can be read with a MOVC instruction and can be programmed in the On-Chip-Debugger (OCD), Serial In-System Programming (ISP), or User Program modes. The contents of Flash memory are divided into sectors, which are blocks of consecutive Flash addresses. The Z51F3220 MCU contains 512 sectors with 64 bytes on each sector. A Flash byte loca- tion comprises eight Flash cells, with each cell representing one bit. In a typical Flash cell, a logic 0 represents an erased state, and a logic 1 represents a programming state. There- fore, a byte location in the erased state reads as 0x00 and can be programmed to any other value by flipping its 0s to 1s. Changing the state of a cell from 1 to 0 can be accomplished only by erasing an entire sec- tor. A sector erase occurs when all of the bytes in a sector are erased at the same time. In an erase cycle, a sector, or several sectors, are erased. Each cell of Flash memory can per- form a specified number of erase cycles; this number is termed endurance. In the Z51F3220 MCU, the endurance of each Flash cell is at least 100,000 write/erase cycles. The primary purpose of the Z8051 MCU’s on-chip Flash memory is to store software pro- AN036501-1013 Page 1 of 19 EEPROM Emulation on the Z51F3220 MCU Application Note gramming instructions. When code is programmed, some portions of Flash are not uti- lized, and remain free. These unused portions can be earmarked for virtual EEPROM memory. EEPROM Emulation Technique Generally, an EEPROM chip stores and retains data in the event of a power failure. The data is retrieved when required and updated in the same location (up to the maximum device rating). A virtual software version of an EEPROM can be used instead of a traditional EEPROM chip, and can emulate generic EEPROM functionality in Zilog’s Z8051 on-chip Flash memory. This emulation is performed in various ways by considering Flash limitations and product requirements. At a minimum, all EEPROM emulation implementations require data and address pairs to be stored in Flash locations for subsequent retrieval or update. When data is modified, the modified data associated with an earlier virtual address is stored in a new Flash location. During data retrieval, this modified data is returned. If a new (blank) Flash location on the appropriate page is not available, that page is erased after its valid contents are copied to a new page. The modified data is then written to the new page. Consequently, virtual EEPROM is useful in products requiring frequent updates to data items in the field or during run time. Example. A remotely-located weather data logger that is required to record ambient tem- perature values at regular intervals can utilize virtual EEPROM to store the latest time and temperature values in the Z8051 MCU’s on-chip Flash. The only working limitation is that this Flash memory contains a finite number of erase cycles and a finite amount of memory. As data is being written to Flash in an emulated EEPROM, it is prone to corruption or ambiguity due to power failure, fluctuations in voltage supply, or loss of voltage. These conditions must be considered carefully when designing an application. Developing an EEPROM Emulation This section describes variable structures in EEPROM memory. Variable Structure A tag byte and its associated data byte combine to create a variable that requires two bytes of storage space. Figure 1 shows the structure of this variable. AN036501-1013 Page 2 of 19 EEPROM Emulation on the Z51F3220 MCU Application Note Figure 1. Structure of a Variable The tag byte is configured as follows: • The most significant bit (msb) is used as a dedicated bit to indicate whether the associ- ated data byte is the latest (msb = 1) or old (msb = 0) • The remaining seven bits are used to store a 7 bit virtual address value (ranging from 0x01 to 0x7F) The virtual address value on a page is calculated as follows: Virtual Address Value = ( Virtual EEPROM Address - ( PAGE_VARIABLES * ( PAGE_NUMBER - 1 ) ) ) + 1 In this equation, the following statements are true: • A virtual EEPROM address is a user-specified address • PAGE_VARIABLES is the total number of bytes that can be stored on a single virtual EEPROM page • PAGE_NUMBER is the virtual page number; it is always an integer A virtual page number is calculated as follows: Virtual page number = (virtual EEPROM address ÷ PAGE_VARIABLES) + 1 Virtual Page Number Byte and Page Integrity Byte The last two physical addresses in every four Flash sectors are reserved as a virtual page number byte and a page integrity byte, respectively. Figure 2 shows a representation of these virtual page number and page integrity bytes. AN036501-1013 Page 3 of 19 EEPROM Emulation on the Z51F3220 MCU Application Note Figure 2. Emulated EEPROM in Z51F3220 Flash A virtual page number byte indicates the page number of a virtual page in the emulated EEPROM. For newly-erased Flash memory, the final four sectors of the device are main- tained as a transfer page. Each group of four consecutive sectors that precede the transfer page act as virtual page number 1, virtual page number 2, etc. This sequence continues until the allotted number of pages is reached, and changes when the data is modified and stored as a result of page erasures. A page integrity byte indicates the validity of data on a page. Values for these page integ- rity bytes – and interpretations of these values – are listed below. • 0xFF: indicates that the page is valid • 0xCC: indicates that data on this page is invalid (i.e., an incomplete transfer) • 0x00: indicates that the page is blank (i.e., contains no data) Specifications The EEPROM emulation implemented in this application is based on the following specifications: • Virtual EEPROM is accessible as a linearly-addressable range (i.e., 0000h–1FBFh). • The size of the data to be stored is one byte long (i.e., ranging from 00h to FFh). AN036501-1013 Page 4 of 19 EEPROM Emulation on the Z51F3220 MCU Application Note • Four Flash sectors form a virtual EEPROM page, which contains 127 bytes of data. • A minimum of two (2) virtual EEPROM pages are required for storing variables as tag- data pairs: one to store tag-data pairs, and the other to be used as a transfer page when the first page is erased. The erased page is then used as a transfer page. • The first virtual EEPROM page should be located at the last sector of Flash memory to avoid the overlapping of the program code and virtual EEPROM (4 KB). Hardware Implementation The Z51F3220 Development Board used in this application is connected to a PC using an USB A (male) to Mini-B cable. An on-chip debugger is connected to the Z51F3220 Development Board when downloading the application software to the MCU. Figure 3 shows an example of this hardware setup. Figure 3. Hardware Setup The USB cable provides two functions: it powers the Development Board and serves as the communication line between the PC and the MCU. On the Development Board, the cable is connected to the FTDI UART-to-USB chip, which is connected to the UART pins. AN036501-1013 Page 5 of 19 EEPROM Emulation on the Z51F3220 MCU Application Note Software Implementation The software for this application can be compiled using Keil μVision v4.53.0.6 or SDCC v3.1.0. The primary source code files for this application are the flash.c and eeprom.c files. The flash.c file contains the routines that manage the writing, reading, and erasing of Flash memory, while the eeprom.c file contains routines for EEPROM emulation. Flash Memory Operations In this application, Flash memory is read, written, and erased in User Program Mode; these routines are listed below, and described in this section. • FLASH_Write • FLASH_Read • FLASH_SectorErase • FLASH_ByteErase FLASH_Write The FLASH_Write routine writes a byte to a specific location in Flash memory. This rou- tine begins by setting the Flash Mode Control (FMCR) Register to 01h to clear the page buffer, then sends three NOP instructions. The routine then writes the data to the page buf- fer. The following code segment shows how to write this data in the page buffer. #pragma asm MOV A, ucData MOV DPH, #0x80 MOV DPL, ucPgBffrAddLwRg MOVX @DPTR, A #pragma endasm Next, the Flash Sector Address High (FSADRH), Mid (FSADRM), and Low (FSADRL) registers are set, as indicated in the following code segment.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    19 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us