DOCSLIB.ORG

EEPROM Emulation and Data Record Storage Using the Upsd32xx

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
EEPROM Emulation and Data Record Storage Using the Upsd32xx AN2040 APPLICATION NOTE EEPROM Emulation and Data Record Storage Using the uPSD32xx Generally, EEPROM devices are used to store and retain data in the event of power failure. The data may be retrieved whenever required, and can be repeatedly updated (the device ratings usually specify an up- per figure between 100 thousand and 10 million Write/Erase cycles). One of the main differences, from the user point of view, between EEPROM and a uPSD device (which includes an extremely large Flash memory array) is the minimum granularity for erasing data. Typically, EEPROM allows the user to modify single byte locations: that is, data stored at a specific address can be updated individually. In contrast, the uPSD Flash memory provides random-access non-volatile data stor- age, a byte at a time, but can only be erased a sector at a time. However, Flash memory in general, and uPSD in particular, offers so many other advantages to the de- signer that it is often better to emulate the EEPROM in Flash memory, rather than to have a specific EE- PROM device. Emulation is achieved by employing two Boot Block sectors in the uPSD device: one that starts off erased, and offers byte-at-a-time programmability, and the other ready to take over when the first one needs to be garbage collected. The byte-at-a-time programmability uses a linked-list data storage algorithm to update stored data until the sector is full, at which time the valid data is swapped to a different sector and the orig- inal sector is erased. The EEPROM emulation code (which is listed in the appendices of this document) swaps data between the sectors as they become filled, in a manner that is transparent to the user. The EEPROM emulation driver meets the following requirements: ■ Minimum use of SRAM ■ Simple and easily updateable code model ■ User API consisting of initial format, read record, update record ■ Clean-up and internal data management transparent to the user ■ Background sector erase ■ Code in main Flash memory, database in boot Flash memory ■ At least two boot Flash memory sectors to be used, more if possible for wear leveling ■ No timers, interrupts or RTOS The EEPROM size to be emulated is flexible, within the limits and constraints of the sector size, and allows for a maximum EEPROM size of 8KBytes in the current implementation, which is the sector size that is defined by the uPSD32xx architecture. The header and source file, written in C on the Keil IDE for uPSD, are held in eeprom.h and eeprom.c (respectively). These can be downloaded with the C code, and use sectors 0 and 1 of the secondary (boot) flash to emulate EEPROM data storage. A sample demonstration program is also supplied to demonstrate and test the EEPROM Emulation using the DK3200 board. This application note describes the EEPROM Emulation driver, and the small demonstration program writ- ten for the DK3200 hardware demonstration kit (which incorporates a uPSD3234A device). September 2004 1/25 AN2040 - APPLICATION NOTE TABLE OF CONTENTS OPERATION . 3 User API . 3 EEPROM_Format . 3 Update_Record . 3 Update_Record (BYTE id, BYTE *buf) . .4 Read_Record . 4 Read_Record (WORD id, BYTE *buffer). 4 Eeprom_Init . 4 Data Structures and Error Recovery . 4 Figure 1. Data Storage Map . 5 Interrupted Sector Erase . 6 Interrupted Sector Swap . 6 Figure 2. Sector Swap Flowchart . 7 Table 1. Sector Status Byte Matrix . 8 Figure 3. Data Integrity Check Flowchart . .9 Lower Level Functions . 9 Write_Record (WORD id, BYTE *buffer) . 9 Boot_Flash_Write (WORD address, BYTE data_byte) . 9 Read_Record_Data_Structure (WORD id_number, BYTE *buffer) . 10 Boot_Flash_Read (WORD address) . 10 Eeprom_Sector_Erase (BYTE sector). 10 Eeprom_Sector_Erase_Start (BYTE sector) . 10 Eeprom_Sector_Erase_Suspend (BYTE sector) . 10 Eeprom_Sector_Erase_Resume (BYTE sector) . 10 Eeprom_Sector_Erase_Status (BYTE sector) . 10 Find_Next_Address (void) . 10 Find_Active_Sector (BYTE io). 10 Eeprom_Sector_Swap (BYTE inn, BYTE *buf) . 10 E_andF_Sector (BYTE sector, WORD max_rec) . 10 Get_Sector_Status (BYTE sector). 10 EEPROM Emulation Demonstration on DK3200. 11 Figure 4. Startup Screen. 12 Figure 5. Merging of MCU Firmware with PSD Screen . 13 APPENDIX A.UPDATES ENDURANCE COMPUTATION . 14 Parameters and Assumptions . .14 APPENDIX B.EEPROM EMULATION Demo code . 16 Changes to be Made at Compile Time. 16 APPENDIX C.DK3200 EEPROM DEMONSTRATION PROGRAM . 20 REVISION HISTORY. 24 Table 2. Document Revision History . 24 2/25 AN2040 - APPLICATION NOTE OPERATION This section describes the key features, functions and basic operation of the driver code. The algorithm used, in the supplied driver code, makes use of the robustness of the Flash memory device. By organizing the data and record entry in the particular structure that it does, provides for maximum data integrity as well as allowing for virtually unlimited updating of the data (APPENDIX A.). The EEPROM Emulation code requires input from the user, for it to determine the allocation and formatting of the memory sectors. Required parameters are explained in the User API. (The sample demonstration program, for example, uses 1 record of 128 bytes). Based on this input, the driver code reserves enough memory immediately after the sector header to hold one instance of each data record. Id numbers that correspond to those memory locations identify the data records. The id numbers are not part of the record themselves. Several low-level functions are provided that per- form the management of the read/write and maintenance of the database, based on the number of records and record size. Some error codes are generated that can be called by users in their application codes. (The demonstration program shows some of the error checks in use). The data structure and error recovery as well as the low-level functions are described later. User API The EEPROM Emulation code is also provided with a sample demonstration program, which is used to input the user parameters to the main code. Four functions are provided to the user for EEPROM data management in this implementation. They are: ■ EEPROM_Format ■ Update_Record ■ Read_Record ■ EEPROM_Init Overall the algorithm performs the data management, in a way that is completely transparent to the appli- cation, using many low-level functions that augment this mechanism. The user is also responsible for defining the data record size (in bytes), and the maximum number of records allowed. Valid values are 0 to 65535 (0 to 0xFFFF) for the current implementation. These param- eters have to be defined at compile- and run-time The data record size is defined in eeprom.h prior to compile-time. For the supplied demonstration program it has been set to 128 bytes. (APPENDIX B.) The maximum number of records is defined at run time via an argument to EEPROM_Format. (In the sup- plied demonstration program it has been set to one record only (APPENDIX C.) A brief description and usage of the four functions, that are available to the user as input, are as follows: EEPROM_Format. This writes a sector header to sector 0, and erases sector 1. Note that a call to this function will erase any existing data. Part of the formatting process involves verifying that the maximum number of records and the record size are compatible with the sector size. (The demonstration program provides an error check to test if this is not met). The user needs to correlate id numbers to data entries based on the application. Update_Record. Data is written using this function. (The demonstration program uses this function to write the contents of a buffer) The function accepts an id number and a pointer to a data buffer. The user is responsible for initializing the data buffer to the correct number of data bytes. Data is updated using the same function. The program will create a linked list of data updates until the sector is full. At that point, only the valid data is written to a new sector, along with the sector header. This is transparent to the user. 3/25 AN2040 - APPLICATION NOTE Update_Record (BYTE id, BYTE *buf). This function adds/updates a record entry with new data. The id number corresponds to the location in memory of the initial data entry. The user can correlate the id num- ber with the data in any way he or she chooses. The user must provide a pointer to a data array in xdata containing the data for the record. This function passes the id number and data pointer to Write_Record. Write_Record will either update the parameter or return an error saying that the sector is full. In the case of a full sector, the data is saved to an intermediate buffer and Eeprom_Sector_Swap is called. Eeprom_Sector_Swap transfers all valid data entries to a new sector, including the current update. Read_Record. This function is used to read any record. (In the demonstration program, it read backs the record written by update record). This function accepts the id number of the record and a pointer to a buffer to receive the data. Once again, it is the users’ responsibility to set up a data buffer of the appropriate type and size. (For the demonstration program, this buffer is set to size 1) Read_Record (WORD id, BYTE *buffer). This function reads record data into a buffer provided by the user. Only the last update is read. The record is retrieved as follows: First, the active sector is retrieved using the function Find_Active_Sector. The base address of the record is then determined from the active sector number. The base record corresponding to the id is then read. If the base record is not the last up- date, the function enters a loop in which it reads the record entries until the last one is found. The data is then copied into the buffer pointed to by *buffer.
Load more

Recommended publications
  • Hard Disk Drives
    37 Hard Disk Drives The last chapter introduced the general concept of an I/O device and showed you how the OS might interact with such a beast. In this chapter, we dive into more detail about one device in particular: the hard disk drive. These drives have been the main form of persistent data storage in computer systems for decades and much of the development of file sys- tem technology (coming soon) is predicated on their behavior. Thus, it is worth understanding the details of a disk’s operation before building the file system software that manages it. Many of these details are avail- able in excellent papers by Ruemmler and Wilkes [RW92] and Anderson, Dykes, and Riedel [ADR03]. CRUX: HOW TO STORE AND ACCESS DATA ON DISK How do modern hard-disk drives store data? What is the interface? How is the data actually laid out and accessed? How does disk schedul- ing improve performance? 37.1 The Interface Let’s start by understanding the interface to a modern disk drive. The basic interface for all modern drives is straightforward. The drive consists of a large number of sectors (512-byte blocks), each of which can be read or written. The sectors are numbered from 0 to n − 1 on a disk with n sectors. Thus, we can view the disk as an array of sectors; 0 to n − 1 is thus the address space of the drive. Multi-sector operations are possible; indeed, many file systems will read or write 4KB at a time (or more). However, when updating the disk, the only guarantee drive manufacturers make is that a single 512-byte write is atomic (i.e., it will either complete in its entirety or it won’t com- plete at all); thus, if an untimely power loss occurs, only a portion of a larger write may complete (sometimes called a torn write).
    [Show full text]
  • Nasdeluxe Z-Series
    NASdeluxe Z-Series Benefit from scalable ZFS data storage By partnering with Starline and with Starline Computer’s NASdeluxe Open-E, you receive highly efficient Z-series and Open-E JovianDSS. This and reliable storage solutions that software-defined storage solution is offer: Enhanced Storage Performance well-suited for a wide range of applica- tions. It caters perfectly to the needs • Great adaptability Tiered RAM and SSD cache of enterprises that are looking to de- • Tiered and all-flash storage Data integrity check ploy a flexible storage configuration systems which can be expanded to a high avail- Data compression and in-line • High IOPS through RAM and SSD ability cluster. Starline and Open-E can data deduplication caching look back on a strategic partnership of Thin provisioning and unlimited • Superb expandability with more than 10 years. As the first part- number of snapshots and clones ner with a Gold partnership level, Star- Starline’s high-density JBODs – line has always been working hand in without downtime Simplified management hand with Open-E to develop and de- Flexible scalability liver innovative data storage solutions. Starline’s NASdeluxe Z-Series offers In fact, Starline supports worldwide not only great features, but also great Hardware independence enterprises in managing and pro- flexibility – thanks to its modular archi- tecting their storage, with over 2,800 tecture. Open-E installations to date. www.starline.de Z-Series But even with a standard configuration with nearline HDDs IOPS and SSDs for caching, you will be able to achieve high IOPS 250 000 at a reasonable cost.
    [Show full text]
  • Use External Storage Devices Like Pen Drives, Cds, and Dvds
    External Intel® Learn Easy Steps Activity Card Storage Devices Using external storage devices like Pen Drives, CDs, and DVDs loading Videos Since the advent of computers, there has been a need to transfer data between devices and/or store them permanently. You may want to look at a file that you have created or an image that you have taken today one year later. For this it has to be stored somewhere securely. Similarly, you may want to give a document you have created or a digital picture you have taken to someone you know. There are many ways of doing this – online and offline. While online data transfer or storage requires the use of Internet, offline storage can be managed with minimum resources. The only requirement in this case would be a storage device. Earlier data storage devices used to mainly be Floppy drives which had a small storage space. However, with the development of computer technology, we today have pen drives, CD/DVD devices and other removable media to store and transfer data. With these, you store/save/copy files and folders containing data, pictures, videos, audio, etc. from your computer and even transfer them to another computer. They are called secondary storage devices. To access the data stored in these devices, you have to attach them to a computer and access the stored data. Some of the examples of external storage devices are- Pen drives, CDs, and DVDs. Introduction to Pen Drive/CD/DVD A pen drive is a small self-powered drive that connects to a computer directly through a USB port.
    [Show full text]
  • Nanotechnology Trends in Nonvolatile Memory Devices
    IBM Research Nanotechnology Trends in Nonvolatile Memory Devices Gian-Luca Bona [email protected] IBM Research, Almaden Research Center © 2008 IBM Corporation IBM Research The Elusive Universal Memory © 2008 IBM Corporation IBM Research Incumbent Semiconductor Memories SRAM Cost NOR FLASH DRAM NAND FLASH Attributes for universal memories: –Highest performance –Lowest active and standby power –Unlimited Read/Write endurance –Non-Volatility –Compatible to existing technologies –Continuously scalable –Lowest cost per bit Performance © 2008 IBM Corporation IBM Research Incumbent Semiconductor Memories SRAM Cost NOR FLASH DRAM NAND FLASH m+1 SLm SLm-1 WLn-1 WLn WLn+1 A new class of universal storage device : – a fast solid-state, nonvolatile RAM – enables compact, robust storage systems with solid state reliability and significantly improved cost- performance Performance © 2008 IBM Corporation IBM Research Non-volatile, universal semiconductor memory SL m+1 SL m SL m-1 WL n-1 WL n WL n+1 Everyone is looking for a dense (cheap) crosspoint memory. It is relatively easy to identify materials that show bistable hysteretic behavior (easily distinguishable, stable on/off states). IBM © 2006 IBM Corporation IBM Research The Memory Landscape © 2008 IBM Corporation IBM Research IBM Research Histogram of Memory Papers Papers presented at Symposium on VLSI Technology and IEDM; Ref.: G. Burr et al., IBM Journal of R&D, Vol.52, No.4/5, July 2008 © 2008 IBM Corporation IBM Research IBM Research Emerging Memory Technologies Memory technology remains an
    [Show full text]
  • Can We Store the Whole World's Data in DNA Storage?
    Can We Store the Whole World’s Data in DNA Storage? Bingzhe Li†, Nae Young Song†, Li Ou‡, and David H.C. Du† †Department of Computer Science and Engineering, University of Minnesota, Twin Cities ‡Department of Pediatrics, University of Minnesota, Twin Cities {lixx1743, song0455, ouxxx045, du}@umn.edu, Abstract DNA storage can achieve a theoretical density of 455 EB/g [9] and has a long-lasting property of several centuries [10,11]. The total amount of data in the world has been increasing These characteristics of DNA storage make it a great candi- rapidly. However, the increase of data storage capacity is date for archival storage. Many research studies focused on much slower than that of data generation. How to store and several research directions including encoding/decoding asso- archive such a huge amount of data becomes critical and ciated with error correction schemes [11–18], DNA storage challenging. Synthetic Deoxyribonucleic Acid (DNA) storage systems with microfluidic platforms [19–21], and applications is one of the promising candidates with high density and long- such as database on top of DNA storage [9]. Moreover, sev- term preservation for archival storage systems. The existing eral survey papers [22,23] on DNA storage mainly focused works have focused on the achievable feasibility of a small on the technology reviews of how to store data in DNA (in amount of data when using DNA as storage. In this paper, vivo or in vitro) including the encoding/decoding and synthe- we investigate the scalability and potentials of DNA storage sis/sequencing processes. In fact, the major focus of these when a huge amount of data, like all available data from the studies was to demonstrate the feasibility of DNA storage world, is to be stored.
    [Show full text]
  • The Future of DNA Data Storage the Future of DNA Data Storage
    The Future of DNA Data Storage The Future of DNA Data Storage September 2018 A POTOMAC INSTITUTE FOR POLICY STUDIES REPORT AC INST M IT O U T B T The Future O E P F O G S R IE of DNA P D O U Data LICY ST Storage September 2018 NOTICE: This report is a product of the Potomac Institute for Policy Studies. The conclusions of this report are our own, and do not necessarily represent the views of our sponsors or participants. Many thanks to the Potomac Institute staff and experts who reviewed and provided comments on this report. © 2018 Potomac Institute for Policy Studies Cover image: Alex Taliesen POTOMAC INSTITUTE FOR POLICY STUDIES 901 North Stuart St., Suite 1200 | Arlington, VA 22203 | 703-525-0770 | www.potomacinstitute.org CONTENTS EXECUTIVE SUMMARY 4 Findings 5 BACKGROUND 7 Data Storage Crisis 7 DNA as a Data Storage Medium 9 Advantages 10 History 11 CURRENT STATE OF DNA DATA STORAGE 13 Technology of DNA Data Storage 13 Writing Data to DNA 13 Reading Data from DNA 18 Key Players in DNA Data Storage 20 Academia 20 Research Consortium 21 Industry 21 Start-ups 21 Government 22 FORECAST OF DNA DATA STORAGE 23 DNA Synthesis Cost Forecast 23 Forecast for DNA Data Storage Tech Advancement 28 Increasing Data Storage Density in DNA 29 Advanced Coding Schemes 29 DNA Sequencing Methods 30 DNA Data Retrieval 31 CONCLUSIONS 32 ENDNOTES 33 Executive Summary The demand for digital data storage is currently has been developed to support applications in outpacing the world’s storage capabilities, and the life sciences industry and not for data storage the gap is widening as the amount of digital purposes.
    [Show full text]
  • Computer Files & Data Storage
    STORAGE & FILE CONCEPTS, UTILITIES (Pages 6, 150-158 - Discovering Computers & Microsoft Office 2010) I. Computer files – data, information or instructions residing on secondary storage are stored in the form of a file. A. Software files are also called program files. Program files (instructions) are created by a computer programmer and generally cannot be modified by a user. It’s important that we not move or delete program files because your computer requires them to perform operations. Program files are also referred to as “executables”. 1. You can identify a program file by its extension:“.EXE”, “.COM”, “.BAT”, “.DLL”, “.SYS”, or “.INI” (there are others) or a distinct program icon. B. Data files - when you select a “save” option while using an application program, you are in essence creating a data file. Users create data files. 1. File naming conventions refer to the guidelines followed while assigning file names and will vary with the operating system and application in use (see figure 4-1). File names in Windows 7 may be up to 255 characters, you're not allowed to use reserved characters or certain reserved words. File extensions are used to identify the application that was used to create the file and format data in a manner recognized by the source application used to create it. FALL 2012 1 II. Selecting secondary storage media A. There are three type of technologies for storage devices: magnetic, optical, & solid state, there are advantages & disadvantages between them. When selecting a secondary storage device, certain factors should be considered: 1. Capacity - the capacity of computer storage is expressed in bytes.
    [Show full text]
  • Digital Preservation Guide: 3.5-Inch Floppy Disks Caralie Heinrichs And
    DIGITAL PRESERVATION GUIDE: 3.5-Inch Floppy Disks Digital Preservation Guide: 3.5-Inch Floppy Disks Caralie Heinrichs and Emilie Vandal ISI 6354 University of Ottawa Jada Watson Friday, December 13, 2019 DIGITAL PRESERVATION GUIDE 2 Table of Contents Introduction ................................................................................................................................................. 3 History of the Floppy Disk ......................................................................................................................... 3 Where, when, and by whom was it developed? 3 Why was it developed? 4 How Does a 3.5-inch Floppy Disk Work? ................................................................................................. 5 Major parts of a floppy disk 5 Writing data on a floppy disk 7 Preservation and Digitization Challenges ................................................................................................. 8 Physical damage and degradation 8 Hardware and software obsolescence 9 Best Practices ............................................................................................................................................. 10 Storage conditions 10 Description and documentation 10 Creating a disk image 11 Ensuring authenticity: Write blockers 11 Ensuring reliability: Sustainability of the disk image file format 12 Metadata 12 Virus scanning 13 Ensuring integrity: checksums 13 Identifying personal or sensitive information 13 Best practices: Use of hardware and software 14 Hardware
    [Show full text]
  • AN568: EEPROM Emulation for Flash Microcontrollers
    AN568 EEPROM EMULATION FOR FLASH MICROCONTROLLERS 1. Introduction Non-volatile data storage is an important feature of many embedded systems. Dedicated, byte-writeable EEPROM devices are commonly used in such systems to store calibration constants and other parameters that may need to be updated periodically. These devices are typically accessed by an MCU in the system using a serial bus. This solution requires PCB real estate as well as I/O pins and serial bus resources on the MCU. Some cost efficiencies can be realized by using a small amount of the MCU’s flash memory for the EEPROM storage. This note describes firmware designed to emulate EEPROM storage on Silicon Laboratories’ flash-based C8051Fxxx MCUs. Figure 1 shows a map of the example firmware. The highlighted functions are the interface for the main application code. 2. Key Features Compile-Time Configurable Size: Between 4 and 255 bytes Portable: Works across C8051Fxxx device families and popular 8051 compilers Fault Tolerant: Resistant to corruption from power supply events and errant code Small Code Footprint: Less than 1 kB for interface functions + minimum two pages of Flash for data storage User Code Fxxx_EEPROM_Interface.c EEPROM_WriteBlock() EEPROM_ReadBlock() copySector() findCurrentSector() getBaseAddress() findNextSector() Fxxx_Flash_Interface.c FLASH_WriteErase() FLASH_BlankCheck() FLASH_Read() Figure 1. EEPROM Emulation Firmware Rev. 0.1 12/10 Copyright © 2010 by Silicon Laboratories AN568 AN568 3. Basic Operation A very simple example project and wrapper code is included with the source firmware. The example demonstrates how to set up a project with the appropriate files within the Silicon Labs IDE and how to call the EEPROM access functions from user code.
    [Show full text]
  • Modular Data Storage with Anvil
    Modular Data Storage with Anvil Mike Mammarella Shant Hovsepian Eddie Kohler UCLA UCLA UCLA/Meraki [email protected] [email protected] [email protected] http://www.read.cs.ucla.edu/anvil/ ABSTRACT age strategies and behaviors. We intend Anvil configura- Databases have achieved orders-of-magnitude performance tions to serve as single-machine back-end storage layers for improvements by changing the layout of stored data – for databases and other structured data management systems. instance, by arranging data in columns or compressing it be- The basic Anvil abstraction is the dTable, an abstract key- fore storage. These improvements have been implemented value store. Some dTables communicate directly with sta- in monolithic new engines, however, making it difficult to ble storage, while others layer above storage dTables, trans- experiment with feature combinations or extensions. We forming their contents. dTables can represent row stores present Anvil, a modular and extensible toolkit for build- and column stores, but their fine-grained modularity of- ing database back ends. Anvil’s storage modules, called dTa- fers database designers more possibilities. For example, a bles, have much finer granularity than prior work. For ex- typical Anvil configuration splits a single “table” into sev- ample, some dTables specialize in writing data, while oth- eral distinct dTables, including a log to absorb writes and ers provide optimized read-only formats. This specialization read-optimized structures to satisfy uncached queries. This makes both kinds of dTable simple to write and understand. split introduces opportunities for clean extensibility – for Unifying dTables implement more comprehensive function- example, we present a Bloom filter dTable that can slot ality by layering over other dTables – for instance, building a above read-optimized stores and improve the performance read/write store from read-only tables and a writable journal, of nonexistent key lookup.
    [Show full text]
  • Computer Hardware SIG Non-Removable Storage Devices – Feb
    Computer Hardware SIG Non-Removable Storage Devices – Feb. 1, 2012 A hard disk drive (HDD; also hard drive, hard disk, or disk drive) is a device for storing and retrieving digital information, primarily computer data. It consists of one or more rigid (hence "hard") rapidly rotating discs (often referred to as platters), coated with magnetic material and with magnetic heads arranged to write data to the surfaces and read it from them. Hard drives are classified as non-volatile, random access, digital, magnetic, data storage devices. Introduced by IBM in 1956, hard disk drives have decreased in cost and physical size over the years while dramatically increasing in capacity and speed. Hard disk drives have been the dominant device for secondary storage of data in general purpose computers since the early 1960s. They have maintained this position because advances in their recording capacity, cost, reliability, and speed have kept pace with the requirements for secondary storage Types of Hard Drives Parallel ATA (PATA), originally AT Attachment (old term IDE), is an interface standard for the connection of storage devices such as hard disks, solid-state drives, floppy drives, and optical disc drives in computers. The standard is maintained by X3/INCITS committee. It uses the underlying AT Attachment (ATA) and AT Attachment Packet Interface (ATAPI) standards. The Parallel ATA standard is the result of a long history of incremental technical development, which began with the original AT Attachment interface, developed for use in early PC AT equipment. The ATA interface itself evolved in several stages from Western Digital's original Integrated Drive Electronics (IDE) interface.
    [Show full text]
  • Hard Disk Drive Specifications Models: 2R015H1 & 2R010H1
    Hard Disk Drive Specifications Models: 2R015H1 & 2R010H1 P/N:1525/rev. A This publication could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein – which will be incorporated in revised editions of the publication. Maxtor may make changes or improvements in the product(s) described in this publication at any time and without notice. Copyright © 2001 Maxtor Corporation. All rights reserved. Maxtor®, MaxFax® and No Quibble Service® are registered trademarks of Maxtor Corporation. Other brands or products are trademarks or registered trademarks of their respective holders. Corporate Headquarters 510 Cottonwood Drive Milpitas, California 95035 Tel: 408-432-1700 Fax: 408-432-4510 Research and Development Center 2190 Miller Drive Longmont, Colorado 80501 Tel: 303-651-6000 Fax: 303-678-2165 Before You Begin Thank you for your interest in Maxtor hard drives. This manual provides technical information for OEM engineers and systems integrators regarding the installation and use of Maxtor hard drives. Drive repair should be performed only at an authorized repair center. For repair information, contact the Maxtor Customer Service Center at 800- 2MAXTOR or 408-922-2085. Before unpacking the hard drive, please review Sections 1 through 4. CAUTION Maxtor hard drives are precision products. Failure to follow these precautions and guidelines outlined here may lead to product failure, damage and invalidation of all warranties. 1 BEFORE unpacking or handling a drive, take all proper electro-static discharge (ESD) precautions, including personnel and equipment grounding. Stand-alone drives are sensitive to ESD damage. 2 BEFORE removing drives from their packing material, allow them to reach room temperature.
    [Show full text]