Flash Data Integrator (FDI) User’s Guide - Welcome …cpop/Documentatie_SMP/Intel...Copies of...

D

Flash Data Integrator (FDI)User’s Guide

November, 1998

Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel orotherwise, to any intellectual property rights is granted by this document. Except as provided in Intel’s Terms and Conditionsof Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relatingto sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability,or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical,life saving, or life sustaining applications.

Intel may make changes to specifications and product descriptions at any time, without notice.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your productorder.

Copies of documents which have an ordering number and are referenced in this document, or other Intel literature, may beobtained from:

Intel CorporationP.O. Box 5937Denver, CO 80217-9808

or call 1-800-548-4725or visit Intel’s Website at http:\\www.intel.com

COPYRIGHT © INTEL CORPORATION, 1998 CG-041493

*Third-party brands and names are the property of their respective owners.

i

11/3/98 10:36 AM TOC.DOC

TABLE OF CONTENTS

CHAPTER 1TECHNICAL OVERVIEW

CHAPTER 2GETTING STARTED2.1 EVALUATION ...............................................................................................................2-22.2 DEVELOPMENT...........................................................................................................2-4

CHAPTER 3EEPROM REPLACEMENT WITH FLASH MEMORY3.1 INTRODUCTION...........................................................................................................3-13.2 MEMORY FUNDAMENTALS........................................................................................3-2

3.2.1 Memory Architecture ...........................................................................................3-23.2.2 Program/Erase Timing.........................................................................................3-23.2.3 Specialized Flash RWW Circuits .........................................................................3-63.2.4 Hardware Assisted Suspend to Read/Write ........................................................3-8

3.3 FLASH DATA INTEGRATOR SOFTWARE STRUCTURE .........................................3-113.3.1 Flash Data Integrator Functional Overview .......................................................3-113.3.2 EEPROM Parameter Types...............................................................................3-123.3.3 Parameter Storage and Management ...............................................................3-133.3.4 Read Latency ....................................................................................................3-143.3.5 Real Time Interrupt Support ..............................................................................3-143.3.6 FDI Features......................................................................................................3-15

3.4 DEVELOPMENT RESOURCES .................................................................................3-153.5 SYSTEM REQUIREMENTS........................................................................................3-16

3.5.1 Random Access Memory Requirements ...........................................................3-163.5.2 Flash Memory Requirements.............................................................................3-16

3.6 PARAMETER CYCLING.............................................................................................3-173.7 POWER LOSS RECOVERY.......................................................................................3-183.8 CONCLUSION ............................................................................................................3-18

CHAPTER 4DATA STREAMING4.1 INTRODUCTION...........................................................................................................4-14.2 STREAMS vs.PARAMETERS.......................................................................................4-14.3 IMPLEMENTING DATA STREAMING IN AN APPLICATION.......................................4-4

4.3.1 Sample Code.......................................................................................................4-74.4 CORRECTLY IMPLEMENTING POWER LOSS RECOVERY......................................4-7

4.4.1 Tracking Valid Data and Empty Space ................................................................4-74.4.2 Recovering Data after Power Loss......................................................................4-9

CONTENTS

ii

11/3/98 10:36 AM TOC.DOC

CHAPTER 5ARCHITECTURE AND API SPECIFICATION5.1 INTRODUCTION...........................................................................................................5-1

5.1.1 Scope ..................................................................................................................5-15.1.2 Purpose ...............................................................................................................5-15.1.3 System Overview.................................................................................................5-15.1.4 Chapter Overview................................................................................................5-2

5.2 FLASH DATA INTEGRATOR REFERENCES ..............................................................5-35.2.1 Glossary ..............................................................................................................5-3

5.2.1.1 DEFINITIONS..........................................................................................5-35.2.1.2 ACRONYMS............................................................................................5-35.2.1.3 ABBREVIATIONS....................................................................................5-3

5.2.2 References ..........................................................................................................5-45.3 FLASH DATA INTEGRATOR GENERAL DESCRIPTION............................................5-4

5.3.1 Flash Data Integrator Product Perspective ..........................................................5-45.3.2 Foreground APIs .................................................................................................5-65.3.3 Background Manager and RECL_Task ...............................................................5-75.3.4 Initialization..........................................................................................................5-7

5.3.4.1 POWER LOSS RECOVERY PROCESS.................................................5-75.3.5 Low-Level Code and Interrupt Handling ..............................................................5-85.3.6 Implementation Constraints .................................................................................5-85.3.7 Assumptions, Dependencies and Limitations ......................................................5-8

5.4 FLASH DATA INTEGRATOR DETAILED DESIGN ......................................................5-95.4.1 Media Control Structures .....................................................................................5-9

5.4.1.1 CONTROL STRUCTURES USED BY FDI ............................................5-105.4.1.2 HOW FDI USES CONTROL STRUCTURES ........................................5-105.4.1.3 RAM USAGE AND CONTROL STRUCTURES.....................................5-25

5.4.2 Modules .............................................................................................................5-255.4.2.1 FOREGROUND API SUB-SYSTEM......................................................5-255.4.2.2 FAST FLASH READ CONFIGURATION...............................................5-565.4.2.3 BACKGROUND MANAGER SUB-SYSTEM..........................................5-585.4.2.4 BOOT CODE MANAGER SUB-SYSTEM..............................................5-69

5.5 RETURN ERROR CODES..........................................................................................5-70

CHAPTER 6PORTING6.1 INTRODUCTION...........................................................................................................6-1

6.1.1 Introduction to the Source Code ..........................................................................6-26.1.1.1 FOREGROUND API INTERFACE...........................................................6-26.1.1.2 BACKGROUND MANAGER AND FLASH MEDIA MANAGEMENT........6-26.1.1.3 LOW-LEVEL DRIVER (LLD)....................................................................6-3

6.2 GETTING STARTED ....................................................................................................6-36.2.1 General Porting to Your System ..........................................................................6-36.2.2 Implementation Considerations ...........................................................................6-4

6.2.2.1 GENERAL CONSIDERATIONS ..............................................................6-46.2.2.2 MULTI-TASKING CONSIDERATIONS....................................................6-5

6.3 FDI REQUIREMENTS ..................................................................................................6-56.3.1 FDI Operational Requirements............................................................................6-56.3.2 FDI Development Requirements .........................................................................6-6

6.4 FILE BREAKDOWN......................................................................................................6-66.4.1 File Descriptions ..................................................................................................6-7

6.5 MODIFYING HEADER FILES.......................................................................................6-8

CONTENTS

iii

11/3/98 10:36 AM TOC.DOC

6.5.1 Include .................................................................................................................6-96.5.1.1 TYPE.H....................................................................................................6-9

6.6 VARIABLE RAM USAGE..................................................................................................6-176.6.1 FDI_EXT.C ........................................................................................................6-18

6.6.1.1 FDI_DataLookupTable [NUM_IDENTIFIERS] .......................................6-186.6.2 FDI_INT.C .........................................................................................................6-18

6.6.2.1 FDI_LogicalBlockTable [MAX_DATA_BLOCKS] ...................................6-186.6.3 LOWLVL.C ........................................................................................................6-18

6.6.3.1 Low-Level Algorithms ............................................................................6-186.6.4 QUEUE.C ..........................................................................................................6-19

6.6.4.1 Queue Size............................................................................................6-196.7 PLATFORM AND COMPILER ARCHITECTURE .......................................................6-196.8 REPLACING LOW-LEVEL DRIVER INTERFACE FUNCTIONS (LOWLVL) ..............6-196.9 UNDERSTANDING DEFINES AND MACROS IN THE LOW-LEVEL DRIVER...........6-21

6.9.1 Compile Options ................................................................................................6-226.9.2 Configuration-Specific Defines ..........................................................................6-23

6.9.2.1 FLASH COMMAND DEFINES...............................................................6-236.9.2.2 PLATFORM DEFINES...........................................................................6-24

6.9.3 Time Monitoring.................................................................................................6-246.9.4 Interrupt Control Definitions ...............................................................................6-256.9.5 Board-Specific Definitions .................................................................................6-28

6.10 DEVELOPMENT ENVIRONMENT CONSIDERATIONS.............................................6-296.10.1 The UNIX* Development Environment ............................................................6-296.10.2 The Existing Make Files ..................................................................................6-306.10.3 Make Files–Adapt Existing, or Create Your Own? ..........................................6-31

CHAPTER 7TEST ENVIRONMENT7.1 INTRODUCTION...........................................................................................................7-17.2 DEFINITIONS AND CONVENTIONS............................................................................7-27.3 SYSTEM ENVIRONMENT SOFTWARE ARCHITECTURE..........................................7-4

7.3.1 PC User Interface ................................................................................................7-57.3.2 PC Asynchronous Communication ......................................................................7-67.3.3 Embedded Asynchronous Communication..........................................................7-67.3.4 Embedded GSM Emulation Software ..................................................................7-6

7.4 PARAMETER STORAGE EMULATION .......................................................................7-67.5 DATA STREAM EMULATION.......................................................................................7-87.6 TIMING ENVIRONMENT ..............................................................................................7-8

7.6.1 TDMA Time Slots ..............................................................................................7-107.6.2 TDMA Frames ...................................................................................................7-107.6.3 TDMA Multi-Frames ..........................................................................................7-10

7.6.3.1 SIGNALING MULTI-FRAME..................................................................7-117.6.3.2 TRAFFIC MULTI-FRAME ......................................................................7-11

7.6.4 TDMA Super-Frame ..........................................................................................7-127.6.5 TDMA Hyper-Frame ..........................................................................................7-127.6.6 Background CPU Availability .............................................................................7-127.6.7 Communication Channels .................................................................................7-12

7.7 POWER LOSS RECOVERY TESTING ......................................................................7-13

CHAPTER 8SYSTEM VALIDATION TEST PLAN

CONTENTS

iv

11/3/98 10:36 AM TOC.DOC

APPENDIX AFAQs

APPENDIX BDOCUMENTATION AND TECHNICAL SUPPORT

APPENDIX CSYSTEM/FLASH HARDWARE REQUIREMENTS

APPENDIX DLICENSE AGREEMENT

APPENDIX EAPPLICATION EXAMPLE CODE

GLOSSARY

INDEX

Figures

Figure Title Page1-1. Typical Memory Subsystem in Today’s Designs.......................................................1-11-2. Relative Cost and Die Sizes of Differing Approaches to Code Plus Data Storage ..1-22-1. Flowchart Indicating the Chapters That Are Useful during FDI Evaluation ...............2-32-2. Flowchart Indicating the Chapters That Are Useful during FDI Development ...........2-43-1. Intel’s Flash Memory Architectures ...........................................................................3-33-2. Maximum Write Timing .............................................................................................3-53-3. Cycling Effects on Erase Time ..................................................................................3-53-4. Comparison of Standard and Specialized Flash Memory Architectures for RWW ...3-83-5. Program Suspend/Resume Flowchart ......................................................................3-93-6. Block Erase Suspend/Resume Flowchart ...............................................................3-103-7. FDI Information Flow between Flash and SRAM Memory ......................................3-123-8. Flash Media Manager .............................................................................................3-144-1. Command Control Structure .....................................................................................4-24-2. Parameter and Stream Types ...................................................................................4-24-3. Example Showing Only One Stream Open at a Time ...............................................4-34-4. Retrieving Data with Get_First and GET_Next .........................................................4-44-5. Data Streaming Methodology....................................................................................4-54-6. Data Streaming without Reserved Space (Using Write_Append) .............................4-64-7. Data Streaming with Reserved Space (Using Write_Reserved and Write_Modify) ..4-64-8. Power Loss Recovery Status Header for Data Streams ...........................................4-85-1. Simplified System Software Architecture ..................................................................5-25-2. Simplified System Software Architecture Using FDI .................................................5-45-3. Software Flash Data Integrator Data Flow Diagram .................................................5-65-4. Code + Data Storage Arrangement in Flash .............................................................5-95-5. Data Block Arrangement .........................................................................................5-115-6. Example of Multiple Instances ................................................................................5-155-7. Parameter Update with New Instance.....................................................................5-155-8. Placement of Block Information ..............................................................................5-16

CONTENTS

v

11/3/98 10:36 AM TOC.DOC

5-9. A Sequence Table Example....................................................................................5-205-10. Data Queue Structure .............................................................................................5-225-11. Block Lock Flowchart for Advanced+ Boot Block ....................................................5-465-12. Reclaim Candidate and Spare ................................................................................5-635-13. Transferring Valid Data to the Spare Block .............................................................5-645-14. Update Status for Erasing of the Reclaim Block .....................................................5-655-15. Erasing the Reclaim Block ......................................................................................5-665-16. Status after Reclamation.........................................................................................5-676-1. Simplified System Software Architecture Using FDI .................................................6-27-1. System Overview ......................................................................................................7-27-2. Software Overview....................................................................................................7-57-3. Time Division Multiple Access Overview...................................................................7-97-4. Time Division Duplex in the GSM System...............................................................7-107-5. Signaling Multi-Frame .............................................................................................7-11C-1. Example of a Program Suspend .............................................................................. C-2

Tables

Table Title Page3-1. Die Area Comparison of Memory Technology ..........................................................3-43-2. Comparison of Flash and EEPROM .........................................................................3-43-3. Flash Memory Erase and Program Timings..............................................................3-63-4. EEPROM Data Parameters ....................................................................................3-133-5. Projected EEPROM Emulation Development Time ................................................3-164-1. Data Streaming Status Header Definitions ...............................................................4-85-1. Unit Header Structure Status Field Definitions........................................................5-145-2. Unit Header Structure Type Field Definitions ..........................................................5-145-3. Multiple Instance Structure Field Definitions ...........................................................5-165-4. Block Information Structure Status Field Definitions ...............................................5-186-1. TT_FileListRequired Source Code File Listing..........................................................6-67-1. GSM Parameter Storage Summary ..........................................................................7-7

E

11/3/98 10:35 AM REVHIST.DOC

INTEL CONFIDENTIAL(until publication date)

REVISION HISTORY

Date of Revision Version Description

March 1997 1.0 Original version

July 1997 1.0a Added Chapter 2, Getting StartedModified Chapter 4, Archtitecture and API SpecificationAdded Chapter 5, PortingModified Chapter 6, Test EnvironmentAdded Chapter 7, System Validation Test PlanModified Appendix D, License AgreementAdded Appendix E, Additional DocumentationOther minor text changes

November 1998 2.0 Overall improvements in consistency and accuracyChapters renumbered to accommodate additionsAdded Chapter 4, Data Streaming

Modified Chapter 5, Architecture and API Specification and Chapter 6Porting to reflect code changes for source release v1.5 and v2.0

Modified Chapter 8, System Validation Test and Plans for test flowchanges for source release v1.5 and v2.0

Moved Additional Information to Appendix B, Documentation andTechnical Support

Added Appendix E, Application Code Example

Version 2.0 of the FDI User’s Guide supports release 1.5 and 2.0 of the FDI code.

11/3/98 10:44 AM CHPT1.DOC


E1

Technical Overview

E

1-1

11/3/98 10:44 AM CHPT1.DOC


CHAPTER 1TECHNICAL OVERVIEW

Many personal communications devices (e.g., cellular telephones and pagers) have a need tostore both data and code. In the past, this problem had been solved using multiple memorydevices (Figure 1-1). Although viable, this approach is neither cost-effective nor sensitive tocritical power constraints. System integration is necessary not only to reduce cost and formfactor but also to foster product differentiation. Furthermore, consumer demand for ease-of-useand convenience is pushing data requirements to new levels. These factors, and others, havefueled the need for a monolithic flash memory device capable of simultaneous read while write(RWW) operation.

4 / 8 MbitR

®SRAM256Kb

EEPROM64Kb

CodeStorage

DataStorage

Mirrors EEPROM /System Variables

Figure 1-1. Typical Memory Subsystem in Today’s Designs

TECHNICAL OVERVIEW E

1-2

11/3/98 10:44 AM CHPT1.DOC


In an attempt to fulfill the needs of RWW, numerous hardware approaches are available today(see Figure 1-2). Some utilize special hardware, such as dual partition flash, which can providehigher performance at a higher cost (up to 20% higher than more common single partitionflash), but usually lack the flexibility to adapt as code and data needs change. Moreover, whenthese devices are used in a real-time operating environment, the flash device still needs to bemanaged since it is writeable on a byte basis, but erasable only on a block basis—and the real-time/multi-tasking access to the data must be handled.

With flash management in mind, a system-level analysis suggests there are other solutions—one which meets the code and data storage requirements and performance needs withoutrequiring the added cost of hardware RWW. This solution incorporates the management of“standard” single partition flash memory within a real-time environment. Intel’s Flash DataIntegrator (FDI) software provides the most cost-effective and flexible solution for code plusdata storage applications. The rest of this guide focuses on using single partition Intel® Flashwith FDI. But keep in mind, software is necessary to manage flash and code/data no matterwhat type of flash hardware is used.

Fast SuspendArchitecture

Partition A

Partition B8Mbit

SegmentedFlash Partitions

Dual-DieFlash

StandardArray4Mbit

StandardArray4Mbit

Flashplus EEPROM

StandardArray4Mbit

EEPROM256Kbit

StandardArray8Mbit

Rel

ativ

e C

ost

Co

mp

aris

on

Flexible Boundary Pre-defined Hardwired Boundary

FDI1-2

Figure 1-2. Relative Cost and Die Sizes of Differing Approaches toCode Plus Data Storage

E TECHNICAL OVERVIEW

1-3

11/3/98 10:44 AM CHPT1.DOC


The Flash Data Integrator (FDI) is a flash media manager that enables real-time code readsfrom flash while data writes are occurring. This is accomplished with a deterministic programand erase suspend (a feature available on most of Intel’s Flash memory products). If anapplication can manage a maximum 20 µs context switch latency, it can realize a code plus datastorage solution within a single flash memory device with FDI and standard flash—without theexpense of a hardware RWW flash device. FDI background flash management can be “held-off” during the execution of time-critical code segments.

A real-world, time-critical application was used as the initial application for FDI. The software,used with standard flash, was originally used to replace an EEPROM in a GSM cellular phoneapplication. Many other cellular and pager applications have subsequently used FDIsuccessfully. In the GSM situation, one of the more demanding applications for FDI, over 84%of the processing time is available for doing background flash management. So, for example, anerase operation that typically takes 1 second would take about 1.2 seconds during a call.

You may be thinking, “This sounds good, but how can I determine if FDI will work for me?”The next chapter, Getting Started, helps you navigate through all the FDI information. It willhelp you evaluate whether FDI meets your critical system requirements and how to beginadapting it to your needs.

11/3/98 10:44 AM CHPT2.DOC


E2

Getting Started

E

2-1

11/3/98 10:44 AM CHPT2.DOC


CHAPTER 2GETTING STARTED

This User’s Guide contains extensive information on FDI, and you may find yourself asking,“Do I have to read ALL of this?” The short answer is, “Yes, you probably do.” But, knowingwhat information is located should help you manage this task. Here is a list of the varioussections of this guide and when each might be most useful.

Section Title Description Stage Used

Chapter 1 Technical Overview Gives a brief overview andapplications of FDI

Evaluation

Chapter 2 Getting Started Document overview Evaluation, Development,Test, and Use

Chapter 3 EEPROM Replacementwith Flash Memory

A technical analysis of how FDIand standard flash can be used toreplace an EEPROM

Evaluation

Chapter 4 Data Streaming A technical analysis of how FDIcan be used to store data streamssuch as voice messages

Evaluation andDevelopment

Chapter 5 Architecture and APISpecification

The commands and structuresthat make up FDI


Chapter 6 Porting What it takes to adapt FDI to yourapplication

Development

Chapter 7 Test Environment Describes the test platform Intelused to emulate GSM cellularphone application

Evaluation and Test

Chapter 8 System Validation TestPlan

Describes the actual test plan andmethodology for QA and SV ofFDI

Evaluation and Test

Appendix A FAQs FDI “Frequently Asked Questions” Evaluation, Development,and Use

Appendix B Documentation andTechnical Support

Provides additional resourceinformation and lists the ways anFDI developer can get help fromIntel

Evaluation, Development,and Use

Appendix C System/Flash HardwareRequirements

Overview of the systemrequirements for implementing FDI


Appendix D License Agreement Details the legal obligationsconcerning FDI for both theimplementor (you) and Intel

Evaluation, Development,and Use

Appendix E Application ExampleCode

OEM application layer codeexamples

Development and Use

GETTING STARTED E

2-2

11/3/98 10:44 AM CHPT2.DOC


2.1 EVALUATIONThe first step to a full evaluation of FDI for your application is to determine and comprehendthe details of your specific application. The next two chapters, EEPROM Replacement withFlash Memory and Data Streaming, can help do this. Appendix C, System/Flash HardwareRequirements, will also help at this stage of your evaluation. With these guides, you candetermine where and how FDI will affect the specific critical areas in your application.

The next step of evaluation should be a quick review of Appendix A, FAQs, which will help toanswer a wide range of questions and concerns about FDI. The questions and answerscontained here are those that have been asked by customers evaluating FDI for their use.

Next, you should evaluate the impact FDI has on your software. Chapter 5, Architecture andAPI Specification details the software interface (or API) to the FDI code. The simple and easyFDI interface should be fairly straightforward to adapt to your software. The source code toFDI is provided as highly portable ‘C’ code for easy integration into your particulardevelopment environment.

The chapters on testing, Test Environment and System Validation Test Plan, detail the effortsand planning Intel uses to make sure the base code is robust and reliable.

E GETTING STARTED

2-3

11/3/98 10:44 AM CHPT2.DOC


FAQs

Architecture andAPI Specification

System/FlashHardware

Requirement

Test EnvironmentSystem Validation

Test Plan

EEPROMReplacement with

Flash Memory

Technical Overviewand Getting Started

Begin Evaluation

Data Streaming

Figure 2-1. Flowchart Indicating the Chapters That Are Useful during FDI Evaluation

GETTING STARTED E

2-4

11/3/98 10:44 AM CHPT2.DOC


2.2 DEVELOPMENTOnce you have evaluated FDI and determined that it meets your requirements, you willprobably want to get started with development. Chapter 6, Porting, was created to ease that taskas much as possible and will be your primary source of information for porting FDI. It detailsthe specific portions of FDI that require your attention such as the low-level flash interface.Additionally, it points out areas of concern for handling your special requirements. Familiaritywith Appendix A, FAQs and Appendix C, System/Flash Hardware Requirements will also behelpful.

Once FDI is ported to your application, the task of integrating it into your application softwarebegins. Chapter 5, FDI Architecture and API Specification, will be helpful at this stage. Mostapplications use FDI by having the application code call directly into FDI through the API.Other applications may wish to adapt the FDI API to the application operating system. The bestapproach should be determined by your software development team. The highly-adaptable FDIcode was designed to be flexible in these situations. Chapter 5 also includes numerousexamples of how to use the FDI API calls.

Throughout your development, access to Intel Technical Support may prove useful. AppendixB, Technical Support, details the availability of technical support for users of FDI.

Porting

Archtecture andAPI Specification

System/FlashHardware

Requirement

FAQs

TechnicalSupport

BeginDevelopment

Figure 2-2. Flowchart Indicating the Chapters That Are Useful during FDI Development

11/3/98 10:45 AM CHPT3.DOC


E3

EEPROMReplacement withFlash Memory

E

3-1

11/3/98 10:45 AM CHPT3.DOC


CHAPTER 3EEPROM REPLACEMENT WITH FLASH MEMORY

3.1 INTRODUCTIONFlash memory is used in a wide range of applications for embedded control code storage. Manyof these applications, including cellular phones, modems, automobile engine control and others,also use a separate EEPROM to store factory, system, and/or user data. With ever-increasingpressure to eliminate components and reduce system cost, designers are looking to use flashmemory to emulate EEPROM for simultaneous code and data storage.

Several years ago, Intel introduced an EEPROM emulation methodology based on linked datalist structures that was successful in applications such as automobile engine control. However,in time-synchronized applications like the cellular phone, the inability of flash memory to writeduring an erase suspend operation and the undeterministic maximum write and erase flashtiming may have prevented EEPROM emulation using standard flash components in certainmarket segments. Time-critical applications, such as cellular telephones, must service systeminterrupts by providing access to processor code stored in flash while simultaneously supportingdata writes to flash. For this reason, research has been undertaken by Intel and others to developa simultaneous read operation while writing or erasing another flash memory partition (block).Specialized components exist to support simultaneous read and write operations, but theytypically incur a percentage increase in silicon die area, and thereby cost more due to redundantcircuitry. Although specialized circuits enable simultaneous read-while-write (RWW)operation, the added cost tends to be less attractive in cost-critical, high-volume manufacturedapplications. Hardware-assisted suspend/resume circuitry with fast latency with standard flashoffers a technically-feasible approach to emulate simultaneous RWW operation with greaterflexibility, and without the cost impact of specialized circuits.

Regardless of the type of flash used, flash media management software is always required tomanage the larger flash memory block partitions. This is true, since flash memory cannot beerased on the byte level common to memory such as EEPROM, but must be erased on a blockgranularity. The development of a flash memory manager requires a keen understanding offlash technology and data management methods. Fortunately, Intel has designed the necessaryflash media manager, known as Flash Data Integrator (FDI), which handles variable lengthparameter storage, while utilizing hardware-assisted circuitry to emulate simultaneous codeexecution. FDI also handles power loss recovery in the case of battery removal during datastorage, providing a reliable EEPROM replacement.

This chapter describes the hardware and software architecture necessary to emulate EEPROMmemory in flash. Section 3.2 reviews the fundamentals of flash and EEPROM technology.Critical timing parameters and hardware limitations are examined, along with a description ofthe hardware suspend to read/write capabilities common to many standard flash architectures.The software architecture for EEPROM emulation in flash memory is reviewed in Section 3.3.

EEPROM REPLACEMENT WITH FLASH MEMORY E

3-2

11/3/98 10:45 AM CHPT3.DOC


The software modules and features are also discussed in Section 3.3. Resource and systemrequirements are presented in Sections 3.4 and 3.5, respectively. Parameter cycling ischaracterized in Section 3.6, and power loss recovery techniques are described in Section 3.7.

3.2 MEMORY FUNDAMENTALS

3.2.1 Memory ArchitectureFlash memory technology offers the electrical erasability of random access memory (RAM),and nonvolatility of read only memory (ROM) to retain information after power is removed.Unlike RAM, flash cannot be erased on a byte basis. Flash memory supports writing(programming), the processes of changing a logic “1” to a “0,” on a byte or word [double byte]basis. Certain flash memory components, including those from Intel, have the added capabilityto be programmed one bit (or multiple bits) at a time.

Erasing flash is the process of changing a logical “0” to a “1” on a block-by-block basis.Physical block partitioning is set by a fixed address range of the component (see Figure 3-1).Typical block sizes range from 8 Kbytes to 64 Kbytes for parameter and main blocks,respectively.

Flash memory stores data as charge on the floating gate of a single transistor as compared toother memory types that require additional components to hold a charge or the state of a latchcircuit. As a result, flash has significant silicon area and cost advantages when compared withother memory types (see Table 3-1), offering a cost-effective means of storing data.

3.2.2 Program/Erase TimingEEPROM supports byte alterability by rewriting a page, typically 16, 32 or 64 bytes. Thesystem must wait 10 ms to allow time for the data to be written to the EEPROM cell in thebackground. This limits EEPROM write times from 157 µs to 625 µs/byte or 12.5 Kb/s to49.7 Kb/s. Flash memory, on the other hand, supports data writes at a continuous 17 µs/byte(22 µs/word) typical 2.7 V program time in the foreground, thereby supporting data write ratesup to 710 Kb/s and reducing the amount of time a system spends writing data from 93% to98%. Continuous data programming is essential for streaming data packets such as shortmessage service (SMS), fax, or digitized voice recording. This analysis also doesn’t account forany overhead time lost rewriting an entire page in EEPROM when only a single byte update isrequired—providing even a further reduction in data write time overhead.

E EEPROM REPLACEMENT WITH FLASH MEMORY

3-3

11/3/98 10:45 AM CHPT3.DOC


Unlike flash, EEPROM does not require a block erase operation to free up space before datacan be rewritten. This means that some form of software management is required to store datain flash. However, EEPROM technology is also limited to a maximum number of data writes[cycles] between 10,000 and 100,000. Flash memory, on the other hand, does not experience adevice cycle until the block is erased. This means flash improves cycling reliability on the orderof thousands of times better than EEPROM technology. The details of parameter cycling arediscussed in Section 3.6.

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

8-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

64-Kbyte Block

FlashFile™ Memory Architecture Boot Block ArchitectureFDI2-1

Figure 3-1. Intel’s Flash Memory Architectures


3-4

11/3/98 10:45 AM CHPT3.DOC


Table 3-2 compares the timing specifications of flash and EEPROM memory. Although thewrite performance of flash technology is fast compared to EEPROM, it is important to considermaximum program time. The time it takes to reliably store charge on the floating gate in flashmemory is a function of process variation, temperature, voltage, and electron storagesusceptibility. Under worst case conditions it may take as long as 165 µs to store a byte (200 µsfor a word), as given by the specification tWHQV1 and tWHQV2, respectively (see Table 3-3). Themaximum time, however, does not occur across each of the flash cells, and is only realized in asingle or few cells within a given address range. When writing a single byte or word, oneshould account for this maximum time tWHQV1 and tWHQV2, respectively. However, when writinga page of data to flash memory the maximum write time is dependent on the page size and isgiven by the graph in Figure 3-2.

The erase time of the flash parameter and main blocks are given by the specification tWHQV3 andtWHQV4, respectively (see Table 3-3). The distribution of erase time is similar to that of writetimes and are dependent on operating conditions and cycling. Erase times remain semi-constantfor erase cycles less than 10,000. Above 10,000 cycles, the erase time increases as illustrated inFigure 3-3. The manufacturer’s specified cycling parameter is based on a given erase andprogram time. Flash can be reliably cycled beyond the specified value provided the designaccommodates an increase in the erase and program time. For example, a flash device withspecified 10K erase cycles can operate with 100K cycles with a typical erase time of 1.5 sec.

Fortunately, engineers need not design systems to wait the maximum specified values. Instead,flash components commonly contain internal status registers that indicate when a program orerase operation is complete. By polling the internal register, the designer can determine whenan operation is completed and the memory is available for another operation such as read.

Table 3-1. Die Area Comparison of Memory Technology

Features Flash DRAM EEPROM SRAM

Cell Components 1 Transistor 1 Transistor +1 Capacitor

2 Transistor 4 Transistor +2 Resistor

Cell Area (µm2)[0.4µ lithography]

2.0 3.2 4.2 22

Chip Area (mm2)(16-Mbit density)

61 98 107 59(1-Mbit Density)

Read Speed (ns) 80 (5 V)120 (3 V)

60 150 <60

Table 3-2. Comparison of Flash and EEPROM

Features Flash EEPROM

Write Time (Typical) 10 µs / Byte (5 V)17 µs / Byte (3 V)

10 ms / 16, 32 or 64 Byte Page[157–625 µs/Byte]

Erase Time (Typical) 450 ms/8-KB Block (5 V)500 ms/8-KB Block (3 V)

NA

Internal Program/EraseVoltage

5 V/12 V (PSE)5 V/–10 V (NGE)

5 V/12 V

Cycling 10K–100K Erase Cycle/Block10K–300M Write Cycle/Byte1

10K–100K Write Cycle/Byte

NOTE: 1. See Section 3.6.


3-5

11/3/98 3:19 PM CHPT3.DOC


0

5

10

15

20

25

30

0 50 100 150 200 250 300 350 400

Page Size (bytes)

Max

imum

Writ

e T

ime

(ms)

Byte Write

Word Write

FDI3-2

Figure 3-2. Maximum Write Timing(VCC = VPP = 2.7 V–3.6 V, TA = –40 °C to +85 °C, 10K Cycles)

0

0.5

1

1.5

2

2.5

3

10 100

1000

1000

0

1000

00

1000

000

Number of Erase Cycles

Era

se T

ime

(sec

)

8-KB Parameter Block

64-KB Main Block

FDI3-3

Figure 3-3. Cycling Effects on Erase Time(VCC = VPP = 2.7 V–3.6 V, TA = –40 °C to +85 °C)


3-6

11/3/98 10:45 AM CHPT3.DOC


Table 3-3. Flash Memory Erase and Program Timings(1,2)

VPP = 2.7 V VPP = 12 V

Sym Parameter Notes Typ3 Max4 Typ3 Max4 Unit

tWHQV1tEHQV1

Word Program Time 5 22 200 8 185 µs

tWHQV2tEHQV2

Byte Program Time 5 17 165 8 185 µs

tBWPB1 Block Program Time (Word)(Parameter)

5 0.10 0.30 0.03 0.12 sec

tBWPB1 Block Program Time (Byte)(Parameter)

5 0.16 0.48 0.08 0.24 sec

tBWMB2 Block Program Time (Word) (Main) 5 0.80 2.40 0.24 0.80 sec

tBWMB2 Block Program Time (Byte) (Main) 5 1.2 3.7 0. 6 1.7 sec

tWHQV3tEHQV3

Block Erase Time (Parameter) 5 0.5 4 0.4 4 sec

tWHQV4tEHQV4

Block Erase Time (Main) 5 1.0 5 0.6 5 sec

tWHRH1tEHRH1

Word/Byte Program SuspendLatency Time to Read

5 10 5 10 µs

tWHRH2tEHRH2

Erase Suspend Latency Time toRead

5 20 5 20 µs

NOTES:

1. These performance numbers are valid for all speed versions.

2. Characterized but not 100% tested.

3. Typical values measured at TA = +25°C and nominal voltages.

4. Maximum values are based on typical process skews.

5. Excludes external system-level overhead.

3.2.3 Specialized Flash RWW CircuitsMost currently available flash technology must complete a program or erase operation beforecode can be read from another memory block. Based on the maximum program/erase timingspecifications of flash, there is a common misconception that EEPROM emulation can besupported only when the application can mask interrupts and allow a write or erase operation tocomplete. In time-synchronized applications with maximum latencies in the range ofmicroseconds, such as a cellular phone, simultaneous operation may be difficult without someform of hardware or software assistance.


3-7

11/3/98 10:45 AM CHPT3.DOC


Many approaches to hardware assisted read-while-write (RWW) operation have been proposedfor flash architecture (see Figure 3-4). One approach is to segment the standard memory arrayinto separate physical partitions by duplicating the row and column (x/y) decoders, senseamplifiers and charge pump circuits—adding 12% to 17% to the silicon die area, andcomponent cost. This form of hardware-assisted flash memory allows code to be read from onememory block, while a program or erase operation executes simultaneously in another block inthe opposite physical partition. However, if the code being executed needs to access data in theother partition, a program or erase will need to be suspended using media management software

Simultaneous read with background program/erase has higher peak power dissipation, but thetotal energy may be the same as the standard architecture. Segmented flash partitions furtherrequire that the data and code fit completely within the fixed partitions—making the selectionof the partition size critical. If either code or data requirements exceed the maximum partitionlimit then simultaneous operation is no longer possible when data and code reside in the samepartition, and the maximum suspend latency timing of the component must be considered.Although this method may be attractive for EEPROM emulation, it does not offer the flexibilityto support growing data needs.

On the other hand, a segmented architecture does minimize program/erase to read latency. Thisreduces the effect on system timing and may reduce testing if the design is time-critical.

An alternative approach is based on packaging two standard flash die into a single “dual-die”package. The “dual-die” approach supports simultaneous operation between the two die withthe added flexibility that the size of the data or code partition can be changed to meet the needsof the application. Unfortunately, total peak memory system power is twice the power of asingle standard flash component. Dual-die packaging, or two separate flash components, maybe attractive when the data requirements exceed 2 Mbits to 4 Mbits (256 KB to 512 KB).EEPROM emulation alone requires far less parameter storage needs, 8 Kbytes to 32 Kbytes,making a dual-die solution less cost-attractive.

A third approach to RWW is to combine EEPROM technology onto a two-transistor (2T) flashmemory process. This approach eliminates the need for media management software, but hasthe disadvantage of increased memory system power and cost. Memory power dissipation canbe as high as 200 mW compared to standard flash memory at 60 mW. The increase in die areanecessary to support both memory technologies has an adverse impact on die yield and in turnproduct cost.

Yet another approach to hardware assistance is enhanced suspend circuits that allowprogram/erase operations to be suspended temporarily to read code from another partition.Suspend circuits allow time critical operations to be serviced without stalling themicroprocessor (CPU). Unlike the other specialized RWW approaches, suspend circuits do notplace limits on the code/data partition size, thereby increasing the flexibility and offeringsupport as data storage needs grow. Suspend circuits do not increase the flash die size (cost),nor do they increase memory system power. The following section describes the suspend-resume operation in more detail.


3-8

11/3/98 10:45 AM CHPT3.DOC


Fast Suspend

Architecture

Partition A

Partition B8 Mbit

Segmented

Flash Partitions

Dual-Die

Flash

StandardArray4 Mbit

StandardArray4 Mbit

Flash

plus EEPROM

StandardArray4 Mbit

EEPROM256 Kbit

StandardArray8 Mbit

Rel

ativ

e C

ost

Co

mp

aris

on

Flexible Boundary Pre-Defined Hardwired Boundary

FDI3-4

Figure 3-4. Comparison of Standard andSpecialized Flash Memory Architectures for RWW

3.2.4 Hardware Assisted Suspend to Read/WriteMany Intel Flash components include two suspend commands; Program and Erase Suspend.Program and erase suspend mode allows system software to suspend both the word/byteprogram or block erase command in order to read from or write data to another block.Commands are written to the Command User Interface (CUI), connecting the microprocessorand the internal chip controller, using standard microprocessor write timings. Issuing a programor erase suspend command will begin to suspend a program/erase operation. The flash internalstatus register will indicate when the device reaches program/erase suspend mode. In this mode,the CUI will respond only to the Read Array, Read Status Register, Program, Program Resume,and Erase Resume commands. Flash specification tWHRH1 and tWHRH2 define the program anderase suspend latency, respectively (Table 3-3).

After a Program or Erase Resume is written to the flash memory, the flash device will continuewith the program or erase process, respectively, (see Figures 3-5 and 3-6). The flash continuesfrom the point where the suspend command was issued, eliminating the need to repeat theprogram or erase operation. The delay to read or write is less than the maximum suspendlatency of the flash memory. This allows the system designer to emulate simultaneous read andwrite operations.


3-9

11/3/98 10:45 AM CHPT3.DOC


Start

Write B0H

Read Status Register

Bus Operation

Write

Write

No

Command

Program Suspend

Read Array

Comments

Data = B0HAddr = X

Data = FFHAddr = X

SR.7 =

SR.2 =

1

Write FFH

Read Array Data

Program Completed

DoneReading

Yes

Write FFHWrite D0H

Program Resumed Read Array Data

0

1

0

ReadRead array data from blockother than the one beingprogrammed.

Read

Status Register Data ToggleCE# or OE# to Update StatusRegister DataAddr = X

StandbyCheck SR.71 = WSM Ready0 = WSM Busy

StandbyCheck SR.21 = Program Suspended0 = Program Completed

Write Program ResumeData = D0HAddr = X

FDI3-5

Figure 3-5. Program Suspend/Resume Flowchart


3-10

11/3/98 10:45 AM CHPT3.DOC


SR.7 =0

1

Start

Write B0H

Read Status Register

Write D0H

Block Erase Resumed

BusOperation

Command Comments

Write EraseSuspend

Read

Data = B0HAddr = X

Check SR.71 = WSM Ready0 = WSM Busy

Status Register DataAddr = X

Standby

SR.6 = Block Erase Completed

Write FFH

Read Array Data

Yes

0

1

Check SR.61 = Block Erase Suspended0 = Block Erase Completed

Standby

Data = D0HAddr = X

Write Erase Resume

Read orProgram

?

Done?

ProgramLoop

Read ArrayData

Read Program

No

FDI3-6

Figure 3-6. Block Erase Suspend/Resume Flowchart


3-11

11/3/98 10:45 AM CHPT3.DOC


3.3 FLASH DATA INTEGRATOR SOFTWARE STRUCTURESoftware is required to make all flash memory components, regardless of RWW circuitry,emulate an EEPROM. The approach of storing data on a nonvolatile media is well understood,but intricate due to the need to overcome the conditions described previously.

Intel has developed an open software architecture, known as the Flash Data Integrator (FDI),that enhances the flash technology. FDI allows the system designer to use a single low-costflash memory component as a storage medium for both system code and data in real-timesystems. This section describes the FDI flash media management software and reviews basicflash data management techniques.

3.3.1 Flash Data Integrator Functional OverviewThe FDI architecture consists of three major subsystems; the Foreground ApplicationProgramming Interface (API), Background Manager, and Reclaim Task.

System tasks and interrupts that need to store data interface to the Foreground API functions.Through the API interface, commands that modify flash and their corresponding data arequeued by the system. The API commands such as Open, Close, Read, Write, and Query arethe interface between FDI and the system. The Background Manager readscommands/parameters from the queue, determines where the information should be stored, andperforms any parameter storage while monitoring for interrupts. The Reclaim Task, wheninitiated by the Background Manager, performs any clean-up tasks necessary.

Figure 3-7 illustrates the information flow between the system flash memory and SRAM. Thesystem calls the Foreground API function (0), with a command and data. The API functioneither queues the command and data into SRAM for operations which modify flash (1W), orexecutes the command directly for commands which do not modify flash (1R). The FDIBackground Manager (2W), executing out of flash memory, manages the queued tasks duringavailable processor time. During a flash program or erase operation (4W), interrupts withvectors in flash are disabled and control is turned over to a small routine (less than 1 Kbyte) inSRAM (3W). This routine polls interrupts while monitoring progress of the program or eraseoperation. If a higher priority interrupt occurs, the polling routine suspends the flash memoryprogram or erase operation, and allows the interrupt handler to then execute directly from flashmemory. Upon completion of the interrupt routine, the flash program or erase operation isresumed by the SRAM polling routine. The Background Manager or Reclaim Task continues inthis fashion until all events are handled and all necessary cleanup is complete.

A complete description of the FDI subsystems is provided in Chapter 5, Architecture and APISpecification.


3-12

11/3/98 10:45 AM CHPT3.DOC


(2R) DataQueues<1 Kbyte

(3W) FlashProgram/

EraseControl &InterruptPolling

<1 Kbyte

(1W) Foreground API:write, delete

Foreground API:read, close

(2W) BackgroundManager: write,

delete

Spare

Factory DataUser Data

Net ParamsBoot Code

(4W)

Total = 2 KB - 3 KB

SRAM Flash

FlashMemory

DataBlocks

Tot

al =

16

KB

-20

KB

(0) Data to BeRead/Stored

(1R)

Reclaim Task init.

FDI3-7

NOTE:

R = Read, W = Write

Figure 3-7. FDI Information Flow between Flash and SRAM Memory

3.3.2 EEPROM Parameter TypesParameters stored in the EEPROM in a cellular phone can be characterized as either factory,network or end-user data. These parameter records vary in size and frequency of updates. Forexample, factory tuning data may be a long record (few hundred bytes) that is written to theEEPROM during the manufacturing process and may only be updated on an infrequent basiswhen the user brings the phone into a service center. On the other hand, the call timerparameter keeps track of the duration of a call and may be updated as often as every coupleseconds during the process of the call. Table 3-4 lists the data parameter types commonly storedin the EEPROM of a cellular phone.

The frequency of parameter updates determines how often parameter blocks must be cleaned up(erased), to ensure free space is always available in flash for data writes. The write occurrencecombined with the system time allocated for flash management and the timing parameters of


3-13

11/3/98 10:45 AM CHPT3.DOC


the flash memory should be evaluated. Based on the low data write rate of cellular phoneEEPROM data, flash memory with hardware assisted suspend/resume circuitry provides morethan adequate timing to emulate an EEPROM and respond to system interrupts. It is feasible tomanage all flash memory program and erase operations during normal phone operation (e.g.,during “dead” time while on a control channel or during a phone call). This maximizes the timethe CPU remains in sleep mode.

Table 3-4. EEPROM Data Parameters

ParameterType

Size (Bytes) Number ofParameters

Amount(Bytes)

Occurrence

Factory 1–300 <10 ∼1,024 1–2 times/year

Network 5–20 25–50 ∼1,024 < few times/day

End-User 20–250 30–250 ∼6,144 Every few seconds during call

3.3.3 Parameter Storage and ManagementUnlike EEPROM, flash memory cannot be erased on a byte basis. By using softwaremanagement techniques, data can be stored on a byte or variable length basis and flash eraseoperations can be completed using a suspend command to emulate byte alterability.

Data parameters are stored and tracked by software as virtual units within the physicalboundaries of the flash block (see Figure 3-8). This is required whether specialized RWWcircuits are available or not. Since a byte in flash may not be overwritten, an old occurrence ofa parameter is marked “dirty” when the parameter is updated. The valid parameter is written tothe next available memory location. The software media manager tracks the valid occurrencesand controls access when requested by the system.

Parameters are stored until there is not enough “clean” space available in the block to insurenew records can be written without overflowing the block. When this point is reached, the latestoccurrence of each parameter is transferred to a clean (erased) block. Block header recordsassociated with each parameter block indicates the status of the block, i.e, information such asif the block is active (containing valid data), if the block is transferring data, or if the block iserased. After the valid parameters are transferred, the original block is marked for reclaim(erasing). The parameter storage and management process is handled fully by FDI, and may besuspended by the system to write data provided free space is available.


3-14

11/3/98 10:45 AM CHPT3.DOC


Valid

Clean

Dirty

n Bytes

FlashBlock

VirtualUnit

FDI3-8

Figure 3-8. Flash Media Manager

3.3.4 Read LatencyUnlike previous EEPROM emulation techniques that were based on a linked list approach, FDIuses a look-up pointer to the parameter header to access the data. This provides uniform latencyand simplifies system timing issues. (See AP-604 Using Intel’s Boot Block Flash MemoryParameter Blocks to Replace EEPROM.)

3.3.5 Real Time Interrupt SupportTo support real time interrupts, the flash management operations are suspended beforeservicing an interrupt. Upon completion of the interrupt routine, the flash operation is resumeduntil complete.

During a flash program or erase operation, a system interrupt hardware register is polled whilewaiting for the flash command to complete. If an interrupt occurs, the program or eraseoperation is suspended, FDI monitors the flash status and re-enables the system interrupt assoon as the flash is ready. The system interrupt then executes directly from the flash memory.The latency to interrupt execution is no longer than the maximum suspend latency of the flashmemory component (10 µs for program or 20 µs for erase in the case of Intel’s Boot Block


3-15

11/3/98 10:45 AM CHPT3.DOC


flash). This eliminates the need to store interrupt handlers in SRAM. Upon completion of theinterrupt, control is returned to flash program/erase routine to resume the operation.

Since non-specialized RWW flash components cannot be read from during a program or eraseoperation, a small (less than 1 Kbyte) software handler in the system’s static RAM (SRAM) isrequired. The SRAM and other system requirements are described in Section 3.5.

3.3.6 FDI Features• Ability to easily integrate data and code into a variety of real-time environments. The areas

of code that require porting are limited and the code does not depend on the existence ofnon-ANSI ‘C’ libraries.

• Ability to suspend all data management activity when requested to execute code.

• Ability to resume data management activity following code execution.

• Ability to migrate the SW developed for standard flash architecture with hardwaresuspend/resume capability to flash components that support specialized RWW circuitry.

• Ability to support all EEPROM data storage requirements as well as data streams(discussed in Chapter 4) and other advanced data storage needs.

• Low latency parameter/file read access.

• Support for variable parameter sizes without large overhead in media.

• Extensive power-loss recovery capabilities. An unexpected power loss should nevercorrupt or lose data. Replacement of old data with new should always provide the old dataas a back-up until the new data can be guaranteed.

• Supports symmetrical block sizes through a portion of the flash component, but allows theblock size to be definable at compile time.

• Flexible through use of defines, compile time options, or parameter options.

3.4 DEVELOPMENT RESOURCESAlthough basic flash data management techniques may be well understood by the systemsoftware engineer, the work necessary to develop a reliable system takes significant time andresources. This effort has delayed many OEMs from fully emulating the EEPROM in flash.Fortunately, Intel’s FDI solution greatly reduces the OEM’s development effort.

Table 3-5 provides an estimate of the development resources required to integrate Intel’s FDIinto an existing system compared to developing an internal media manager for a flash memorycomponent using a specialized RWW flash component. Intel’s FDI may reduce thedevelopment time, thus allowing the OEM to bring the product to market faster.


3-16

11/3/98 10:45 AM CHPT3.DOC


Table 3-5. Projected EEPROM Emulation Development Time

Feature Intel FDI Internal MediaManager

FDI Definition included 2400 devl.-hours

Flash Parameter Storage Management included 3000 devl.-hours

Flash Storage Management Reclaim included 3000 devl.-hours

EEPROM Interface included 450 devl.-hours

Power Loss Recovery included 2350 devl.-hours

Flash Suspend/Resume Interface and Testing included N/A

API Integration 400 devl.-hours N/A

Total 400 devl.-hours 11,200 devl.-hours

3.5 SYSTEM REQUIREMENTS

3.5.1 Random Access Memory RequirementsSome amount of system RAM (SRAM) is required to provide instructions and a data queueduring flash program and erase operation. The amount of RAM usage is dependent on thespecific features needed. The size of this area is expected to be 2 Kbyte—1 Kbyte for queuestorage and less than 1 Kbyte for code. RAM should be used for queuing of events/data. Thegoal is to create a modular set of reference code, where the cellular phone OEM can pick andchoose the various features needed in their product, and thus tailor the software to their specificproduct needs. Flash memory with specialized RWW still needs RAM for data queue, but doesnot require the 1 K of code space.

3.5.2 Flash Memory RequirementsFlash memory space will be necessary to store the Foreground, Background, and Reclaim Taskprogram code. This is required for all flash memory types, standard and specialized. Intel’s FDImedia manager requires 20 Kbytes to 40 Kbytes of flash memory, depending on which featuresare enabled.

In addition, the flash memory component must include program and erase suspend commands(such as those in Intel’s Boot Block components). This is true even for specialized RWWcomponents, as executing code may need to read data from the data partition at any time (e.g.,when a block is being erased).


3-17

11/3/98 10:45 AM CHPT3.DOC


3.6 PARAMETER CYCLINGIntel’s flash memory is specified to work over 100,000 erase cycles when operating overextended temperature range of –40 °C to +85 °C.

A cycle is defined as an erase operation, not the number of data writes the device can support.For example, an 8-Kbyte block supports 8,192 byte writes before a single erase operation (onecycle) has completed. Therefore, parameter cycling is a function of the parameter size. This isimportant when determining how many parameter updates can be supported. Today, manyOEMs limit writes to EEPROM due to 100K write cycling limit of EEPROM technology.Parameter updates in EEPROM over write the previous instance. The maximum life of theEEPROM is thereby limited to the update rate of the most frequently written parameter (e.g.,call timer in the case of a digital cellular phone). Using flash for EEPROM emulation extendsthe effective number of data cycles.

The effective number of write cycles is dependent on the number of available parameter blocksand size of the parameter record and is given by:

Eff Write Cycles

available bytes block x no blocks

parameter record sizexMax erase cycles block

.

/ .. /

=

Assuming two 8-KB flash blocks are used to store a 5-byte record over an extendedtemperature range, and further assuming 5 Bytes/block status and 512 Bytes/block overheadresults in:

Eff Write Cycles

Bytes blk x Blks

Bytes parameterx cycles blk

.

( , / )

/, /

, ,

=− −

=

8 192 5 512 2

5100 000

307 000 000

This is a 3000 times improvement over EEPROM memory that is limited to 100,000 writecycles. The same approach works for variable size records, where the effective write cycles aredetermined by the summation of the occurrences of the various records.


3-18

11/3/98 10:45 AM CHPT3.DOC


3.7 POWER LOSS RECOVERYPower loss is handled in a reliable manner by adding a status field to the header of each dataparameter block, as well as each parameter. The status field indicates that a parameter updatehas been initiated or the write was complete. If power is lost during a parameter update, thestatus is known when power is restored. Upon power recovery, the initiation process shouldcheck the status of each parameter. If the status indicates that a parameter update began but didnot complete successfully, then the record can be marked invalid. The same process is usedduring clean-up operations when valid data is moved to a clean block. Because of the fast writecapability of flash, critical parameters can be stored to flash sooner than an EEPROMcomponent, thereby improving the robustness of the system.

3.8 CONCLUSIONSpecialized RWW flash architectures with fixed size data partitions are limited in their abilityto manage data that exceeds the partition size. Intel’s FDI software is designed to manage amultiple number of memory blocks, offering a more flexible solution when combined with acomponent that is not limited by a physical partition, such as the Intel’s Boot Block Flashmemory. FDI reduces system cost, improves system write times by as much as 98%, supportsdata write rates up to 710 Kb/s, reduces memory system power by as much as 140 mW(compared with specialized RWW components), greatly reduces development time and canincrease parameter cycling better than 300 times over EEPROM memory. Power loss recoverytechniques ensure data is not lost or corrupted in the event of power loss, eliminating the needfor battery backed SRAM. EEPROM emulation in flash requires limited system resourcesdepending on the needs and selected flash technology. Intel’s FDI flash media managementsoftware and Boot Block flash memory offer a cost-effective, robust, reliable, and flexiblesolution to EEPROM replacement.

11/3/98 10:46 AM CHPT4.DOC


E4

Data Streaming

E

4-1

11/3/98 10:46 AM CHPT4.DOC


CHAPTER 4DATA STREAMING

4.1 INTRODUCTIONData streaming is a method of storing data that can enrich the feature set of an application.Implemented correctly, data streaming allows for large amounts of data to be stored in thememory subsystem. Using FDI, flash, and RAM, applications can store data streams (streams)to flash while executing application code from the same flash device.

This chapter covers the differences between parameters and streams, how to effectively useFDI’s APIs to implement data streaming, and how to deal with power loss recovery issues.

4.2 STREAMS vs. PARAMETERSA stream is frequently defined as an undefined amount of data continuously arriving at aregular rate (#bytes/second). Examples of streams include voice mail, faxes, email, and/orphone books. Parameters are commonly defined as fixed-size data. Examples of parametersinclude call timers, phone numbers, and OEM-specific information.

From an API usage perspective, a parameter is defined as type 0 in the command controlstructure (see Figure 4-1, Command Control Structure and Figure 4-2, Parameter and StreamTypes) and a stream may be type 1 through n in the command control structure. Please see thecommand control structure definitions in Chapter 5, Architecture and API Specification formore details on this type field.

DATA STREAMING E

4-2

11/3/98 10:46 AM CHPT4.DOC


typedef struct {

buffer_ptr;

count;

offset;

aux;

actual;

identifier;

type;

priority;

sub_command;

reserved

/* buffer address */

/* number of bytes desired */

/* beginning offset into the data */

/* supplementary field */

/* number of actual bytes acted on */

/* unique identifier for each data or code */

/* command type: either data or code type */

/* each identifier is assigned a priority*/

/* subcommand to expand functionality */

/* padded for DWORD alignment */

BYTE_PTR

DWORD

DWORD

DWORD

WORD

WORD

BYTE

BYTE

BYTE

BYTE

} COMMAND_CONTROL;

Figure 4-1. Command Control Structure

parameter 1parameter 2parameter 3parameter 4parameter 5parameter 6

voice mail 1voice mail 2voice mail 3voice mail 4

fax 1fax 2

email 1email 2email 3email 4email 5

Type 1Type 0 Type 2 Type 3

data stream 1data stream 2

Type N

parameters data streams

Figure 4-2. Parameter and Stream Types

Type affects how FDI handles information. For instance, while the limit to the number ofstreams or parameters in an application is 64 K, FDI allows only one stream/parameter to beopen at a time. Opening streams improves read/write performance (see Section 4.3,Implementing Data Streaming in an Application for further details). Other parameters and/orstreams may be read or written while the stream is open. In the following example, a voice mailstream is opened and recording begins. During the recording, other parameters and/or streamsmay be read or written, however the voice mail is the only stream that may be open until it isclosed. Another stream may be opened after the voice mail is closed (see Figure 4-3, ExampleShowing Only One Stream Open at a Time).

E DATA STREAMING

4-3

11/3/98 10:46 AM CHPT4.DOC


opendata stream(voice mail)

start recordingvoice mail

read/writeother parameters/

data streams

continuerecording voice

mail

closevoice mail

Voice mail is theonly data streamthat may be open

Another data streammay now be opened

Time

7897_03

Figure 4-3. Example Showing Only One Stream Open at a Time

When retrieving data, subcommands in the FDI_Get function allow an application to locate thefirst stream or the next stream for a certain type. The unique identifier and size returned by theFDI_Get command can then be used in the FDI_Read command to retrieve the stream.

These retrieval features can be implemented if different types of streams are defined asdifferent types within the application. For example, if an application contains faxes, email, andvoice mail, the following steps can be taken to retrieve all voice mail efficiently (if all voicemail is defined as one type, all faxes as another type, etc.):

1. Locate the first voice mail with the FDI_Get API (Get_First as the subcommand). This willreturn the identifier and size of the stream.

2. Read the first voice mail with FDI_Read. Inputs to FDI_Read are from the output of thefirst step.

3. Locate the next voice mail with the FDI_Get API (Get_Next as the subcommand). Thiswill return the identifier and size of the stream.

4. Read the voice mail located in Step 3 with FDI_Read. Inputs to FDI_Read are from theoutput of the Step 3.

5. Repeat Steps 3 and 4 until all voice mails have been retrieved at which time FDI_Get willreturn ERR_NOT_EXISTS.

Figure 4-4, Locating Data with Get_First and Get_Next, illustrates this concept.

DATA STREAMING E

4-4

11/3/98 10:46 AM CHPT4.DOC


fax

email

voice mail

Get_First

Get_Next

Get_Next

Flash

7897_04

Figure 4-4. Retrieving Data with Get_First and GET_Next

4.3 IMPLEMENTING DATA STREAMING IN AN APPLICATIONData streams must be written efficiently to improve access to the flash and thus improve systemperformance. To write the stream efficiently, the stream must first be opened using FDI_Openotherwise acceptable data rates may be unattainable. Figure 4-5, Data Streaming Methodology,illustrates a methodology to implement data streaming recording which optimizes efficiency.

FDI_Open improves the performance when accessing a stream by maintaining open streaminformation in RAM. This open information eliminates the need for FDI_Write and FDI_ReadAPIs to call supporting functions to determine basic file information, enabling the stream to bewritten more efficiently.

Reserving space in flash and then writing data to the reserved space further eliminates the needto update information. Reserving space is accomplished through the subcommandWrite_Reserved in the FDI_Write API. This is a new feature that has been added to improvedata streaming. Writing data is accomplished through the subcommand Write_Modify in theFDI_Write API.

E DATA STREAMING

4-5

11/3/98 10:46 AM CHPT4.DOC


Without reserving space in flash and then writing new data to the reserved space, theapplication will need to use the Write_Append subcommand in the FDI_Write API. UsingWrite_Append reduces efficiency by copying the existing data within the fragment to a newlocation and then writing the new data (i.e., the preceding data written to the fragment needs tobe copied in subsequent data writes). See Figure 4-6, Data Streaming without Reserved Spacefor an illustration. A data fragment is defined as contiguous memory with a size in multiples ofunit granularities. The number of granularities is defined in the compile time optionMAX_NUM_UNITS_PER_FRAG in Type.h.

opendata stream

reserve spacein flash

write data

data streamcompleted?

reservespace full

closedata stream

No

No

Yes

Yes

7897_05

Figure 4-5. Data Streaming Methodology

DATA STREAMING E

4-6

11/3/98 10:46 AM CHPT4.DOC


Fragment #1

Data Unit 1

Fragment #2

Data Unit 1 Data Unit 2

Fragment #3


Data Unit 3

First Data Write Second Data Write Third Data Write

Data Written into New FragmentData Written Data Written into New Fragment

7897_06

Figure 4-6. Data Streaming without Reserved Space(Using Write_Append)

By reserving space and writing to the fragment, previous writes do not need to be copied (seeFigure 4-7, Data Streaming with Reserved Space).

Fragment #1(reserved space)

Data Unit 1





Data Unit 3

First Data Write Second Data Write Third Data Write

Data Written into Existing FragmentData Written Data Written into Existing Fragment

7897_07

NOTE:

Same fragment

Figure 4-7. Data Streaming with Reserved Space(Using Write_Reserved and Write_Modify)

E DATA STREAMING

4-7

11/3/98 10:46 AM CHPT4.DOC


The recommended amount of space to reserve is equal to the size of a data fragment. A datafragment size is defined as the UNIT_GRANULARITY size multiplied by theMAX_NUM_UNIT_PER_FRAG. Both UNIT_GRANULARITY and MAX_NUM_UNIT_PER_FRAG are defined in header files. Data written to this reserved space should be inamounts that maximize the fragment usage thus minimizing overhead. For example, if a 256-byte fragment is written to in 32-byte increments, eight increments may be written.

Finally, FDI_Close closes the stream to allow other streams to be opened for writing.

4.3.1 Sample CodeSample code, for implementing a data streaming type application, is provided with the FDIsource. Please see the “\Sample\Datastrm\” directory in the source for functional codeexamples.

4.4 CORRECTLY IMPLEMENTING POWER LOSS RECOVERYData streaming brings special power loss recovery considerations. FDI implements power lossrecovery for parameters and the reserved fragment in which a stream is being written, howeverit is not implemented for the data increments within the fragment. Since the data stream format(for power loss recovery) is application specific, these considerations need to be taken intoaccount by the OEM.

4.4.1 Tracking Valid Data and Empty SpaceThe first consideration is to track valid and empty data within a reserved fragment. Forexample, suppose that an application reserves one fragment consisting of four unit granularities,each 256 bytes. The total amount of reserved space is 1 Kbyte. The application writes data tothe reserved space in 32-byte increments. To implement power loss recovery, a status header atthe beginning of the fragment should track valid and empty data throughout the recording (seeFigure 4-8, Power Loss Recovery Status Header).

DATA STREAMING E

4-8

11/3/98 10:46 AM CHPT4.DOC


Status Header

Valid Data

Reserved Space

unit_granularities

Fragment

7897_08

Figure 4-8. Power Loss Recovery Status Header for Data Streams

This status header may consist of pairs of bits to track the state of each increment that is written(see Table 1, Data Streaming Status Header Definitions).

Table 4-1. Data Streaming Status Header Definitions

Name Condition Status Value(Binary)

Definition

“empty” 11 This indicates the increment has not been written to yet

“allocating” 01 The increment is in the process of being written

“valid” 00 The increment contains valid data

In the example above, if 31 increments may be written to the fragment (the status headerconsists of eight bytes if two bit/increment for status is used). If six increments are valid, one isin the process of being written, and the remaining are empty, the status header would appear inhex as 00 07 FF FF FF FF FF FF. Note that the last two bits in the status header would remainunused.

E DATA STREAMING

4-9

11/3/98 10:46 AM CHPT4.DOC


4.4.2 Recovering Data after Power LossTwo different methods may be incorporated to recover data after power loss:

1. Clean the corrupted section by rewriting the data that has already been written and excludethe increment that may have been lost during power loss (bits equaling “01” in the statusheader). The drawback is that this method increases initialization time.

2. Do nothing upon initialization and force the application to read/write around the firstincrement that that may have been lost during power loss (bits equaling “01” in the statusheader). The drawback is that this method can be inefficient in its use of space. In this case,32 bytes would be lost. This can add up if power loss is frequent—otherwise, it is a non-issue.

NOTE:

The above methods for tracking the status of data as well as recovering dataafter power loss are only recommendations, as other implementations may bemore appropriate for certain applications.

11/3/98 10:46 AM CHPT5.DOC


E5

Architecture and APISpecification

E

5-1

11/3/98 10:46 AM CHPT5.DOC


CHAPTER 5ARCHITECTURE AND API SPECIFICATION

5.1 INTRODUCTION

5.1.1 ScopeThis chapter provides a detailed design description of the Flash Data Integrator (FDI) whichenables code plus data storage in a single flash component.

5.1.2 PurposeThe purpose of this chapter is to provide a general and detailed design description of the FDIApplication Programming Interface (API).

5.1.3 System OverviewMany of today’s systems use flash for code storage and execution. These same systems useEEPROMs to provide nonvolatile memory for system data and parameter storage even thoughthe flash device often has unused space. The FDI code plus data solution removes theEEPROM from the system, thus reducing board space and product cost.

FDI allows the storage of data and the execution of code from the same flash device. FDI alsoallows for future upgrades and extensions in flash.

Figure 5-1 provides a highly simplified diagram of a system software architecture which is agood candidate for FDI. In this system, many tasks, such as protocol control, run on top of areal-time operating system kernel. An EEPROM data storage request may be prompted by auser pressing a key or a service routine which generates a system interrupt. An EEPROMmanager task handles the data storage request, and may queue the data in RAM until time isavailable to write the data to EEPROM.

ARCHITECTURE AND API SPECIFICATION E

5-2

11/3/98 10:46 AM CHPT5.DOC


MAC ISR

Key Press

EEPROMManager

O/S Kernel

TasksInterrupt Service Routines

FDI5-1

Figure 5-1. Simplified System Software Architecture

FDI is a complete flash media manager which includes an EEPROM manager type APIs. FDIhandles all aspects of storing and retrieving variable length parameters into flash memory. FDIallows system designers to remove EEPROM and use existing flash for parameter data andcode storage.

Intel’s Boot Block Flash memory products have been designed to maximize data efficiencywhen using FDI. FDI takes advantage of Intel’s Boot Block features including small datablocks and program/erase suspend features.

5.1.4 Chapter OverviewThe Flash Data Integrator General Description, Section 5.3, contains the FDI APIs, andgeneral implementation considerations.

The Flash Data Integrator Detailed Design, Section 5.4, contains the FDI softwarerequirements to a level of detail sufficient to enable system and firmware designers to design asystem with FDI as a component of their system.

E ARCHITECTURE AND API SPECIFICATION

5-3

11/3/98 10:46 AM CHPT5.DOC


5.2 FLASH DATA INTEGRATOR REFERENCES

5.2.1 Glossary

5.2.1.1 DEFINITIONS

Bitmask Set of bits

BYTE 8-bit unsigned value

DWORD 32-bit unsigned value

Granularity Minimum allocation unit size

Init Initialization

NIBBLE 4-bit unsigned value

NULL Zero

Unit A section of a flash block taking up one or more granular sizes

WORD 16-bit unsigned value

parameters Information such as system variables, small arrays, etc.

data streams Data such as SMS, voice messages, large arrays, etc.

data fragment A unit containing one of multiple data pieces of a parameter or data stream

Instance One occurrence of a parameter in a unit which can hold multiple occurrences of the parameter

5.2.1.2 ACRONYMS

APC Advanced Personal Communication

API Application Program Interface

EEPROM Electrically Erasable Programmable Read Only Memory

FDI Flash Data Integrator

GSM Global System for Mobile communications

ISR Interrupt Service Routines

RAM Random Access Memory

SMS Small Message Service

5.2.1.3 ABBREVIATIONS

blk block

blknum block number


5-4

11/3/98 10:46 AM CHPT5.DOC


5.2.2 ReferencesEuropean Digital Cellular Telecommunications System (Phase 2); Specification of theSubscriber Identity Module–Mobile Equipment (SIM–ME) Interface (GSM 11.11) ETS 300608, January 1995.

5.3 FLASH DATA INTEGRATOR GENERAL DESCRIPTION

5.3.1 Flash Data Integrator Product PerspectiveThe Flash Data Integrator (FDI) enables embedded systems to use flash memory for codestorage and execution as well as data storage. FDI will replace EEPROM management softwarein current systems. Figure 5-2 provides an overview of the software components necessary toaccomplish this and how these components interact with the existing system software.

MAC ISR

Key Press

FDI BackgroundManager: write,

delete

O/S Kernel

TasksInterrupt Service Routines

Reclaim

FDI ForegroundAPIs: open,

close, read, write,delete

FDI5-2

Figure 5-2. Simplified System Software Architecture Using FDI

All tasks and interrupts that need to store data into the flash interface to functions provided inthe FDI Foreground API. These functions (such as open/close/read/write) allow the commandand corresponding data to be queued in memory for the FDI Background Manager.


5-5

11/3/98 10:46 AM CHPT5.DOC


The FDI Background Manager is responsible for executing pending data writes. When a writeis queued, and background processing time is available, the Background Manager managesupdating or creation of data in flash. The Background Manager also initiates any reclaim ofinvalid (deleted) data areas in flash for reuse.

The FDI Background Manager and RECL_Task both utilize a small low-level flash erase andprogramming routine which resides in RAM. This low-level routine responds to interrupts thatoccur during the flash program/erase times by suspending the program/erase, and allowing theinterrupt to then be executed from flash. Worst case latencies for program and erase suspendare 10 µs and 20 µs, respectively.

FDI implements robust power loss recovery mechanisms to protect the valuable data stored inflash media.

Figure 5-3 provides a diagram of the information flow between flash and RAM. The systemcalls the Foreground API function (1), with a command and data. The Foreground API functioneither, writes the command and data into a RAM queue for operations which modify flash (1a),or executes the command directly for commands which do not modify flash (1b). TheBackground Manager (2), executing out of flash, manages the queued tasks during availableprocessor time. During a flash write or erase, interrupts with vectors in flash are disabled andcontrol is turned over to a small routine in RAM (3). This routine polls interrupts whilemonitoring progress of the program or erase operation. If a higher priority interrupt occurs, thepolling routine suspends the program or erase operation, and allows the interrupt handler tothen execute from flash. Upon completion of the interrupt routine, the flash program or eraseoperation is resumed by the RAM polling routine.


5-6

11/3/98 10:46 AM CHPT5.DOC


FlashRAM

Data Queues< 1 Kbyte

3

Flash program/erase control &Interrupt polling

< 1 Kbyte

ForegroundAPI: write, delete

2 BackgroundManager: write,

delete

EEPROMdata to be

stored

Spare

Factory Data

User Data

NetworkParameters

Boot Code

1a

ForegroundAPI: read, open,

close

1

1b

flash memorydata blocks

Reclaim

FDI4-3

Figure 5-3. Software Flash Data Integrator Data Flow Diagram

5.3.2 Foreground APIsThe Foreground API functions receive storage and read commands from other tasks in thesystem. The system calls the Foreground API function with a command and data. TheForeground API function then either writes the command and data into a RAM queue foroperations which modify flash, or executes the command directly for commands which do notmodify flash. The Foreground API functions are the application interface for storing EEPROMdata types, factory data, network parameters, data streams and user-alterable data to the flashmedia.


5-7

11/3/98 10:46 AM CHPT5.DOC


5.3.3 Background Manager and RECL_TaskThe FDI Background Manager controls the actual writes into the flash media. The BackgroundManager awaits the arrival of items into its Data Queue and then extracts the highest priorityitem to act upon. When there is CPU time available, the Background Manager reads from thequeue and determines the information’s location in flash. During flash programming and eraseoperations, the Background Manager or RECL_Task disables and polls interrupts. If aninterrupt occurs, the Background Manager or RECL_Task suspends the program/erase inprogress, and then relinquishes the flash to the interrupt task. Once the interrupt handling iscomplete, the Background Manager or RECL_Task continues until it completes, or untilinterrupted again by other interrupts. The Background Manager or RECL_Task resumes theprogram/erase which then continues in this fashion until the data queue is empty.

The Background Manager is responsible for initiating the RECL_Task which reclaims invalid(deleted or superseded) data. Reclamation occurs upon a predetermined free space trigger, or auser-defined percentage of a block that has been dirtied, or when there is not enough free spaceto store a new piece of data. The Background Task asks for permission from the system, andwhen granted, RECL_Task executes the reclamation process to free up invalid regions of flashmemory and makes them available for reuse.

5.3.4 InitializationThe initialization process performs power loss recovery and initializes all FDI hardware andRAM variables. FDI implements robust power loss recovery mechanisms throughout the code.This safeguards the valuable data stored in the flash media. By utilizing the uniquecharacteristics of flash media, the integrity of the existing data can be assured if power failswhile writing to flash.

The worst case power loss situations for FDI are:

• All data in the RAM queue (not yet written to flash) will be lost if a power failure occurs.

• Any operation in progress is considered not done.

If a power loss occurs during the operation, the partial data that has been written prior to powerloss is discarded. A reclamation in progress is identified and completed during the initializationprocess at the next power on. Refer to the Power Loss Recovery Process section below. Keep inmind that these worst case situations will occur with EEPROM usage as well.

5.3.4.1 POWER LOSS RECOVERY PROCESS

Power loss recovery is done during initialization to guarantee all internal structures and data arein a valid state. To validate all blocks, power loss recovery reads internal structures maintainedwithin each flash block. If a power loss has occurred during the reclaim of a block, the reclaimis restarted and completed. To validate all data, power loss recovery reads the header structures.If a power loss has occurred during a data modification, power loss recovery will restore theoriginal data.


5-8

11/3/98 10:46 AM CHPT5.DOC


5.3.5 Low-Level Code and Interrupt HandlingFDI performs all programs and erases to flash media through a RAM based low-level flashdriver.

The basic functions provided by the low-level flash driver are: program, erase, program/erasesuspend, and interrupt polling. During a flash program or erase, interrupts with vectors in flashare disabled and control is turned over to a RAM based low-level flash driver. This routinepolls interrupts while monitoring the progress of the flash program or erase operation. If ahigher priority interrupt occurs, the RAM based routine suspends the flash program or eraseoperation, and allows the interrupt handler to then execute from flash. Upon completion of theinterrupt routine, the flash program or erase operation is resumed by the RAM flash driver.

Intel’s Boot Block product family provides Erase Suspend to Read (ESR) in 20 µs maximumand Program Suspend to Read (PSR) in 10 µs maximum. This allows FDI to suspend programor erase and re-enable interrupts with minimal latency.

5.3.6 Implementation ConstraintsFDI is coded in ANSI Standard C. Documentation to assist users in porting processor specificareas is included in Chapter 6, Porting.

5.3.7 Assumptions, Dependencies and Limitations

• Only one open read/write stream will be supported at any given time.

• Deleting portions of stored data are not allowed.

• Data reads will not be interrupted.

• If the data is opened for read, the FDI_OpenStream structure points to the beginning of thedata.

• If the data is opened for modify or create, the FDI_OpenStream structure points to the endof the data.

• The priority of a data item must remain the same throughout the lifetime of the data item.


5-9

11/3/98 10:46 AM CHPT5.DOC


5.4 FLASH DATA INTEGRATOR DETAILED DESIGN

5.4.1 Media Control StructuresFDI manages code and data separately to enable code execution and data storage in the sameflash device. FDI provides a movable data/code partition, however, it must be on a flashmemory block boundary. A movable partition allows the ratio of code vs. data throughout thelife of a system to evolve to match the system’s needs. A symmetrically-blocked part isrequired to allow a movable data/code partition. For an asymmetrically-blocked flash device,the data/code partition is flexible within the same blocking space. That is to say, a small blockcannot be used as a spare block for a large block. FDI requires a spare block in the data storagearea for reclamation.

Boot Code

DataStorage

Spare Block

CodeStorage

MovableData/CodeBoundary

FDI5-4

Figure 5-4. Code + Data Storage Arrangement in Flash

FDI supports boot code blocks separate from code and data storage. The boot code blockscontain the initialization code needed at startup. Some systems may have boot code storedexternal to the flash device and would then use the entire flash device for code and data storage.


5-10

11/3/98 10:46 AM CHPT5.DOC


The following control structures are used by FDI to manage data. FDI provides flashread/write/modify capabilities with limited overhead and improved performance overEEPROM.

5.4.1.1 CONTROL STRUCTURES USED BY FDI

Command Control structure–Interface between the system and the FDI. A pointer to thisstructure enables the system and FDI to communicate and share information for reading,writing, and managing flash.

Unit Header structure–Describes the contents of the unit it points to with name, type, size, andattribute fields. Stored in the flash block which contains the data.

Multiple Instance structure–Describes the number of instances of the parameter which can becontained within this unit, and the current valid instance. Stored in the flash block whichcontains the data.

Block Information structure–Used to track the logical block number and power lossinformation. Stored at the bottom of every flash block.

Sequence Table structure–Describes the location of multiple Unit Headers describing multiplefragments of a parameter or data stream stored in a flash block.

Open Stream structure–Describes physical location of the data stream or parameter that wasopened with FDI_Open. Stored in RAM.

Data Queue structure–Describes the current state of the RAM priority queue. Contains thecontrolling semaphores and a pointer to the first priority header. This structure is part of theQUEUE_SIZE defined in RAM.

Group Table–A table containing entries that describe the location of sequence table UnitHeaders associated with the identifier. Stored in flash and is located with its own Unit Header.

Sequence Table–A table containing entries that describe the location of data fragment UnitHeaders associated with the identifier. Stored in flash and is located with its own Unit Header.

Logical Block array of structures–Describes the physical block number and the free and dirtyspace of each logical block. Stored in RAM.

Data Lockup array of structures–Describes the logical block number and type of eachidentifier. Stored in RAM.

5.4.1.2 HOW FDI USES CONTROL STRUCTURES

Each flash data block consists of a list of Unit Headers addressed from the top of the block, andthe data they describe addressed from the bottom of the block. Figure 5-5 shows thearrangement of Unit Headers and data within a physical block. At the bottom of each block isthe Block Information structure. The Block Information structure maintains the logical blocknumber and tracks reclamation status for the block.


5-11

11/3/98 10:46 AM CHPT5.DOC


Unit Header 1

Unit Header 2

Unit Header 3

Headers Grow Down

Data Grows Up

Data 3

Data 2

Data 1

Block Information

Diagram of a single block showing the relationship betweenUnit Headers and Data.

FDI5-5

Figure 5-5. Data Block Arrangement

For ease in data management, physical blocks are segmented into sections called units. A unit isa segment of a block whose contents are described by a Unit Header. Units vary in size in termsof granularity. Granularity is the minimum allocation unit size defined at compile time.


5-12

11/3/98 10:46 AM CHPT5.DOC


5.4.1.2.1 Command Control Structure

The Command Control structure is the interface between the system and FDI. A pointer toCommand Control enables the system and FDI to communicate with each other and shareinformation for reading, writing, and managing flash.

Command Control Structure Fields

typedef struct COMMAND_CONTROL {

DWORD buffer_ptr; /* pointer to buffer address */

DWORD count; /* number of bytes desired */

DWORD offset; /* beginning offset into the data */

DWORD aux; /* supplementary field */

WORD actual; /* number of actual bytes acted on */

WORD identifier; /* unique identity for each data or code */

BYTE type; /* either data or stream type */

BYTE priority; /* each identifier is assigned a priority */

BYTE sub_command; /* sub-command to expand functionality */

BYTE reserved; /* padded for DWORD alignment */

} COMMAND_CONTROL;

buffer_ptr–Pointer to a buffer to read data from, or write data to flash.

count–The number of bytes to read or write.

offset–The number of bytes into the Unit (offset) to begin reading or writing.

aux–Allows additional information to be passed between the application and FDI.

actual–The number of bytes FDI was able to read or write.

identifier–Unique identifier.

type–Used to define unique classes or types of information. A data type of zero (0) defines aparameter and any non-zero value up to and including six (6) for FDI V1.5, orfourteen (14) for release 2.0 (and up) is a user-definable data stream.

priority–The priority of the data determines the order the data is written, if the data is queuedfor write.

sub_command–Used for future or extended commands.


5-13

11/3/98 10:46 AM CHPT5.DOC


5.4.1.2.2 Unit Header Structure

The Unit Header describes the data unit within the physical block. It also tracks the status bitsof the data for reclamation and power loss recovery. Bit fields within the Unit Header structureindicate whether the data unit is active, being transferred, or invalid. Unit size indicatesmultiples of the base granularity.

Unit Header Structure Fields

typedef struct UNIT_HEADER {

WORD identifier; /* unique identifier per * parameter */

BYTE table_number /*sequence table number of * instance */

BYTE g_unit_size; /* in multiples of granularity */

WORD g_unit_offset_bottom; /* offset from the bottom * of the block in terms of * granularity */

BYTE status; /* power-off recovery */

BYTE type_attribute; /* data type and unit * attribute : multiple * instance, single instance, * sequence table, etc. */

} UNIT_HEADER;

identifier–A unique classification.

table_number– Identifies the exact sequence table number for the particular instance.

g_unit_size–g_unit_size is a multiple of granularity in this unit. Granularity is defined atcompile time as the minimum number of bytes taken up by any unit.

g_unit_offset_bottom–The offset from the bottom of the block (above the block info structure)where the Unit data starts. g_unit_offset_bottom is in multiples of granularity.

status–A bit-mapped field that indicates the current status of the parameter, data stream, etc.

type_attribute–This field distinguishes the information associated with this header. Thecurrently defined types in the first nibble of this field are attributes: Multiple Instance,Single Instance, Data Fragment and Sequence Table. The last nibble defines theassociated data type: parameter, data stream, phone number, etc.


5-14

11/3/98 10:46 AM CHPT5.DOC


Table 5-1. Unit Header Structure Status Field Definitions

Name Condition Status Value Definition

“empty” 1111 111X Binary This is an empty Unit Header. The systemcan use this for the next Unit Header

“allocating” 0111 111X Binary The Unit Header is in the process of beingwritten

“allocated” 0011 111X Binary The unit data is in the process of beingwritten

“valid” 0001 111X Binary This Unit Header describes valid data

“invalidating” 0000 111X Binary This Unit Header is in the process of beinginvalidated

“invalid” 0000 011X Binary This Unit Header describes invalid data

Table 5-2. Unit Header Structure Type Field Definitions

Type Value Definition

XXXX 1110 Binary This header points to Multiple Instance unit

XXXX 1100 Binary This header points to a sequence table

XXXX 1000 Binary This header points to a Single Instance unit

XXXX 0000 Binary This header points to a Data Fragment unit

0000 XXXX Binary The data type is parameter

0001 XXXX Binary The data type is data stream #1



5.4.1.2.3 Multiple Instance Structure

This structure describes multiple instances of small parameter data within a unit. Grouping thedata into multiple instances limits the overhead in managing small parameters, and improvesthe performance of updates. Figure 5-6 provides an example of a small parameter with fouravailable instances.


5-15

11/3/98 10:46 AM CHPT5.DOC


InstanceInformation

Instance #1status = VALID

Instance #2status = UNUSED



Valid Data Erased Erased Erased

FDI5-6

Figure 5-6. Example of Multiple Instances

Each instance has a corresponding status. New instances added have the status of “allocating,”“allocated,” and “valid.” The old instances have the status of “invalid.” Figure 5-7 displays aparameter updated with a new instance. Note the status of the old instance is set to “invalid.”

InstanceInformation

Instance #1status = INVALID

Instance #2status = VALID



Invalid Data Valid Data Erased Erased

FDI5-7

Figure 5-7. Parameter Update with New Instance

The number of multiple instances of the parameters is based on the size of the parameter andthe size of the containing unit (granularity).

Multiple Instance Structure Fieldstypedef struct MULTI_INSTANCE {

WORD size_of_instance; /* size of this instance of * * the data in bytes */

WORD number_of_instances; /* number of data instances * available in this unit */

} MULTI_INSTANCE;

size_of_instance–The size in bytes of each data instance.

number_of_instances–The number of instances available in this unit.


5-16

11/3/98 10:46 AM CHPT5.DOC


Following the MULTI_INSTANCE structure area are the instance status fields. There are fourstatus bits for each instance in this unit.

Table 5-3. Multiple Instance Structure Field Definitions


“empty” 1111 Binary This is an unused data instance

“allocating” 0111 Binary The instance is in the process of being written

“valid” 0001 Binary The instance holds valid data

“invalid” 0000 Binary The instance no longer holds valid data

5.4.1.2.4 Block Information Structure

The Block Information Structure is located at the bottom of each physical block used for datastorage. It contains the logical block number, reclamation status, and current state of the block.Figure 5-8 depicts the block information structure in a physical block.

Rest of the Block

status logical block number current state last addressin block

FDI5-8

Figure 5-8. Placement of Block Information


5-17

11/3/98 10:46 AM CHPT5.DOC


Block Information Structure Fieldstypedef struct BLOCK_INFO {

#if RECL_WEARLEVELING

DWORD erase_count; /* number of times this block is * erased */

DWORD physical_erase_count; /* number of times the block being * reclaimed block has been * erased */

#end if

BYTE status; /* reclamation information */

BYTE logical_block_number; /* allows for movable spare block */

BYTE physical_copy; /* physical block being copied * during reclamation */

BYTE reserved_byte; /* padding for data alignment */

WORD reserved_word; /* padding for data alignment */

WORD current_state; /* this will demonstrate block * integrity: F0F0H */

} BLOCK_INFO;

erase_count–Tracks the number of times this block has been erased.

physical_erase_count–Tracks the number of times the block being reclaimed has been erased.

status–This field contains the information needed for the reclamation process.

logical_block_number–Contains the logical block number.

physical_copy–Contains the physical block number of the block being copied during reclaim.

current_state–Enables the FDI software to verify the block’s integrity. Current_state ischecked to see if a block erase was interrupted by a power loss.


5-18

11/3/98 10:46 AM CHPT5.DOC


Table 5-4. Block Information Structure Status Field Definitions


“erased” 1111 1111 Binary Indicates block has not been written to and allbits are in the erased state

“recover” 1111 1110 Binary Indicates that the process of placing data intothis block from a block being reclaimed hasbegun

“erasing” 1111 1100 Binary All data has been transferred from a blockbeing reclaimed to this block and the blockindicated is undergoing erase

“updating” 1111 1000 Binary After erasing, updating the spare block erasecount in the parameter where it is maintained

“write” 1111 0000 Binary This block is available for writing

5.4.1.2.5 Data Stream Methodology

If data spans physical block boundaries, a combination of group and sequence tables is used tolist each data fragment. Figure 5-9 provides an example of using these tables with threeseparate fragments across two physical blocks. Group tables contain an ordered list of sequencetables. Sequence tables contain an ordered list of data fragments. Unit Headers for eachsequence table and data fragment are described by logical block number and occurrence in theblock. Notice in Figure 5-9 that the second fragment in the sequence table is associated to thesecond instance in block 1.

Sequence Table Structure Fieldstypedef struct SEQUENCE_TABLE {

BYTE block_number; /* virtual block number */BYTE fragment_instance; /* the instance of this fragment */WORD fragment_size; /* in multiples of granularity */WORD physical_index; /* the Unit Header that needs to be

* invalidated */} SEQUENCE_TABLE;

block_number–This is the block number of the parameter data.

fragment_instance–Because there can be multiple fragments in a single block, this fieldcontains the instance of this fragment in the Unit Header table.

fragment_size–This field describes each fragment’s size in multiples of granularity.

physical_index–During power off recovery, used to track the location of the original data whenreplacing a fragment.


5-19

11/3/98 10:46 AM CHPT5.DOC


Group/Sequence Table Entry Fieldstypedef struct ENTRY_TABLE {

BYTE block_number; /* virtual block number */BYTE entry_status; /* table entry status byte-PLR */WORD entry_instance; /* the instance of this frag/table */BYTE entry_size; /* in multiples of granularity */BYTE old_entry_block; /* replaces entry’s logical block

* number */WORD physical_index; /* the header that needs to be

* invalidated */

} ENTRY_TABLE;

block_number–This is the logical block number of the sequence table or parameter datafragment.

entry_status–This tracks the state of the table update when appending to an existing table.

entry_instance–Because there can be multiple sequence tables or fragments in a single block,this field contains the instance of this table’s or fragment’s Unit Header in the logicalblock.

empty_size–This field describes each table’s or fragment’s size in multiples of granularity.

old_entry_block–During power loss recovery, used to track the block number of the originaldata when replacing a sequence table or data fragment.

physical_index–During power loss recovery, used to track the location of the original datawhen replacing a sequence table or data fragment.


5-20

11/3/98 10:46 AM CHPT5.DOC


Get Parameter X

Data X Group Table Header

Data X Sequence Table Fragment Header

Data X Sequence Table Fragment (#1)

Group Table: Data X

Block Info Structure: Logical Block 0

Block 0 Instance #1

Block 1 Instance #2

Block 1 Instance #1

Block 1 Instance #1

Block 2 Instance #1

Block 3 Instance #2


Parameter X Data Fragment Header



Parameter X Data Fragment (#1)


Block Info Structure: Logical Block 1

FDI5-9

Figure 5-9. A Sequence Table Example


5-21

11/3/98 10:46 AM CHPT5.DOC


5.4.1.2.6 Data Queue Structure

The system writes to the Data Queue using FDI API functions to request flash reads, writes,and modifications. Figure 5-10 depicts the Data Queue Structure.

Command Queue Node Fieldstypedef struct Q_HEADER {

struct Q_HEADER * next_header_ptr; /* points to next lower * priority header */

Q_ITEM_PTR first_item_ptr; /* points to first item structure*/

WORD accum_free; /* accumulated free flash space in Q */

WORD accum_dirty; /* accumulated dirty flash space in Q */

BYTE priority; /* priority of item in queue */

} Q_PRIORITY_HEADER;

next_header_ptr–Points to the next lower priority element in the Command Queue Nodepriority queue. If there is no lower priority element, this field points to NULL.

first_item_ptr–Points to the first command element in the command queue of priority“priority.”

accum_free–Accumulated free space used in this priority in queue.

accum_dirty–Accumulated dirty space used in this priority in queue.

priority–Data is accessed from the command queue in high to low priority order.


5-22

11/3/98 10:46 AM CHPT5.DOC


Command QueuePriority element

Command Queueelement

null




null


null



null

Elements in eachCommand Queue havesame priority.

Elements in Priority Queueare ordered in decreasingpriority.

FDI5-10

Figure 5-10. Data Queue Structure


5-23

11/3/98 10:46 AM CHPT5.DOC


typedef struct Q_ITEM {

struct Q_ITEM *next_item_ptr; /* points to next item * structure */

WORD item_size; /* size of item data tagged * below this structure */

} Q_ITEM_INFO;

next_item_ptr–Points to the next element in the command queue. If the current element is thelast element, then next_item_ptr is set to NULL.

item_size–Indicates the size in bytes of the data buffer to be written/modified.

typedef struct COMMAND {DWORD data_offset; /* beginning offset into the data to

* be accessed. */

IDTYPE identifier; /* identity of data accessed. */

WORD gran_needed; /* space needed in granularity */

BYTE sub_command; /* task execution sub command */

BYTE type; /* command type: either data * parameter or data stream. */

BYTE priority; /* used to update Q_PRIORITY_HEADER * accumulated values */

} COMMAND;

data_offset–The number of bytes from the beginning of the data unit to begin operation.

identifier–Unique identifier of a data unit to write/modify.

gran_needed–The space needed in terms in granularity.

sub_command–The type of data modification function requested.

type–Defines unique classes of data storage information.

priority–The priority of this data is used to update Q_PRIORITY_HEADER valuesaccum_free and accum_dirty once the data is pulled from the queue.


5-24

11/3/98 10:46 AM CHPT5.DOC


typedef struct Q_DESCRIPTOR {

SEM_ID sem_cntrl_sync; /* true when an item is in the * queue */

SEM_ID sem_cntrl_mutex; /* mutex queue protection */

Q_HDR_PTR first_header_ptr; /* points to first priority * header */

BYTE alignment_shift; /* for DWORD boundary * alignment */

BYTE number_items; /* count of items in queue */

WORD free_count; /* number of free bytes */

WORD queue_id; /* used for verification */

WORD queue_signature; /* used for verification */

} Q_DESCRIPTOR;

sem_cntrl_sync–Binary semaphore used to indicate when an item is in the queue. TheBKGD_Task is pending on this semaphore while waiting for an item to arrive in thequeue.

sem_cntrl_mutex–Mutex semaphore used to protect the queue structures allowing only onetask to access the queue at any given time.

first_header_ptr–Points to the first priority header in the queue.

alignment_shift–Value used for DWORD boundary alignment during Q_Create if necessary.

number_items–The number of items in the queue. Used by Q_Status.

free_count–The number of free bytes available in the queue.

queue_id–If the compile option Q_VERIFICATION is set TRUE the first WORD of the Q_IDaddress is stored here and compared at the beginning of each queue function. Can bedisabled if necessary by setting Q_VERIFICATION to FALSE to decrease code sizeand improve performance.

queue_signature–If the compile option Q_VERIFICATION is set TRUE the first WORD ofthe Q_ID address inverted is stored here and compared at the beginning of each queuefunction. Can be disabled if necessary by setting Q_VERIFICATION to FALSE todecrease code size and improve performance.


5-25

11/3/98 10:46 AM CHPT5.DOC


5.4.1.3 RAM USAGE AND CONTROL STRUCTURES

The RAM usage listed is in addition to that used by the queue and stack.

Variable Name Data Type Description Size in Bytes

FDI_OpenStream OPEN_STREAM A copy of last data found used bythe FDI_Open and FDI_Closeroutines

43

FDI_LogicalBlockTable LOGICAL_BLOCK The table contains the logicalblock number, free space anddirty space for each physicalblock

5 per block

FDI_DataLookupTable DATA_LOOKUP Points to the data Unit Headerlocation

1 per identifier

5.4.2 Modules

5.4.2.1 FOREGROUND API SUB-SYSTEM

5.4.2.1.1 Opening Data

FDI_Open opens data for reading, editing or creates a data stream for writing. Only oneparameter or data stream can be opened at any given time.

Open Data FormatERR_CODE FDI_Open(COMMAND_CONTROL *cmd_cntrl);


5-26

11/3/98 10:46 AM CHPT5.DOC


Input Elements

Identifier Description DataType

DataRep.

Limit / Range ValidityCheckPerf.?

InputMethod

cmd_cntrl->sub_command

This field containsa command toindicate the datastream openingmethod:

OPEN_READ:Open for read only

OPEN_MODIFY:Open for parameterdata modification

OPEN_CREATE:Open for writing anew parameter

BYTE flag

OPEN READ

OPEN MODIFY

OPEN CREATE

yes by ref.

cmd_cntrl->aux unused

cmd_cntrl->identifier

This is a uniqueparameter or datastream identifier

WORD integer 0 <= identifier <=MAX_PARAMETERS,FIRST_STREAM <=identifier <=MAX_IDENTIFIERS,NEW_DATA_STREAM_ID

yes by ref.

cmd_cntrl->type This field indicatesa data type. Theoptions are:

DATA_PARAMETER oruser defined datastream type

BYTE integer type <= MAX_TYPE yes by ref.

cmd_cntrl->priority Data item’s priorityvalue

BYTE integer >= MIN_PRIORITY,<= MAX_PRIORITY

yes by ref.

Processes Characteristics

FDI_Open improves performance when accessing a data stream multiple times by maintainingopen stream information in RAM. FDI_Open stores the opened data information in the globalFDI_OpenStream structure. FDI_Open returns an error if the system attempts to open multipleparameters or data streams. FDI_Open calls DataFind to determine the existence of data with amatching identifier and type. If data already exists and is being opened for reading ormodification, FDI_Open updates the FDI_OpenStream structure. The FDI_OpenStream


5-27

11/3/98 10:46 AM CHPT5.DOC


structure is made to point to the beginning or end of the data stream, based on the sub-command OPEN_READ and OPEN_MODIFY respectively. Successive calls to FDI_Read orFDI_Write bypass the call to DataFind thus reducing overhead.

Error Handling

If during the open process there is an error, the return value will contain a non-zero error code.

Utilization of Other Elements

None.

Limitations

Only one parameter or data stream can be opened at any given time.

Output Elements

Identifier Description Data Type DataRepresentation

Limit /Range

ValidityCheckPerf.?

OutputMethod

cmd_cntrl->buffer_ptr

unused

error Refer to thereturn codesin Section 5.5

ERR_CODE ENUM n/a no functioncall

cmd_cntrl->identifier If inputidentifier isNEW_DATA_STREAM_ID,id is returned

FDI_OpenStream Open Streamdata structure

OPEN_STREAM structure n/a no update

cmd_cntrl->type reserved


reserved

5.4.2.1.2 Closing Data

FDI_Close closes an open parameter or data stream.

Close Data FormatERR_CODE FDI_Close(COMMAND_CONTROL *cmd_cntrl);


5-28

11/3/98 10:46 AM CHPT5.DOC


Input Elements


DataRep.


InputMethod

cmd_cntrl->identifier Uniqueparameter ordata streamidentifier

WORD integer 0 <= identifier <=MAX_PARAMETERS,FIRST_STREAM<= identifier <=MAX_IDENTIFIERS

yes byreference

cmd_cntrl->type This fieldindicates a datatype. Theoptions are:

DATA_PARAMETERor user defineddata streamtype

BYTE integer type <= MAX_TYPE yes byreference


unused

cmd_cntrl->count unused

cmd_cntrl->offset unused

cmd_cntrl->actual unused


cmd_cntrl->priority Data’s priority BYTE integer >= MIN_PRIORITY,< =MAX_PRIORITY

yes byreference

cmd_cntrl->buffer_ptr reserved

Processing Characteristics

FDI_Close determines if data is open. FDI_Close returns an error if no data is open. FDI_Closeclears the FDI_OpenStream structure to indicate closing data.

Error Handling

If during the close process there is an error, the return value will contain a non-zero descriptiveerror code.


None.


5-29

11/3/98 10:46 AM CHPT5.DOC


Limitations

Not applicable.

Output Elements

Identifier Description Data Type DataRep.

Limit /Range

ValidityCheck

Performed?

OutputMethod

error Refer to the returncodes in Section5.5


FDI_OpenStream Open Stream datastructure

OPEN_STREAM structure n/a no update

cmd_cntrl->identifier reserved



reserved

cmd_cntrl->buffer_commend

unused




cmd_cntrl->priority unused


5.4.2.1.3 Deleting Data

The delete process invalidates data in the flash media.

Delete Call FormatERR_CODE FDI_Delete(COMMAND_CONTROL *cmd_cntrl);


5-30

11/3/98 10:46 AM CHPT5.DOC


Input Elements


DataRep.


InputMethod

cmd_cntrl->identifier Uniqueparameter ordata streamidentifier

WORD integer 0 <= identifier <=MAX_PARAMETERS,FIRST_STREAM <=identifier <=MAX_IDENTIFIERS

yes byreference

cmd_cntrl->type This fieldindicates a datatype. The optionsare:

DATA_PARAMETER oruser define datastream type

BYTE integer type <= MAX_TYPE yes byreference

cmd_cntrl->priority Used to indicatethe priority of theparameter ordata stream


yes byreference

cmd_cntr->sub_command

unused





cmd_cntrl->buffer_ptr reserved


FDI_Delete loads all requests to modify the flash into the Data Queue for the BackgroundManager to execute in priority order. FDI_Delete returns an error if the parameter or datastream is open. Using the input identifier and type as parameters, a call to DataFind verifies thedata’s existence. FDI_Delete fills a Data Queue entry structure buffer and calls Q_Add to addthe entry to the queue.

Error Handling

If during the delete process there is an error, the return value will contain a descriptive errorcode.


5-31

11/3/98 10:46 AM CHPT5.DOC



None.

Limitations

Not Applicable.

Output Elements

Identifier Description Data Type Data Rep. Limit /Range

ValidityCheckPerf.?

OutputMethod

cmd_cntrl->buffer_ptr unused





cmd_cntrl->priority reserved






reserved

5.4.2.1.4 Getting Data

The get process locates the first or next parameter or data stream of the specified type or it willfind the ID of a matched parameter or data stream using the type and identifier fields. FDI_Getupdates the FDI_Get Data Found structure.

Get Data FormatERR_CODE FDI_Get(COMMAND_CONTROL *cmd_cntrl);


5-32

11/3/98 10:46 AM CHPT5.DOC


Input Elements


DataRep.


InputMethod


Contains a flag tomodify thefunctions action:

GET_FIRST:finds the first dataitem of a giventype

GET_NEXT: findsthe next data itemof a given type

GET_MATCHED:finds thematching dataitem of a giventype and identifier

BYTE flag commands listedbelow:

GET_FIRST

GET_NEXT

GET_MATCHED

yes by ref.

cmd_cntrl->identifier This is a uniqueparameter or datastream identifier

This input is onlyused for theGET_MATCHEDoption


yes by ref.

cmd_cntrl->type This fieldindicates a datatype. The optionsare:

DATA_PARA-METER or userdefined datastream type


cmd_cntrl->buffer_prr

unused





5-33

11/3/98 10:46 AM CHPT5.DOC



DataRep.


InputMethod

cmd_cntrl->priority Used to indicatethe priority of theparameter or datastream, onlynecessary forGET_MATCHED


yes, forGET_MATCHEDonly

by ref.



FDI_Get calls the DataFind routine and saves the data location into the structureFDI_GetDataFound defined from the Data Location structure type. FDI_Get usesFDI_GetDataFound structure to find the next data item of the same type if the input sub-command is GET_NEXT. FDI_Get updates the FDI_Get Data Found structure. The type andattribute is returned to the calling function through the cmd_cntrl->type field. The FDI_Get APIalso calls the GetDataSize routine to calculate the total data size. The total data size is returnedto the calling function through the cmd_cntrl->count field.

Error Handling

If the DataFind routine returns an error, the function sets the input parameter buffer to zero andreturns the error. The error ERR_NOTEXISTS indicates the last id of a particular type has beenfound or if the type is GET_MATCHED, indicates that the data does not exist.


None.

Limitations

Data stored in a single instance or fragmented structures is stored on a granular unit basis. Thismeans that file size is tracked to a granularity resolution for these storage types. This requiresknowledgeable handling of parameters and data streams. Most parameters are of a pre-determined structure so the size is not requested from the filing system. Data streams are oftenof undetermined size so the size is usually requested from the filing system. Since FDI does nottrack data streams to a byte granularity, this must be resolved in the application layer. This isdone by implementing an internal data stream structure tracking method to allow the END OFFILE (EOF) to be determined by the application.


5-34

11/3/98 10:46 AM CHPT5.DOC


Output Elements


ValidityCheck

Performed?

OutputMethod


unused

error Refer to thereturn codes inSection 5.5

ERR_CODE ENUM n/a no function call

cmd_cntrl->identifier reserved forGET_MATCHEDsub-command–identifier foundfor get_first/_next

WORD integer n/a n/a n/a

cmd_cntrl->type type and attribute BYTE integer n/a n/a by ref.

cmd_cntrl->count data size DWORD integer n/a n/a by ref.






reserved

5.4.2.1.5 Reading Data

The read process returns the specified portion of a parameter or data stream’s content into acalling routine’s data buffer.

Read Data FormatERR_CODE FDI_Read(COMMAND_CONTROL *cmd_cntrl);


5-35

11/3/98 10:46 AM CHPT5.DOC


Input Elements


DataRep.


InputMethod


This is a pointer to abuffer in which thedata content is placed

BYTE_PTR pointer n/a no by ref.

cmd_cntrl->count This field contains thenumber of bytes toread

DWORD count n/a yes by ref.

cmd_cntrl->offset This is the number ofbytes into theparameter or datastream to beginreading

DWORD index n/a yes by ref.



unused


cmd_cntrl->identifier This is a uniqueparameter or datastream identifier


yes by ref.

cmd_cntrl->type This field indicates adata type. The optionsare:

DATA_PARAMETERor user define datastream type

BYTE integer type <=MAX_TYPE

yes by ref.

cmd_cntrl->priority Priority of the data BYTE integer >=MIN_PRIORITY,<=MAX_PRIORITY

yes by ref.


FDI_Read reads from the starting offset location in the parameter or data stream and writescount bytes of data into the buffer. Using the identifier and type input parameters, FDI_Readverifies the data’s existence in the FDI_OpenStream structure. FDI_Read calls DataFind toupdate the FDI_OpenStream structure if the data is not currently open. FDI_Read gets the datasize in multiples of granularity and updates the FDI_OpenStream structure size field.


5-36

11/3/98 10:46 AM CHPT5.DOC


If the data stream or parameter is fragmented, the data fragments are read unit by unit for eachfragment in the sequence table until done reading. If no fragmentation exists, a single unitneeds to be read. To read information from any unit, a starting offset and data size are set up toindicate the amount of data read within the current unit. FDI_Read calls ReadData to read fromthe starting offset location in flash and writes size bytes of data into the buffer.

To verify that more up-to-date data is not available, ReadData determines if data with the sameidentifier and type are pending in the Data Queue by calling Q_Peek. If matching data is in thequeue, Q_Peek returns a pointer to the queue buffer. ReadData updates the buffer data ifcommands in the Data Queue overwrite the data. ReadData repeatedly calls Q_Peek until thereare no more matching data modification items in the Data Queue. Finally, FDI_Read checks theactual number of bytes read by ReadData. If it is less than the requested number, FDI_Readreturns an error.

Error Handling

If during the read process there is an error, the return value will contain a descriptive errorcode.


None.

Limitations

Not Applicable.

Output Elements


ValidityCheck

Performed?

OutputMethod


Points to thebuffer into whichthe flash data isstored

BYTE_PTR pointer n/a no byreference


ERR_CODE ENUM n/a no function call






5-37

11/3/98 10:46 AM CHPT5.DOC



ValidityCheck

Performed?

OutputMethod

cmd_cntrl->actual The actualnumber of bytesread

DWORD count n/a no byreference



cmd_cntrl->sub_cmd reserved

5.4.2.1.6 Writing Data

The write process queues data to be written or replaced by the Background Manager.

Write Data FormatERR_CODE FDI_Write(COMMAND_CONTROL *cmd_cntrl);

Input Elements



InputMethod


This points to thedata to be written

BYTE_PTR pointer MAX_QUEUE_ITEM_SIZE

no by ref.

cmd_cntrl->count The number ofbytes to write

DWORD integer If WRITE_APPENDorWRITE_RESERVED,then 1≤ count ≤MAX_QUEUE_ITEM_SIZE. IfWRITE_RESERVEDor WRITE_MODIFY,then 1≤ count ≤filesize-offset

yes by ref.

cmd_cntrl->offset The index into thedata at which thenew data is written

DWORD integer If WRITE_APPENDorWRITE_RESERVED,then 0≤ offset ≤filesize (if < filesize,treat asWRITE_REPLACE).If WRITE_REPLACEor WRITE_MODIFY,then 0≤ offset< filesize.

yes by ref.


5-38

11/3/98 10:46 AM CHPT5.DOC




InputMethod


Contains a flag tomodify the function’saction:

WRITE_REPLACE:replaces existing datain flash

WRITE_APPEND:writes after existing orcreates new data

WRITE_MODIFY:modifies existing datain place

WRITE_RESERVED:reserves space forlater data streammodifications

BYTE flag commands listedbelow:

WRITE_REPLACE

WRITE_APPEND

WRITE_MODIFY

yes by ref.

cmd_cntrl->identifier

Unique parameter ordata stream identifier

WORD integer 0 <= identifier <=MAX_PARAMETERS,FIRST_STREAM <=identifier <= MAX_IDENTIFIERS

no by ref.

cmd_cntrl->type This field indicates adata type. Theoptions are:

DATA_PARAMETER or userdefined data streamtype


cmd_cntrl->priority Priority value of thedata


yes by ref.




FDI_Write loads all requests to modify the flash data into the Data Queue for the BackgroundManager to execute in priority order.

FDI_Write checks the FDI_OpenStream structure to see if the data is already opened.Otherwise FDI_Write calls DataFind to see if the data exists in the flash media. FDI_Writecreates the data if the sub-command type is WRITE_APPEND and DataFind returns errorERR_NOTEXIST. NEW_DATA_STREAM_ID should be used to create a data stream.


5-39

11/3/98 10:46 AM CHPT5.DOC


A call to Q_Add loads the command element information into the Data Queue.

Error Handling

If during the write process there is an error, the return value will contain a descriptive errorcode.


None.

Limitations

Not applicable.

Output Elements


ValidityCheckPerf.?

OutputMethod

error Refer to thereturn codes inSection 5.5


cmd_cntrl->identifier WhenNEW_DATA_STREAM_ID isthe identifierinput, id isreturned

5.4.2.1.7 Reclaim Request Enable

FDI_ReclaimEnable unlocks the reclaim process pending on the RECL_Enable semaphore. Areclaim can be invoked by the system at any time.

Reclaim Call FormatERR_CODE FDI_ReclaimEnable(void);

Input Elements

None.


5-40

11/3/98 10:46 AM CHPT5.DOC



FDI_ReclaimEnable grants reclaim permission by asserting the RECL_Enable semaphore.

RECL_Enable: Used to control flash reclamation. When RECL_Enable is asserted, reclamationis unlocked and proceeds to reclaim invalid (written to but superseded) areas of flash.

Error Handling

None.


None.

Limitations

Not applicable.

Output Elements

None.

5.4.2.1.8 Memory Statistics

This memory statistics process calculates the memory statistics of the media and returns thevalues to the calling function.

Memory Statistics Call FormatERR_CODE FDI_Statistics(DWORD *freeUnits, DWORD *invalidUnits);

Input Elements

Not applicable.


FDI_Statistics provides a way to monitor the FDI usage of the entire media. These valuesrepresent FDI usage for the Flash Data Integrator structures and application data. The totalnumber of clean units remaining does not include those units held in reserve(SYSTEM_THRESHOLD and FDI_THRESHOLD). Each entry of the Logical Block tabletracks the statistics of individual blocks. FDI_Statistics adds up the free_space field of theLogical Block table to get the total free space and the dirty_space field to get the total invalidspace. FDI_Statistics returns these values by filling in the variables pointed to by the pointersthat were passed in by the calling function.


5-41

11/3/98 10:46 AM CHPT5.DOC


Error Handling

Not applicable.


None.

Limitations

Not applicable.

Output ElementsIdentifier Description Data

TypeData

RepresentationLimit /Range

ValidityCheckPerf.?

OutputMethod

freeUnits Number of freeunits in terms ofgranularity

DWORD pointer no byreference

invalidUnits Number ofinvalid units interms ofgranularity

DWORD pointer no byreference

5.4.2.1.9 Data Queue Status

FDI_Status returns the queue status and the reclamation status to the calling function.

Status Call FormatERR_CODE FDI_Status(BYTE PTR Status);

Input Elements

None.


5-42

11/3/98 10:46 AM CHPT5.DOC



FDI_Status returns whether reclamation is in progress and whether the data queue is empty.

The table below indicates all possible values that can be returned by this function and itsinterpretation.

Bit mask Interpretation

0000 No pending reclamation. Queue is empty

0001 Reclamation is pending. Queue is empty

0010 No pending reclamation. Message pending in the queue

0011 Reclamation is pending. Message pending in the queue

Error Handling

None.


None.

Limitations

Not applicable.

Output Elements


DataRepresentation

Limit /Range

ValidityCheckPerf.?

OutputMethod

status Return valueindicates thestatus of thequeue andreclamation

BYTE integer 0–3 no functioncall

5.4.2.1.10 Retrieving Errors

FDI_GetError provides a mechanism for retrieving error information for errors that occur in theBackground or Reclaim Tasks. The function pends on an error indication semaphore andreturns the information once an error occurs. Errors should be monitored frequently throughpolling or a dedicated task.

Get Error Call FormatERR_CODE FDI_GetError(ERROR_INFO *error_buf_ptr, DWORD timeout);


5-43

11/3/98 10:46 AM CHPT5.DOC


Input Elements


DataRep.


InputMethod

timeout The number ofticks to remainblocked on theerror semaphore

DWORD integer 0–DWORDMAX yes by value


This function fills the ERROR_INFO structure which gives the information about the errortypes that occurred in the background. This function also returns the background errorinformation if one occurred. If no background error occurred before timeout, ERR_TIMEOUTis returned.

Error Handling

Not applicable.


Not applicable.

Limitations

Not applicable.

Output Elementstypedef struct ERROR_INFO {

BYTE error_handled; /* indicates when error is handled */

BYTE error_code; /* codes from ENUM ERR_CODE */

} ERROR_INFO;


Data Rep. Limit /Range

Validity CheckPerformed?

OutputMethod

error Returns an errorcode generatedby FDI

ERR_CODE ENUM n/a no byfunction

error_buf_ptr Pointer to errorinformationstructure

ERROR_INFO pointer n/a no byreference


5-44

11/3/98 10:46 AM CHPT5.DOC


5.4.2.1.11 Formatting

The format function is provided to allow systems to re-format the flash during development. Itwill not typically be part of the product, however, an in-system format capability allowsrecovery for issues that arise during porting. This function erases all data blocks within the FDIpartition and sets up the flash for data storage.

Format Call Formatvoid FDI_Format(void);

Input Elements

Not applicable.


This function formats the flash media, preserving the erase count if wear leveling compile timeoption is set to true. Format process includes reading any existing spare erase count parametervalue, input and output elements, erasing all the blocks, rewriting the erase count parameter andthe block information, and re-initialization.

Error Handling

Not applicable.


Not applicable.

Limitations

Not applicable.

Output Elements

Not applicable.


5-45

11/3/98 10:46 AM CHPT5.DOC


5.4.2.1.12 Advanced+ Boot Block Features Commands

These functions in FDI Release V2.0, provide access to the features provided in the Intel®Advanced+ Boot Block product line (28FxxxC3). These functions are only available when theAdvanced+ component support is enabled with the appropriate compile time option(s).

Protection Register

Enable PR should be set true by the customer if access to the PR Register is desired. EnableTSOPx8 shall be set true if the device is a TSOP x8. Both defaults disabled.

#define ENABLE_PR FALSE

#define ENABLE_TSOPx8 FALSE

Block Locking

The block locking feature in general is enabled by setting the Block_Lock_Support compiletime options to TRUE. The default is disabled.

#define BLOCK_LOCK_SUPPORT FALSE

Conditional compile flag that shall be set true by customer if non-FDI managed block lockingcapability is desired. Default disabled.

#define ENABLE_NONFDI_BLOCKLOCKING FALSE

Conditional compile flag that shall be set true by customer if FDI managed block lockingcapability is to be enabled. If enabled, it shall be assumed that a supporting flash device isinstalled so that validation is not necessary. Default disabled.

#define ENABLE_FDI_BLOCKLOCKING FALSE


5-46

11/3/98 10:46 AM CHPT5.DOC


Figure 5-11 illustrates the software flow for block locking on the Advanced+ Boot Blockcomponents.

Disable Interrupts

Flash Status

Flash Ready?

Flash Suspend

Flash Status

Flash Ready?

Program Suspend?

Lock Command

Flash Resume

Program Suspend?

Lock Command

Flash Read

Enable Interrupts

ERR_NONEExit

Flash Resume

Flash Ready?

Lock Command

Flash Read

Enable Interrupts

ERR_NONEExit

Flash Read

Enable Interrupts

ERR_SUSPENDExit

Y

N (erase suspend or idle)

Y

Y

N

N

Y (program done)

N (erase suspend )

N

fdi5-11

Figure 5-11. Block Lock Flowchart for Advanced+ Boot Block


5-47

11/3/98 10:46 AM CHPT5.DOC


5.4.2.1.13 Read Protection Register

FDI_ReadProtectionReg reads the Protection Register (PR) of the Advanced+ Boot Blockcomponent for use by a higher level function.

Read Protection Register Call Format

ERR_CODE FDI_ReadProtectionRegister (BYTE * factory_reg, BYTE * user_reg);

Input Elements

Identifier Description Data Type Data Rep. Limit/Range ValidityCheck Perf.?

InputMethod

factory_reg Pointer to an 8-bytefield which willreceive the value atthe factory-programmedprotection register

BYTE * registerpointer

n/a no byreference

user_reg Pointer to an 8-bytefield which willreceive the value atthe user-programmedprotection register


n/a no byreference


API function residing in low-level code that receives a pointer to a 16-byte field. The factory-programmed field is placed in the lower eight bytes and the user-programmed field is placed inthe upper eight bytes. Status is returned.

Error Handling

ERR_NONE Function completed successfully.

ERR_PARAM Pointer value was NULL.

ERR_NOTRDY The flash device is in the “busy” state. At function entry the flash must be in the readmode and not busy.

ERR_SUSPEND The flash device is in the “suspended” state. At function entry the flash must be inthe read mode and not suspended.


None.


5-48

11/3/98 10:46 AM CHPT5.DOC


Limitations

Only valid for Advanced+ Boot Block components.

Output Elements

Identifier Description Data Type Data Rep. Limit/Range ValidityCheckPerf.?

OutputMethod

status Status return value ERR_CODE ENUM ERR_NONEERR_NOTRDYERR_SUSPEND

no byfunctioncall

pProt_reg Protection registerdata is referencedvia this pointer

PROT_REG pointer n/a no byreference

5.4.2.1.14 Write Protection Register

Write Protection Register writes the Protection Register (PR) of the Advanced+ Boot Blockcomponent for use by a higher level function.

Call Format

ERR_CODE FDI_WriteProtectionRegister (BYTE * pUsr_reg, BYTE lock);

Input Elements


InputMethod

pUsr_reg Pointer to an 8-byte field that willbe written to theuser-programmablesegment of theprotection registers


n/a no byreference

lock If TRUE, the lockword is written tolock the user-programmablesegment after theprotection

BYTE integervalue

TRUEFALSE

yes by value


5-49

11/3/98 10:46 AM CHPT5.DOC



API function residing in low-level code that receives a pointer to an eight-byte field. The user-programmed field is written with the data at this pointer. An option to “write and lock” is alsoprovided. Status is returned.

Error Handling




ERR_WRITE Flash device write failure.



None.

Limitations


Output Elements


OutputMethod

status Status return value ERR_CODE ENUM ERR_NONE,ERR_NOTRDY,ERR_WRITE, andERR_SUSPEND

no byfunctioncall

5.4.2.1.15 Read PR-Lock

Provides access to the Advanced+ Boot Block Protection Register lock. The data is for use by ahigher level application function.

Call Format

ERR_CODE FDI_ReadProtectionRegisterLock (WORD *prot_lock);


5-50

11/3/98 10:46 AM CHPT5.DOC


Input Elements

None.


API function residing in low-level code that returns the protection lock word.

Error Handling



ERR_NOTRDY The flash device is in the “busy” state. At function entry the flash must be in theread mode and not busy.



None.

Limitations


Output Elements


OutputMethod

status Status return value ERR_CODE ENUM ERR_NONEERR_NOTRDY,andERR_SUSPEND

no byfunctioncall

pLock_reg PR-lock registerdata is referencedvia this pointer

WORD * registerpointer

n/a no byreference

5.4.2.1.16 Write Protection Register Lock

Provides write access to the Advanced+ Boot Block Protection Register lock. This allows ahigher level application function to write protect the PR register.


5-51

11/3/98 10:46 AM CHPT5.DOC


Call Format

ERR_CODE FDI_WriteProtectionRegisterLock (void);

Input Elements

None.


API function residing in low-level code that locks out writes to the user programmable segmentof the protection register by writing the lock word. Status is returned.

Error Handling



ERR_WRITE Flash device write failure.



None.

Limitations


Output Elements


OutputMethod

status Status return value ERR_CODE ENUM ERR_NONE,ERR_NOTRDY,ERR_WRITE, andERR_SUSPEND

no byfunctioncall


5-52

11/3/98 10:46 AM CHPT5.DOC


5.4.2.1.17 Lock Block (Non-FDI Managed Blocks)

This API allows a higher level application function to lock a block in the Advanced+ BootBlock component that is not being managed by FDI.

Call Format

ERR_CODE FDI_LockBlock (DWORD block_addr, BYTE lock_down);

Input Elements


Limit/Range ValidityCheckPerf.?

InputMethod

block_addr The address ofthe physicalblock to belocked

DWORD integer 0 to ((NUM_BOOT_BLOCKS *BLOCK_SIZE)-1) [whereNUM_BOOT_BLOCKS <>0] and((NUM_DATA_BLOCKS–LAST_BLOCK*BLOCK_SIZE) to((LAST_BLOCK *BLOCK_SIZE)-1)

yes by value

lock_down If TRUE, thespecified blockis “locked-down”

BYTE integervalue

TRUEFALSE

yes by value


API function residing in low-level code that locks the block specified by the caller. Thisfunction shall disallow access to blocks managed by FDI. An option shall allow “lockingdown” the specified block. Status is returned.

Error Handling


ERR_PARAM The block input parameter pertains to an FDI-managed block.

ERR_SUSPEND The flash device is in program suspend mode. The lock command cannot beexecuted.



5-53

11/3/98 10:46 AM CHPT5.DOC



None.

Limitations


Output Elements


Limit/Range ValidityCheck Perf.?

OutputMethod

status Status return value ERR_CODE ENUM ERR_NONE,ERR_PARAM,ERR_SUSPEND,andERR_NOTRDY

no by functioncall

5.4.2.1.18 Unlock Block (Non-FDI Managed Blocks)

This API allows a higher level application function to unlock a block in the Advanced+ BootBlock component that is not being managed by FDI.

Call Format

ERR_CODE FDI_UnlockBlock (DWORD block_addr);

Input Elements



InputMethod

block_addr The address ofthe physicalblock to beunlocked

DWORD integer 0 to((NUM_BOOT_BLOCKS* BLOCK_SIZE)-1)[whereNUM_BOOT_BLOCKS<>0] and((NUM_DATA_BLOCKS–LAST_BLOCK*BLOCK_SIZE) to((LAST_BLOCK *BLOCK_SIZE)-1)

yes by value


5-54

11/3/98 10:46 AM CHPT5.DOC



API function residing in low-level code that unlocks the block specified by the caller. Thisfunction shall disallow access to blocks managed by FDI. Status is returned.

Error Handling






None.

Limitations


Output Elements


Limit/Range ValidityCheck Perf.?

OutputMethod


no by functioncall

5.4.2.1.19 Read Lock Status (Non-FDI Managed Blocks)

This API allows a higher level application function to access the lock status of a block in theAdvanced+ Boot Block component that is not being managed by FDI.

Call Format

ERR_CODE FDI_ReadLockStatus (DWORD block_addr, WORD_PTR *pLock_stat);


5-55

11/3/98 10:46 AM CHPT5.DOC


Input Elements



InputMethod

block_addr The address ofthe physicalblock to retrievelock-status

DWORD integer 0 to((NUM_BOOT_BLOCKS* BLOCK_SIZE)-1)[whereNUM_BOOT_BLOCKS<>0] and

((NUM_DATA_BLOCKS-LAST_BLOCK*BLOCK_SIZE) to((LAST_BLOCK *BLOCK_SIZE)-1)

yes by value


API function residing in low-level code that provides the lock status of the block specified bythe caller. This function shall disallow access to blocks managed by FDI. Status is returned

Error Handling






None.

Limitations



5-56

11/3/98 10:46 AM CHPT5.DOC


Output Elements


OutputMethod


No byfunctioncall

pLock_stat Block lock statusis referenced viathis pointer

WORDPOINTER

POINTER FDI_LOCK,FDI_UNLOCK,andFDI_LOCKDOWN

yes by ref.

5.4.2.2 FAST FLASH READ CONFIGURATION

5.4.2.2.1 Fast Boot Block Features Commands

These functions in FDI Release V2.0, provide access to the features provided in the Intel® FastBoot Block product line (28FxxxF3). These functions are only available when the Fast BootBlock component support is enabled with the appropriate compile time option(s).

The Fast Boot Block features in general are enabled by setting the ENABLE_FBB_OPTIONScompile time option to TRUE. The default is disabled.

#define ENABLE_FBB_OPTIONS FALSE

5.4.2.2.2 Set Read Configuration Register (Fast Boot Block)

This API allows a higher level application function to write the Read Configuration Register ina Fast Boot Block component. This allows the various read modes of the component to be setby a calling function.

Call Format

ERR_CODE FDI_SetReadConfig (WORD read_config);

Input Elements


InputMethod

read_config

The value to bewritten to the readconfigurationregister

WORD integer n/a yes by value


5-57

11/3/98 10:46 AM CHPT5.DOC



API function residing in low-level code that writes the read configuration register with the wordspecified by the caller. Defines provide all possible bit-field settings for configuration. Status isreturned.

Error Handling




None.

Limitations

Only valid for Fast Boot Block components.

Output Elements


OutputMethod

status Status return value ERR_CODE ENUM ERR_NONE andERR_NOTRDY

no byfunctioncall

5.4.2.2.3 Get Read Configuration Register (Fast Boot Block)

This API allows a higher level application function to get the current state of the ReadConfiguration Register in a Fast Boot Block component. This allows a calling function todetermine in which read mode the component is operating.

Call Format

ERR_CODE FDI_GetReadConfig (WORD *pRead_cfg);

Input Elements

None.


API function residing in low-level code that shall return the contents of the read configurationregister.


5-58

11/3/98 10:46 AM CHPT5.DOC


Error Handling




None.

Limitations

Only valid for Fast Boot Block components.

Output Elements



OutputMethod

status Status return value ERR_CODE ENUM ERR_NONE andERR_NOTRDY

no byfunctioncall

pRead_cfg Read configurationdata is referencedvia this pointer

WORD PTR integerpointer

n/a no by ref.

5.4.2.3 BACKGROUND MANAGER SUB-SYSTEM

5.4.2.3.1 Background Task

BKGD_Task is the FDI Background Manager which performs any modifications/writes toflash. The BKGD_Task is pending on data available in the Data Queue, and then reads thehighest priority Command Queue element. BKGD_Task disables system interrupts beforeissuing program or erase commands. BKGD_Task then polls interrupts while waiting for theprogram or erase to complete. If an interrupt is asserted during this time, BKGD_Task suspendsthe flash program or erase in progress, and then relinquishes the system to the interrupting task.Once the interrupt handler has completed executing, BKGD_Task continues until it completes,or until it is interrupted again by another interrupt. BKGD_Task continues in this fashion untilthe Data Queue is empty. BKGD_Task also determines when a reclaim is necessary bychecking predetermined thresholds. If the available free space is below the threshold,BKGD_Task either requests reclaim to be started or enables reclaim to begin.

Background Task Call Formatvoid BKGD_Task(void);


5-59

11/3/98 10:46 AM CHPT5.DOC


Input Elements

Not applicable.


When pending on the sem_cntrl_sync semaphore, BKGD_Task looks for the highest priorityitem in the Data Queue. When an item arrives in the Data Queue, BKGD_Task gets a pointer tothe item by calling Q_Peek. BKGD_Task uses the Data Queue command information pointedto by Q_Peek to modify the flash media. BKGD_Task determines the location of the data inflash by calling DataFind if the data is not already opened. BKGD_Task modifies the DataHeader status field if the operation is a DELETE sub-command. For the cases ofWRITE_REPLACE and WRITE_MODIFY commands, BKGD_Task determines the storagemethod of the data, either a Multiple Instance unit, a Single Instance unit, or a fragmented dataunit.

If the data is in a Multiple Instance unit and there is available space in the unit, BKGD_Taskwrites a new instance of the data within the existing Multiple Instance unit. The old datainstance in the unit is marked invalid. If there is not enough space in the Multiple Instance unit,BKGD_Task creates a new unit with corresponding Unit Header with the replacement ormodified data. The old Multiple Instance unit and associated Unit Header is invalidated.

If the storage method is a Single Instance unit and there is available space, BKGD_Task createsa new unit with corresponding Unit Header with the replacement or modified data. The oldSingle Instance unit and associated Unit Header is invalidated.

If the storage method is a fragmented data unit, this requires writing the replacement ormodified data to a new unit, corresponding and sequence and group tables. Unit Header.BKGD_Task recreates the Sequence Table and associated Unit Header to reflect the changeddata. In the case of the WRITE_APPEND command, BKGD_Task determines the storagemethod of the data. If the method is a Multiple Instance unit, BKGD_Task creates a new unitwith the additional data added. The old unit and associated Unit Header is invalidated. If thestorage method is a fragmented data unit, BKGD_Task creates a new unit and Unit Header withthe additional data and updates the Sequence Table.

Before a data write takes place, it is necessary to determine if enough space exists on the flashmedia. If the data size is greater than the available space above the SYSTEM_THRESHOLD,BKGD_Task checks the condition of the RECL_Done semaphore. If RECL_Done semaphoreis asserted, BKGD_Task asserts the RECL_Request semaphore and resets the RECL_Donesemaphore. The write command completes if the data size fits within the available space andthat headroom exists between the SYSTEM_THRESHOLD and the FDI_THRESHOLD.Otherwise, BKGD_Task is pending on the RECL_Done semaphore. Once the reclamationfunction asserts the RECL_Done semaphore, BKGD_Task continues with the write or deleteoperation.

Before modifying flash media, BKGD_Task determines if there is enough time to execute thecommand. BKGD_Task delays if there is not enough time until the next interrupt occurs. A callto the low-level write function executes the command from within RAM. If an error occurs


5-60

11/3/98 10:46 AM CHPT5.DOC


during this low-level function, BKGD_Task gives an error semaphore to indicate the error tothe system. If the low-level operation completes, a call to Q_Remove removes the item fromthe queue and BKGD_Task is again pending on items in the Data Queue.

Error Handling

If an error is returned the semaphore describing the error and location is given to the system.


None.

Limitations

Not applicable.

Output Elements

Not applicable.

5.4.2.3.2 Low-Level Interrupt RAM

IntelXxLowLevelRAM exists in RAM and allows a real-time multi-tasking system flash “readwhile write” capabilities.

Low-Level RAM Call FormatHW_ERROR IntelX16LowLevelRAM (DWORD dest_addr, DWORD src_addr,

BYTE_PTR buffer, WORD length, HW_CMD command);

HW_ERROR IntelX8LowLevelRAM (DWORD dest_addr, DWORD src_addr, BYTE_PTR buffer, WORD length, HW_CMD command);


5-61

11/3/98 10:46 AM CHPT5.DOC


Input Elements

The input parameter structure is defined as follows:


Data Rep. Limit /Range

ValidityCheck Perf.?

InputMethod

dest_addr Beginningaddress of flashmedia data

DWORD address no by value

src_addr DWORD address by value

buffer Pointer to buffercontaining datafor programming

BYTE PTR array of bytes no byreference

length Number of bytesif programming

WORD byte counter 0–0XFFFF yes by value

command Either programor erase/copy

HW_CMD command flag 0–1 yes by value


IntelXxLowLevelRAM disables the system Task Scheduling so the scheduler does not interruptthe write process. The Data Queue still contains the current data element being acted upon.Next, IntelXxLowLevelRAM disables the interrupts. This is the point of worst case interruptlatency, after the interrupts have been disabled. IntelXxLowLevelRAM calculates the “timeuntil next interrupt” using the last interrupt time-stamp and the current time. There must beavailable time for a minimum run, overhead and command suspend time. If there is not enoughtime, IntelXxLowLevelRAM re-enables the interrupts and the task scheduler.IntelXxLowLevelRAM then delays until the next interrupt occurs and the process begins again.

If enough time exists, IntelXxLowLevelRAM allows the program or erase command to start orcontinue the operation. Checking the status register verifies the command is complete.

If the operation is a programming command, the byte counter is decremented and the addresspointer increments to the next location. IntelXxLowLevelRAM checks the status register forerrors if there are no more bytes to write and sets the status variable to indicate correctcommand completion or error. Verification of the status register ensures the completion of theoperation. IntelXxLowLevelRAM analyzes the available time if the command has notcompleted. IntelXxLowLevelRAM sets the status variable to the suspended state if there is notenough time to poll the status register or an interrupt has occurred. This is the point of best caseinterrupt latency, after the interrupt polling. IntelXxLowLevelRAM suspends the program orerase command and waits for the operation to complete. IntelXxLowLevelRAM re-enables theinterrupts and the task scheduler. The system will vector to the address of the interrupt handler.After the system interrupt completes and the Background Manager is allowed CPU time, theprocess is continued until interrupted again or until complete.


5-62

11/3/98 10:46 AM CHPT5.DOC


If the status variable indicates that the program/erase command was suspended,IntelXxLowLevelRAM disables the Task Scheduling, disables the interrupts and verifies theavailable time. IntelXxLowLevelRAM resumes the previously interrupted command until thevariable status indicates completion or error.

Error Handling

IntelXxLowLevelRAM returns the status value to the calling function.


None.

Limitations

Not applicable.

Output Elements


Data Rep. Limit / Range ValidityCheckPerf.?

OutputMethod

status Returns the status of thecommand upon completion

BYTE unsigned char 0 - okay1 - suspended2 - an error

no functioncall

5.4.2.3.3 Reclamation Management

Reclamation is the process used to make invalid regions of flash memory available for reuse forparameter block storage. The FDI system uses a spare block for reclaiming valid headers anddata. This spare is not used for parameter storage but is used for reclamation only. When thereis no more room to write updated or new data, the system finds a block with the greatestamount of invalid space and finds the spare block.

Figure 5-12 displays the reclaim candidate and the spare block prior to the reclaim process.


5-63

11/3/98 10:46 AM CHPT5.DOC


LogicalBlock #4

Valid andInvalid Dataand Headers

Spare Block

status ="erased"

PhysicalBlock #2

PhysicalBlock #7

Block withthe greatestamount of

invalidspace

FDI5-11

Figure 5-12. Reclaim Candidate and Spare


5-64

11/3/98 10:46 AM CHPT5.DOC


Transfer of valid data and headers from the block being reclaimed to the spare block is the nextstep. The status of the spare block indicates the valid data is being transferred. Figure 5-13demonstrates this process. Notice invalid data and headers do not transfer to the spare block.

LogicalBlock #4

Valid andInvalid Dataand Headers

PhysicalBlock #2

PhysicalBlock #7

transfer only validdata and headers

Spare Block

status ="recover"

FDI5-12

Figure 5-13. Transferring Valid Data to the Spare Block


5-65

11/3/98 10:46 AM CHPT5.DOC


Upon completion of the data transfer the next step is to prepare the spare block to logically takethe original block’s place. The FDI writes the original block’s logical block number to the spareblock’s block information structure. For power-off recovery purposes the status of the spareblock indicates the original block is about to be erased. The old block begins to erase after allvalid data exists in the spare block. Figure 5-14 shows the status of the spare and reclaim blocksat this time.

Unknownstate/content

PhysicalBlock #2

PhysicalBlock #7

Place thelogical block

number of thereclaimed

block into thespare

LogicalBlock #4

status ="erasing"

FDI5-13

Figure 5-14. Update Status for Erasing of the Reclaim Block


5-66

11/3/98 10:46 AM CHPT5.DOC


Figure 5-15 shows the intermediate step of setting the block status for the current block to“invalid” before erasing it. This step is required for power loss recovery.

PhysicalBlock #2

Markcurrentstate toinvalidbeforeerase

FDI5-14

Figure 5-15. Erasing the Reclaim Block


5-67

11/3/98 10:46 AM CHPT5.DOC


When the erase of the original block completes, the status of the spare block changes to indicatethat the block is now a writeable block. All of the valid data and headers have been transferredsuccessfully and the old locations have been erased. The new status of the blocks is shown inFigure 5-16.

New SpareBlock

status ="erased"

PhysicalBlock #2

PhysicalBlock #7

Ready foranother

reclamation

Contains validheaders and

data

LogicalBlock #4

status ="write"

FDI5-15

Figure 5-16. Status after Reclamation

Reclamation Call Formatvoid RECL_Task(void);

Input Elements

Not applicable.


Flash is byte alterable. However, to rewrite a flash location which has already been writtenrequires a block erase. Flash blocks are typically large – several Kbytes. Any valid informationin a block that will be erased, must be moved from the block before “reclaiming” invalid flashmemory by erasing the block. Reclamation copies all the valid data from a block with invaliddata to reclaim to an empty “spare” block and then erases the block.


5-68

11/3/98 10:46 AM CHPT5.DOC


Initialization installs reclamation as a task which runs in the background. The reclamation taskpends on the RECL_Enable semaphore. When this semaphore is asserted by the system throughthe Foreground API FDI_ReclaimEnable function, the reclamation process begins. Thefollowing semaphores are used to control reclamation:

RECL_Request: BKGD_Task uses this semaphore to request the system to enablereclaim at the next available instant.

RECL_Enable: The system asserts this semaphore to grant reclaim permission. Thereclamation function awaits this binary semaphore.

RECL_Done: The reclamation function uses this semaphore to indicate thecompletion of the reclamation process. If BKGD_Task is pendingon the RECL_Done semaphore, this indicates that memory is fulland that it cannot continue the write or delete operation untilreclaim is complete.

Reclamation selects the block to be reclaimed by finding the block with the least amount oferase counts or the highest percentage of dirty space. Reclaiming the block with the leastamount of erase counts distributes the erases across the blocks for maximum reliability. Thisprocess is called wear-leveling.

Reclamation first reads all the erase count information stored in each block and stores them in alocal array and calculates the difference between the fewest erase counts and the most erasecounts. If the difference is greater than a pre-defined value, reclamation reclaims the block withsmallest erase count. If the difference is less than or equal to a pre-defined value, reclamationreads the invalid count of each block from the Logical Block table and selects the block withmost invalid data.

Once reclamation selects the block to reclaim, reclamation writes the erase count value of thatblock as a parameter with a unique identifier directly bypassing the Data Queue.

Then reclamation finds the spare block from the Logical Block table and marks the spare blockto indicate the start of data transfer.

After finding the spare block, reclamation transfers the valid units from the reclaim block to thespare block. Once the data transfer is complete, reclamation writes the logical block numberand the physical block number of the reclaimed block into the block information area of thespare block.

After completion of the data transfer, reclamation marks the spare block to indicate that theerase of the old block has begun.

Reclamation then erases the old block. Upon erase completion, reclamation retrieves the cyclecount by doing a parameter read, increments it by one and writes this value into the blockinformation area of the reclaimed block. The reclamation function then writes the completeblock information into the spare block and marks it as a valid block. Then reclamation deletesthe parameter cycle count to free up its RAM space. Finally, reclamation updates the LogicalBlock table and asserts the RECL_Done semaphore.


5-69

11/3/98 10:46 AM CHPT5.DOC


Error Handling

If during the process there is an error, a special semaphore that indicates that an error hasoccurred in the system is set by reclamation.


None.

Limitations

Not applicable.

Output Elements


ValidityCheckPerf.?

OutputMethod

RECL_Done Indicate the completion ofreclamation to the pendingbackground write task if any

semaphore no byreference

reclaimError Indicate an error occursduring the reclamationprocess

semaphore no byreference

5.4.2.4 BOOT CODE MANAGER SUB-SYSTEM

5.4.2.4.1 Power On Initialization

The initialization process initializes all the FDI control structures and performs necessarypower loss recovery.

Initialization Call FormatERR_CODE FDI_Init(void);

Input Elements

None.


5-70

11/3/98 10:46 AM CHPT5.DOC



FDI_Init calls the InitUnit routine to validate all the blocks and to validate all the units of eachblock. FDI_Init also updates all the control structures and the global variables used by the FDIfunctions. InitUnit scans through all the Unit Header entries to build the Data lookup table byscanning through all the Unit Header entries. InitUnit also builds the Logical Block Tablescanning through the Block Information entries at the end of each block. Finally, FDI_Initinstalls the Background Manager task as well as the reclamation task.

Error Handling

Any error during the initialization process will be returned to the application layer.


None.

Limitations

Care must be taken to avoid repeated calls to FDI_Init from the application or OS interface.Multiple calls to FDI_Init can create undesired results, such as trashing existing globalvariables.

Output Elements


ValidityCheckPerf.?

OutputMethod

error Refer to the returncodes in Section 5.5

ERR_CODE ENUM no function call

5.5 RETURN ERROR CODESThe following list of error codes may possible be returned from any interface function of theFDI system

Return Error Code Meaning

ERR_NONE 0 Indicates command was successful

ERR_READ 1 Indicates an error reading the flash component

ERR_WRITE 2 Indicates an error in the status register when writing to the flashcomponent. Potentially due to a locked block if the flash componenthas this capability.

ERR_PARAM 3 Indicates an incorrect parameter to a function.


5-71

11/3/98 10:46 AM CHPT5.DOC


Return Error Code Meaning

ERR_OPEN 4 Indicates an operation is attempted on an open parameter or datastream when the data item should be closed.

ERR_EXISTS 5 Indicates the attempt to create a parameter or data stream thatalready exists.

ERR_NOTEXISTS 6 Indicates an error in attempting to perform an operation on aparameter or data stream that does not exist.

ERR_SPACE 7 Indicates that there is no available clean flash space left. Thisindicates that a manual reclaim needs to occur before re-attemptingthe command.

ERR_NOTOPEN 8 Indicates an error in performing an operation on a parameter or datastream that is not open but must be to complete the operation.

ERR_ERASE 9 Indicates an error erasing the flash block. Potentially due to a lockedblock if using flash with this capability.

ERR_MAX_EXISTS 10 Indicates that the maximum number of data streams or parametersexists.

ERR_FORMAT 11 Indicates the detection of an error in the component format structures.

ERR_MEDIA_TYPE 12 Indicates the component type is identified as a component that isunsupported.

ERR_NOT_DONE 13 Indicates that a function was aborted before completion due to anabort capability such as that used in the REVERSE_SEEK_SETUP.

ERR_WRITE_PROTECT 14 Indicates the media is write protected. Returned at in initialization(which should not be treated as an error, only a flag) and when a writeis attempted.

ERR_FLASH_FULL 15 Indicates that the flash media is full.

ERR_SYSTEM 16 Indicates that a system error has occurred and the FDI softwareshould be re-initialized.

ERR_MAX_OPEN 17 Indicates that the maximum number of objects open consecutively hasalready been reached. This is determined by the MAX_OBJECTSdefine in type.h.

ERR_INIT 18 Indicates that an error has occurred during initialization due to anincorrect setup combination or other fatal error. Requires systemreset.

ERR_Q_FULL 19 Indicates the Data Queue is full and cannot accept additionalelements.

ERR_TIMEOUT 20 Indicates that a time out occurred during program or erase of the flashcomponent.

11/3/98 10:48 AM CHPT6.DOC


E6

Porting

E

6-1

11/3/98 10:48 AM CHPT6.DOC


CHAPTER 6PORTING

6.1 INTRODUCTIONFDI is a filing system and flash media manager targeted for embedded systems that requirereal-time parameter and data stream storage handling capabilities in a system that stores codeand data within the same flash component. These applications include, but are certainly notlimited to, cellular phones, pagers, radio phones, and set top boxes.

The Flash Data Integrator, FDI, tracks the creation and modification of data stream files andparameters in flash memory. Through the use of intelligent software and smart/judicial use ofsystem resources, FDI does this within the same component from which the main code isrunning. Furthermore, it does it using conventionally-blocked flash, which means greaterflexibility (no hardware limits on the code and data sizes/boundaries) and economy (standardflash means higher volume products which yield economies of scale).

This chapter discusses the steps, issues, and concerns of adapting (porting) FDI for yourapplication. Also discussed are the software modules that are part of the FDI package and howto port this software to your system and hardware setup. Since many embedded systemstypically have a small amount of code storage space as well as more limited system resources(e.g., DRAM), some functionality may be included or excluded as a compile time option.Familiarity with programming and the general contents of the reference software is assumed.

PORTING E

6-2

11/3/98 10:48 AM CHPT6.DOC


6.1.1 Introduction to the Source CodeFigure 6-1 provides an overview of the software components and how these componentsinteract with the existing system software. Please refer to Section 3.3.1 for a functionaloverview of FDI.

Key Press

MAC ISR

FDI Foreground APIs:open, close, read,

write, delete

Interrupt Service Routines Tasks

Reclaim

FDI BackgroundManager: write, delete

O/S Kernel

FDI5_1

Figure 6-1. Simplified System Software Architecture Using FDI

6.1.1.1 FOREGROUND API INTERFACE

The Foreground API functions receive storage and read commands from other tasks in thesystem. The system calls the Foreground API function with a command and data. TheForeground API function then either writes the command and data into a RAM queue foroperations which modify flash or executes the command directly for commands which do notmodify flash. The Foreground API functions are the application interface for storing EEPROMdata types, factory data, network parameters and user-alterable data to the flash media.

6.1.1.2 BACKGROUND MANAGER AND FLASH MEDIA MANAGEMENT

The FDI Background Manager controls the actual writes into the flash media. The BackgroundManager awaits the arrival of items into its prioritized Data Queue and then extracts the highestpriority item to act upon. When there is CPU time available, the Background Manager readsfrom the queue and determines the information’s location in flash. During flash programmingand erase operations, the Background Manager disables and polls interrupts. If an interruptoccurs, the Background Manager suspends the program/erase in progress, and then relinquishes

E PORTING

6-3

11/3/98 10:48 AM CHPT6.DOC


the flash to the interrupt task. Once the interrupt handling is complete, the BackgroundManager continues until it completes, or until interrupted again by other interrupts. TheBackground Manager resumes the program/erase from where it was suspended and continues inthis fashion until the RAM queue is empty.

The Background Manager is also responsible for initiating the Reclaim Task’s reclamation ofinvalid (deleted or superseded) data. Reclamation occurs upon a predetermined free spacetrigger, or a user-defined percentage of a block that has been dirtied, or when there is notenough free space to store a new piece of data. The Background Task asks for permission fromthe system and, when granted, Reclaim Task executes the reclamation process to free up invalidregions of flash memory and makes them available for reuse

6.1.1.3 LOW-LEVEL DRIVER (LLD)

The LLD handles two basic functions. First it handles the particulars of your flash hardwareinterface, and therefore requires code modification. Second, it does the basic flash program anderase routines. The small erase and program routines will be copied to and operate primarilyfrom RAM. This is to allow the primary system code to be “paused” during a flash program orerase since all of the data, including any code running there, in a conventional flash part cannotbe concurrently read during a program or erase sequence. When the program or erasecompletes, or a system event (such as a system interrupt) causes the program or erase to besuspended, control is returned to code running from the flash.

6.2 GETTING STARTEDThe first step toward porting FDI to your system is to determine your system resources andrequirements. The following section outlines the general steps necessary, implementationrequirements, and considerations.

6.2.1 General Porting to Your SystemThe following are listed in the order they should be accomplished:

• Manipulate defines and compile time options in type.h to reflect your implementation.Special consideration should be used when porting the task and semaphore macros for youroperating system’s particular implementation of multi-tasking. See Section 6.5, ModifyingHeader Files, especially Section 6.5.1.1, TYPE.H, for more information on this subject.

• Modify the low-level software to adapt it to your system and flash interface. Please refer toSections 6.8, Replacing Low-Level Driver Interface Functions (LOWLVL), and 6.9,Understanding Defines and Macros in the Low-Level Driver, for more information onpower control.

• Adapt the existing or create new make files for your particular development environment.

• Manipulate any other special requirements.

PORTING E

6-4

11/3/98 10:48 AM CHPT6.DOC


• Determine the appropriate error handling for your system.

• Add interface calls for storage of parameter and data streams to application software.

• Evaluate standard library calls to see if you wish to replace them (memorySet,memoryCopy, memoryCompare) with O/S calls.

6.2.2 Implementation Considerations

6.2.2.1 GENERAL CONSIDERATIONS

There are several operational characteristics of FDI:

• The file system allows a single parameter or data stream to remain open at any given time.Other parameters and data streams may be read/updated during this time, however, eachaccess to other data includes the overhead of finding the data and indexing into the data.

• The file system allows append capability on a per-byte basis.

• The file system allows replacement of data on a per-byte basis, but does not allow theinsert or deletion of data within a data stream or parameter.

• The format of the flash is typically going to be performed at manufacturing. Duringimplementation and evaluation, the format routine will need to be included as part of thesystem to allow issues to be worked out. Format can be included or excluded using acompile option. Format is not considered a run-time feature and is not considered in anybaseline ROM and RAM calculations.

• RAM usage reduction can be accomplished by reducing the number of parameter and datastream identifiers. Parameters can be grouped into structures where appropriate. RAM canalso be decreased through changing the size of the RAM Queue, if data rates are slow.

• The current low-level interface has been designed using a flat memory model withunlimited access to the flash memory array. If your architecture requires the use ofsegmented memory or memory windowing into the flash, additional modifications to thelow-level functions will be required.

• Data stored in a single instance or fragmented structures is stored on a granular unit basis.This means that file size is tracked to a granularity resolution for these storage types. Thisrequires knowledgeable handling of parameters and data streams. Most parameters are of apre-determined structure so the size is not requested from the filing system. Data streamsare often of undetermined size so the size is usually requested from the filing system. SinceFDI does not track data streams to a byte granularity, this must be resolved in theapplication layer. This is done by implementing an internal data stream structure trackingmethod to allow the END OF FILE (EOF) to be determined by the application.

• There are a maximum number of parameters/data storage streams allowed at any giventime (set at compile time).

E PORTING

6-5

11/3/98 10:48 AM CHPT6.DOC


6.2.2.2 MULTI-TASKING CONSIDERATIONS

• FDI has been designed utilizing the features of a multi-tasking operating system. If youroperating system does not handle multi-tasking, additional code modification will benecessary.

• Time slicing—preemptive vs. round robin

The current FDI software has been tested thoroughly in a preemptive prioritized taskscheduling mode. It has not been tested in a round-robin task scheduling mode. Issues mayarise if your operating system environment utilizes this mode.

• Operating system requirements—semaphores (binary/mutex)

Semaphores are a mechanism used for synchronization and communication between tasks in amulti-tasking system. They are used to indicate events, as well as to provide mechanisms toshare data and protect critical processing. There are two types of semaphores utilized in the FDIsoftware. These include binary or “synchronized” semaphores and mutual exclusion (mutex)semaphores.

The mutual exclusion semaphore is used to interlock access to shared resources. The mutualexclusion semaphore provided by VxWorks* is a binary semaphore that has been optimized toaddress problems inherent to mutual exclusion. These include priority inversion, deletionsafety, and recursive access to resources.

The binary semaphores available in VxWorks are similar to semaphores available in mostoperating systems and are used for task coordination. If your operating system does not provideboth of these types of semaphores, you need to use a mechanism to emulate these. The compiletime option VXWORKS_SEM_MTX when defined enables the VxWorks semaphores. Byremoving (not defining) that option will enable emulation of the mutex semaphores in FDIsource release 2.0 and up.

6.3 FDI REQUIREMENTS

6.3.1 FDI Operational RequirementsThe following is a list of requirements for the operational characteristics of the FDI software.

• Flash Code size: 20 KB–40 KB, depending on enabled features

• RAM Footprint = 2 KB–3 KB (without high-speed data streaming), see Chapter 4 for RAMguidelines for data streaming

• Recover media from catastrophic power loss situations

• Single directory, single data stream open at one time

• Optional format capability

PORTING E

6-6

11/3/98 10:48 AM CHPT6.DOC


6.3.2 FDI Development Requirements

• Ability to boot and execute from RAM for easy debug

• Extra RAM is required so that the FDI code can be run from RAM for easy debug. Theamount of extra RAM equals the compiled size of the FDI code.

6.4 FILE BREAKDOWNThe following table gives an overview of which files in the FDI directories require modificationfor your implementation. Each file is described more completely below. Files existing in theFDI\LOWLVL directory are the low-level files necessary for an example FlashFile™ memoryx8 or Advanced Boot Block x16 implementation on an EST360 platform using a linear memorymodel. Your implementation will need to replace or modify the functionality in the low-level asindicated in Section 6.8, Replacing Low-Level Driver Interface Functions.

Table 6-1. TT_FileListRequired Source Code File Listing

Path Filename Modifications Necessary?

\INCLUDE FDI_EXT.H NO

FDI_INT.H NO

ERROR.H NO

TYPE.H YES - adapt to operating system

QUEUE.H NO

LOWLVL.H NO

\FDI FDI_EXT.C NO

FDI_INT.C NO

FDI_FMT.C NO

FDIRECLM.C NO

FDIBKGND.C NO

\LOWLVL LOWLVL.C YES - adapt to platform and media type

\COMMON QUEUE.C NO

E PORTING

6-7

11/3/98 10:48 AM CHPT6.DOC


6.4.1 File Descriptions

FDI_EXT.H

This file contains structures, defines, and prototypes for the Flash Data Integrator (FDI)application interface. The user application should include this file to reference any of the FDIAPI functions. This file includes all user interface definitions and does not requiremodification.

FDI_INT.H

This file contains the structures, defines, and prototypes needed internally within the FDIsoftware. The user does not need to directly include this file from the application software;however, it should remain as part of the system build. This file does not require modification.

ERROR.H

This file contains the structures, definitions, and prototypes needed for error handling. The userapplication may reference the error code definitions in this file; however, this file does not needto be included directly from the user application. This file does not require modification.TYPE.H

This module contains compile options, defines, macros, and definitions for variable types. Thisfile is required as part of the file system. This file should be carefully modified to incorporateall compile time options and operating system interfaces required by the user application. Theuser does not need to directly include this file from the application software; however, it shouldremain as part of the system build.

QUEUE.H

This file contains structures, definitions, and prototypes needed for queue handling. The userdoes not need to directly include this file from the application software; however, it shouldremain as part of the system build. This file does not require modification.

LOWLVL.H

This file contains function prototypes and structure definitions for the low-level software layer.The user does not need to directly include this file from the application software; however, itshould remain as part of the system build. This file does not require modification.

FDI_EXT.C

This file contains the interface functions for the FDI Foreground API software. This file doesnot require modification.

PORTING E

6-8

11/3/98 10:48 AM CHPT6.DOC


FDI_INT.C

This file contains all support functions for the FDI Foreground API software software. This filedoes not require modification.

FDI_FMT.C

This file contains the FDI format function and a termination function required to execute theformat. This function is required as part of the file system only if the user application will havethe option to re-format the flash if a catastrophic error were to occur. This file does not requiremodification.

FDIRECLM.C

This module contains the Reclaim Task and all functions necessary to perform reclaim. Thisfile is required as part of the file system and does not require modification.FDIBKGND.C

This file contains the Background Manager and all functions necessary to execute commandsplaced in the RAM queue. This file is required as part of the file system and does not requiremodification.

LOWLVL.C

This file contains low-level media support: flash control for Initialization, Read, Write andErase. The flash algorithms are required for FDI to operate. The user needs to adapt theseroutines to suit the interface/type of media used by their application. This file is required as partof the file system and requires modification.

QUEUE.C

This file contains the management software for the RAM queue. The queue software managesdata and commands in RAM while the background manager is waiting for processing time.This file is required as part of the file system and does not require modification.

6.5 MODIFYING HEADER FILESThe following outlines all of the defines in the user-modifiable portion of the FDI filing system.The user should only need to change those defines found in the type.h file. Numbers used inthis chapter as define values are not default values, but examples of what the #defines can beset to.

E PORTING

6-9

11/3/98 10:48 AM CHPT6.DOC


6.5.1 Include

6.5.1.1 TYPE.H

#define LOCAL_ALLOC

This define should be commented out if the user wishes to use the operating system’sMALLOC and FREE algorithms. Keep this define to use the FDI-provided functions

#define FLASH_START_ADDRESS 0X00C00000

This defines the first memory location of the flash chip. During debug, the “flash” memory maybe mapped to RAM and this address may need to change.

#define NUM_BOOT_BLOCKS 2

This define indicates the number of blocks that exist at the beginning of the flash componentthat are not part of the data partition and should be skipped for all calculations.

#define NUM_DATA_BLOCKS 6

This define indicates the number of blocks that will be used for the FDI data partition. Theseblocks immediately follow the number of blocks defined in the NUM_BOOT_BLOCKS. Thespare block should be included in the count.

#define NUM_PARAMETERS 100

This define indicates the maximum number of parameter identifiers that will be used by theuser application. Each parameter identifier utilizes a byte of RAM. In a low RAM usage model,parameters that are not accessed often can be combined into a single parameter (defined by astructure) to assist in reducing RAM.

#define NUM_STREAMS 10

This define indicates the maximum number of data stream identifiers that will be used by theuser application. Each data stream identifier utilizes a byte of RAM.

PORTING E

6-10

11/3/98 10:48 AM CHPT6.DOC


#define UNIT_GRANULARITY 128

This define indicates the number of bytes in each unit allocated for data. Multiple units can beallocated for a data instance or fragment. The maximum that can be allocated per data instanceor fragment is determined by the MAX_UNITS_PER_FRAG define described below. Any datainstance or fragment will be a minimum size of UNIT_GRANULARITY and a maximum of(UNIT_GRANULARITY * MAX_UNITS_PER_FRAG) depending on the amount of spaceavailable in any given block. Unit Granularity must be a power of 2. The range recommendedis from 128 bytes (minimum recommended) to 512 bytes. Unit granularity should be chosenthrough close evaluation of parameter and data stream storage needs. If the majority of storageneeded is small parameters. Unit granularity can be fairly large because the overheadintroduced by the multiple instance structure is very low. If the majority of storage needsconsist of data streams, the unit granularity can remain fairly high. If a large number ofparameters are close to the unit granularity in size, unit granularity should be slightly largerthan these parameters in size. Determining the “perfect” value requires intimate knowledge ofyour particular storage needs. Intel can assist you in determining the correct granularity size foryour application.

#define SYSTEM_THRESHOLD FDI_THRESHOLD

This define indicates the threshold at which a reclaim should be initiated. The reclaim isinitiated automatically if the AUTO_RECLAIM compile option is TRUE. The reclaim isrequested through the SEM_ReclaimRequest semaphore if the AUTO_RECLAIM compileoption is FALSE. Once the reclaim is requested, the user application should enable the reclaimas soon as possible through the FDI_ReclaimEnable function. The SYSTEM_THRESHOLDmust be greater than or equal to the FDI_THRESHOLD. Be careful when makingmodifications to this variable, but SYSTEM_THRESHOLD can be set to a multiple of FDITHRESHOLD. If you find that the system is reclaiming too often, lower theSYSTEM_THRESHOLD.

#define FDI_QUEUE_SIZE 1024

This define indicates the maximum number of bytes of RAM that may be used by the queue.Once the amount of data in the queue reaches this size, an ERR_QUEUE_FULL is returned tothe user. Each OEM must analyze the maximum data rate to flash along with the processingtime available for the Background Manager to determine the appropriate queue size. Intel canassist you in determining the optimal queue size for your application.

#define FDI_RAM_START 0X000000

When set to 0x000000, the FDI code assumes that the user wishes to load the code to RAM fordebug purposes. RAM space will be allocated either with the FDI-provided alloc function, orwith the operating system’s malloc function.

#define BLOCK_SIZE 0x2000

This define indicates the number of bytes in the erase block for the blocks being used for theFDI data partition. Setting this define to 0x2000 indicates the block size is 8 KB, setting thisdefine to 0x10000 indicates the block size is 64 KB.

E PORTING

6-11

11/3/98 10:48 AM CHPT6.DOC


#define UNIT_GRANULARITY 128

#define RECL_PRIORITY 190

This define indicates the relative priority of the Reclaim Task. Priorities in the test systemranged from 0–255 with 0 as the highest priority. The Reclaim Task should be a relatively lowpriority. All other tasks that interface to the FDI API should be of higher priority than theReclaim Task.

#define RECL_STACK_SIZE 0x2000

This define indicates the maximum number of bytes allocated for the local stack of the ReclaimTask.

#define BKGD_PRIORITY 180

This define indicates the relative priority of the Background Manager. Priorities in the testsystem ranged from 0–255 with 0 as the highest priority. The Background Manager should bemedium to low priority, but should be a higher priority than the Reclaim Task. All other tasksthat interface to the FDI API should be of higher priority than the Background Manager.

#define BKGD_STACK_SIZE 0x3000

This define indicates the maximum number of bytes allocated for the local stack of theBackground Manager.

#define MAX_NUM_UNITS_PER_FRAG 3

This define indicates the maximum number of granular units that should be used for a datainstance or fragment. In a system that is using large data but never modifying that data, thisnumber should be large. In a system that is performing modifications on medium to large dataon a regular basis, this number should be relatively small. Any data instance or fragment willbe a minimum size of UNIT_GRANULARITY and a maximum of (UNIT_GRANULARITY *MAX_UNITS_PER_FRAG) depending on the amount of space available in any given block.

#define MIN INSTANCES 3

This define indicates the minimum number of instances that must fit into a granular unit beforeFDI chooses the multi-instance structure for storage of the data. This allows you to tailor thedata storage characteristics to your particular needs.

PORTING E

6-12

11/3/98 10:48 AM CHPT6.DOC


The following set of defines characterize the systems data access. Make sure to modify these tofit your system setup.

typedef unsigned char BYTE

Should be set to reflect 8-bit wide unsigned data.

typedef unsigned int WORD


typedef unsigned long DWORD


typedef VOID * VOID_PTR

Should be set to reflect a pointer to unsigned data of undetermined width.

typedef BYTE* BYTE_PTR

Should be set to reflect a pointer to 8-bit wide unsigned data.

typedef WORD* WORD_PTR


typedef DWORD* DWORD_PTR


typedef BYTE* BYTE_BITMASK

Should be set to reflect an 8-bit wide bit mask.

typedef VOID_PTR* VOID_PTR_PTR

Should be set to a void pointer to a pointer.

typedef WORD* IDTYPE

Should be set to reflect 16-bit unsigned data.

typedef VOID* SEM_ID

This define does not currently exist within the FDI reference code. It is supplied by theVxWorks development environment used to develop this code. It is a handle returned by thesemaphore creation function and used in all of the semaphore macros defined below. You willneed to add the appropriate typedef similar to the above to equate SEM_ID to be equal to thehandle type returned by the semaphore creation routine in your operating system.

E PORTING

6-13

11/3/98 10:48 AM CHPT6.DOC


The following set of macros characterize the functions used through the operating system.Make sure to modify these to fit your operating system setup.

#define MALLOC (x) malloc (x)

This define is a macro to allow the user application to change which function to call when amemory malloc should occur. This function must be changed to refer to your operating systemcall or the FDI-provided routine.

#define FREE (x) free (x)

This define is a macro to allow the user application to change the function to call whenpreviously allocated memory is no longer needed and should be released back into the memoryheap. This function must be changed to refer to your operating system call or the FDI-providedroutine.

#define SEM_TRY_WAIT (a) semTake (a, NO_WAIT)

This define is a macro to allow the user application to change the function to call when trying totake a semaphore without waiting. The semaphore identifier is denoted by “a” and is of typeSEM_ID. This function must be changed to refer to your operating system call to perform thisfunction.

#define SEM_WAIT (a) semTake (a, WAIT_FOREVER)

This define is a macro to allow the user application to change the function to call when trying totake a semaphore with an indefinite wait. The semaphore identifier is denoted by “a” and is oftype SEM_ID. This function must be changed to refer to your operating system call to performthis function.

#define SEM_WAIT_TIME (a,b) semTake (a, b)

This define is a macro to allow the user application to change the function to call when trying totake a semaphore with a specific time-out. The semaphore identifier is denoted by “a” and is oftype SEM_ID, the time value is denoted by “b” and should be in a form recognizable by thefunction replacing semTake. This function must be changed to refer to your operating systemcall to perform this function.

#define SEM_POST (a) semGive (a)

This define is a macro to allow the user application to change the function to call when trying torelease a semaphore that is no longer needed or give a semaphore to indicate an event. Thesemaphore identifier is denoted by “a” and is of type SEM_ID. This function must be changedto refer to your operating system call to perform this function.

PORTING E

6-14

11/3/98 10:48 AM CHPT6.DOC


#define SEM_BIN_CREATE () semBCreate (SEM_Q_FIFO, SEM_EMPTY)

This define is a macro to allow the user application to change the function to call when trying tocreate a binary semaphore that has an initial state of empty and is given to pending tasks in aFIFO fashion. This function should return a handle to the semaphore tracking structure createdand should be of type SEM_ID. This function must be changed to refer to your operatingsystem call to perform this function. If your operating system does not provide a semaphorecreate/destroy function, use the SEM_CREATE_DESTROY define.

#define SEM_MTX_CREATE () semMCreate (SEM_Q_FIFO)

This define is a macro to allow the user application to change the function to call when trying tocreate a mutual exclusion semaphore that has an initial state of “full” and is given to pendingtasks in a FIFO fashion. This function should return a handle to the semaphore trackingstructure created and should be of type SEM_ID. This function must be changed to refer toyour operating system call to perform this function. If your operating system does not provide asemaphore create/destroy function, use the SEM_CREATE_DESTROY define.

#define SEM_DESTROY (a) semDelete (a)

This define is a macro to allow the user application to change the function to call when trying toremove semaphore that is no longer needed. The semaphore identifier is denoted by “a” and isof type SEM_ID. This function must be changed to refer to your operating system call toperform this function. If your operating system does not provide a semaphore create/destroyfunction, use the SEM_CREATE_DESTROY define.

#define SPAWN (a, b, c, d, e) taskSpawn (a, b, c, d, e, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

This define is a macro to allow the user application to change the function to call when trying tospawn a task. Currently for VxWorks, the input to the task spawn function is as follows:

a = name of the task

b = priority of the task

c = task option word (see TASK_OPTIONS below)

d = stack size in bytes of stack needed + name

e = entry point to the new task

The output from the task spawn function is an integer (DWORD on test system) and is usedlater when task is deleted. This function must be changed to refer to your operating system callto perform this function.

#define TASK_OPTIONS VX_FP_TASK

This define is used internally by the FDI code to set the task options when spawning a task. Theoptions currently used are VxWorks-specific and you will need to define the options requiredby your operating system.

E PORTING

6-15

11/3/98 10:48 AM CHPT6.DOC


#define SEM_BIN_CREATE () semBCreate (SEM_Q_FIFO, SEM_EMPTY)

#define SPAWN_ERROR ERROR

This define is used internally by the FDI code to determine if an error occurred when spawningthe task. You need to replace the define definition to be appropriate for the error returned by thefunction called from the SPAWN macro (above). This function must be changed to refer toyour operating system call to perform this function.

#define TASK_DESTROY (a) taskDelete (a)

This define is a macro to allow the user application to change the function to call when trying toremove or delete an existing task. This function is only used when re-initializing a system thathas already been initialized. The task identifier is denoted by “a” and is an integer (DWORD ontest system) and should be the information returned from the task spawn. This function must bechanged to refer to your operating system call to perform this function.

The following set of compile options characterize the functionality provided by the file system.Make sure to modify these to fit your needs.

#define AUTO_RECLAIM FALSE

Setting this option to TRUE allows the background process to begin the reclaim process when itdetermines that it is necessary (free space falls below a pre-defined threshold). Setting thisoption to FALSE forces the background process to request permission from the user applicationbefore initiating a reclaim.

#define RECL_WEARLEVELING TRUE

Setting this option to TRUE allows the file system to occasionally choose a block for reclaimusing the cycling count as the criteria instead of the normal criteria (amount of outdatedinformation). This allows the entire partition to be cycled at an equivalent rate at the cost of anoccasional reclaim that does not yield as much free space. Setting this option to FALSEprevents this capability. In this case, the file system always chooses the block with the greatestamount of outdated information as the block to reclaim. If all data in the partition is beingcycled at a relatively similar rate, then wear-leveling is not necessary. If the data varies greatlyin update rate, wear-leveling will extend the life of the flash. If this compile option is set toTRUE, the user must set the WEARLEVELING_LIMIT variable to indicate the point at whichwear-leveling should take place. WEARLEVELING_LIMIT is a define that indicates themaximum block cycling differential that can exist before wear-leveling will occur. The defaultis 1000 cycles.

PORTING E

6-16

11/3/98 10:48 AM CHPT6.DOC


#define WEARLEVELING_LIMIT 1000

This is the define used to set the actual wear-leveling limit that kicks off the reclaim process.

#define INCLUDE_FORMAT TRUE

Setting this option to TRUE includes the format code, setting this option to FALSE does notinclude the format code. Typically the format code will need to be included duringimplementation and debug and will not be included for the final product. Format will occur atmanufacturing time in most user applications.

#define INCLUDE_FRAGMENTED_DATA TRUE

This option will allow the user to include the capability to include large file storage capabilities(option set to TRUE) or remove these capabilities (option set to FALSE) thus reducing codesize by approximately 10 KB. The option should only be disabled (set to FALSE) if the size ofthe largest data object stored complies with the following equation using defines alreadydetermined: largest data object size < (UNIT_GRANULARITY * MAX_NUM_UNITS_PER_FRAG

#define DATA_STREAM TRUE

Setting this define to TRUE allows the code to maintain a data stream rate. Please see Chapter4, which fully describes how data streams operate.

#define RESERVE_MOD TRUE

Setting this define to TRUE includes code to allow the user to perform Reserves and Modifies.Please see Chapter 5 for complete descriptions of these functions. This define must be set toTRUE if the DATA_STREAM define is set to TRUE.

#define OVER_16_BLOCKS FALSE

This define, when set TRUE, enables changes/additions to the FDI code to manage more than16 flash blocks with FDI. The default is false.

The following set of compile time defines are provided to add support for Intel Advanced+Boot Block components (28FxxxC3 as well as future components that utilize “Advanced+”features) in FDI source release 2.0 and higher.

#define ENABLE_PR FALSE

Setting this option to true enables access to the Protection Register. Please see the Architectureand API Specification chapter for details on the API enabled by this option. Default is disabled.May need to be used in conjunction fit ENABLE_TSOPx8.

#define ENABLE_TSOPx8 FALSE

This option may need to be used in conjunction with ENABLE_PR option. Default is FALSE.Set this option to TRUE if you are using a TSOP 28xxxC3 in x8 mode. This allows properaccess to the PR register on that particular package and mode.

E PORTING

6-17

11/3/98 10:48 AM CHPT6.DOC


#define BLOCK_LOCK_SUPPORT FALSE

This option enables block lock support in general when set to TRUE. Default is FALSE. Usedin conjunction with ENABLE_NONFDI_BLOCKLOCKING and ENABLE_FDI_BLOCKLOCKING option.

#define ENABLE_NONFDI_BLOCKLOCKING FALSE

This option, when set to TRUE, enables block lock support for those blocks not being managedby FDI. It also adds new functions for accessing the block locking features. Please see theArchitecture and API Specification chapter for details on the API enabled by this option. Thedefault is disabled.

#define ENABLE_FDI_BLOCKLOCKING FALSE

This option enables the special handling required in the low-level routines to write topotentially locked blocks in Intel Flash components that support this capability. It also addsnew functions for accessing the block locking features. Please see the Architecture and APISpecification chapter for details on the API enabled by this option. The default is disabled.

The following set of compile time defines are provided to add support for Intel Fast Boot Blockcomponents (28FxxxF3, as well as future components that utilize “fast” features) in FDI sourcerelease 2.0 and higher.

#define ENABLE_FBB_OPTIONS FALSE

This option, when set to TRUE, enables special routines to access the features of the Intel FastBoot Block flash components (plus other components that support this same capability). Pleasesee the Architecture and API Specification chapter for details on the API enabled by this option.The default is disabled.

#define X16_ARCHITECTURE TRUE

Enables operation of the flash in a x16 access mode.

6.6 VARIABLE RAM USAGESeveral FDI control structures are maintained in RAM to provide functionality and improve I/Operformance. The following descriptions represent a subset of the fields used by FDI. For acomplete description of RAM usage by FDI routines, refer to a compiler-generated map (MAP)file. There are several significant factors which affect the amount of RAM usage; total numberof parameter and data streams, total number of blocks supported, as well as the FDI featuresrequired for your application.

PORTING E

6-18

11/3/98 10:48 AM CHPT6.DOC


6.6.1 FDI_EXT.C

6.6.1.1 FDI_DataLookupTable [NUM_IDENTIFIERS]

This table is used to assist in looking up data. This table currently contains the logical blocknumber indicating where the information can be found. This table may be expanded later tocontain more addressing information to speed access to variables for those users that haveavailable RAM. This would be implemented as a compile time option. This table currentlyrequires one byte of RAM per identifier.

6.6.2 FDI_INT.C

6.6.2.1 FDI_LogicalBlockTable [MAX_DATA_BLOCKS]

This table is used to assist in looking up data. This table currently contains logical to physicalblock translation information, as well as information indicating the current status of space in theblock (free, outdated). The size of this table is determined by the following calculation:

((LOGICAL_BLOCK structure size) * (NUM_DATA_BLOCKS-1))

The table currently requires five bytes of RAM per data block (not including the spare block).

6.6.3 LOWLVL.C

6.6.3.1 Low-Level Algorithms

The low-level flash algorithms must be downloaded to RAM (beginning at the addressspecified by the RAM_START define). The size of these algorithms change based on thechanges made to the code to be downloaded. The efficiency of your code in these algorithmswill ultimately determine your implementation’s total RAM usage.

If using LOCAL_ALLOC define, the low-level downloads into an array, lowlvlRAMLocation.The array size must be adjusted for low-level code changes that increase the size beyond thedefault setting.

E PORTING

6-19

11/3/98 10:48 AM CHPT6.DOC


6.6.4 QUEUE.C

6.6.4.1 Queue Size

The queue which holds flash modification commands and data, directly affects RAM size. Afaster data rate requires a larger queue size and vice versa. A 1 KB/s data rate requiresapproximately 1 KB for a queue size, although processor speed and background processingtime may alter this. This needs to be tailored to each individual system.

6.7 PLATFORM AND COMPILER ARCHITECTUREThe existing FDI code may require unique compiler and/or platform settings which supportyour system’s hardware and software architecture. FDI was coded and tested using an EST360(M68360 processor) development platform with a custom flash board attached through theVME interface. This board includes configuration options for an Intel Boot Block or a FlashFilememory. The flash board can be set to various voltage combinations for testing. It was createdfor the sole purpose of internal development of FDI. It is assumed that your development willutilize a development platform or prototype that more closely resembles your end-product. Onthe development board, the entire flash component is mapped into memory in a linear fashion.Porting issues may arise in the OEM system through use of a segmented architecture ormapping only a portion of the flash memory (windowing) into the system memory map.

The filing system and media manager are ANSI-compatible, compiled using Wind RiverSystems Tornado Environment which utilizes VxWorks as the operating system and the GNUtools as the compiler.

6.8 REPLACING LOW-LEVEL DRIVER INTERFACE FUNCTIONS(LOWLVL)

Due to the unique characteristics of the hardware interface to flash created by individual OEMs,the following functions must be supplied by your low-level driver. They must adhere to FDIerror handling. FDI accepts a successful return value of zero (0) from the low-level layer andlabels it HW_ERR_NONE. Non-zero values are reported through the filing system with anappropriate descriptive error code. Descriptive error codes supported can be found in thelowlvl.h file.

HW_ERROR FlashDevCompatCheck ()

Verifies compatibility with flash supported by the user application. It is used to initialize anyhardware necessary to access the flash (such as chip selects) as well as a pointer that determineswhere the algorithm to perform erases/programs/copies resides. One of several algorithms maybe pointed to—based on the component supported. The flash algorithms must either reside inRAM or be relocated to RAM at initialization. This function reports an error if components areincompatible.

PORTING E

6-20

11/3/98 10:48 AM CHPT6.DOC


HW_ERROR FlashDevRead (DWORD address, BYTE_PTR buffer, WORD length)

This function fills the specified buffer with the number of bytes defined by length, from thedevice’s absolute physical address. The Background Manager or Reclaim Task determines therelative address by using the FDI mapping structures. The FlashDevRead function translates therelative flash address into a physical system address.

This function must access the flash through the hardware interface on your system. If yoursystem uses memory windows (i.e., only a portion of the flash is mapped into the main memorymap at any given time), it must be accounted for in this algorithm and the low-level mustincorporate a sliding window algorithm. If your system uses linear memory and the entire flashmemory is mapped into the system memory map, few changes will be required for the existingalgorithms.

HW_ERROR FlashDevWrite (DWORD address, BYTE_PTR buf_ptr,WORD length)

This function writes length bytes of data from a specified buffer to the destination addresswithin the device. The Background Manager or Reclaim Task determines the relative addressby using the FDI mapping structures. This function translates the relative flash address into aphysical system address, verifies the address range, and calls the appropriate low-level flashalgorithm function (e.g., IntelX16LowLevelRAM) to perform the actual write. This functionshould not require modification.

HW_ERROR FlashDevEraseBlock (DWORD address)

In order to reuse the flash media, an erase command must be provided for the filing systemdriver. This command erases a single flash erase-block beginning at the address specified. TheReclaim Task determines the relative address by using the FDI mapping structures. Thisfunction translates the relative flash address into a physical system address, verifies the addressrange, and calls the appropriate low-level flash algorithm function (e.g.,IntelX16LowLevelRAM) to perform the actual erase. This function should not requiremodification.

HW_ERROR FlashDevCopy (DWORD dest_address, DWORD src_address,WORD size)

The copy command is used during reclaim to copy valid data from the block being reclaimed tothe spare block and during data updates to copy data that is not changing. The BackgroundManager and Reclaim Task determine the relative address by using the FDI mapping structures.This function translates the relative flash address into a physical system address, verifies theaddress range, and calls the appropriate low-level flash algorithm function (e.g.,IntelX16LowLevelRAM) to perform the actual write. This function should not requiremodification.

E PORTING

6-21

11/3/98 10:48 AM CHPT6.DOC


HW_ERROR IntelX16LowLevelRAM ( DWORD dest_address, DWORDsrc_address, BYTE_PTR buffer, WORD length, HW_CMD command)/

HW_ERROR IntelX8LowLevelRAM ( DWORD dest_address, DWORDsrc_address, BYTE_PTR buffer, WORD length, HW_CMD command)

This function gets copied to RAM if both code and data are stored in flash. This functioncontains the low-level algorithms that must execute from RAM. This function must be modifiedto be adapted to the user’s hardware system. Calls to external functions cannot occur while taskswitching is disabled and interrupts are disabled. All calls to external functions (before or aftertask switch/interrupt disable) must be absolute branches or jumps. They cannot be relativejumps due to relocation of the code to RAM.

This function must access the flash through the hardware interface on your system. If yoursystem uses memory windows (i.e., only a portion of the flash is mapped into the main memorymap at any given time), it must be accounted for in this algorithm and the low-level mustincorporate a sliding window algorithm. If your system uses linear memory and the entire flashmemory is mapped into the system memory map, few changes will be required for the existingalgorithms.

IntelSetReadConfig

Function residing in low-level code that writes the read configuration register with the wordspecified by the caller.

IntelGetReadConfig

Function residing in low-level code that returns the contents of the read configuration register.

IntelX16RamFlexLock

Lock/Unlock/LockDown/ReadLockStatus algorithms for Intel Flash in a x16 manner.

6.9 UNDERSTANDING DEFINES AND MACROS IN THE LOW-LEVEL DRIVER

The low-level driver currently has several compile time options and defines to assist in settingup the hardware interface to the flash. There are also several macros. This section is intended toclarify the compile options and defines outlined in the lowlvl.c file. Please note that anysubroutines called internally by the low-level driver cannot be called through a relative branch.Since the low-level algorithms are copied into RAM, all relative addressing is invalid. Also,please note that operating system routines and routines stored in flash may not be called whileinterrupts and task scheduling are disabled.

PORTING E

6-22

11/3/98 10:48 AM CHPT6.DOC


6.9.1 Compile OptionsThe low-level flash interface file contains several flash configuration options. Theconfiguration used depends on how the compile options below are configured. There are alsoadditional compile options used to assist with debug.

X16_ARCHITECTURE (in type.h)

Setting this option to TRUE indicates that the algorithms to be used for flash access should beset up for a 16-bit address/data bus. This means that the IntelX16LowLevelRAM functionshould be used as the flash interface algorithm. Setting this option to FALSE indicates that an8-bit address/data bus will be used and the algorithms found in the IntelX8LowLevelRAMfunction should be used. If this option is FALSE, the actual configuration supported depends onthe JAGUAR compile option defined below. If the JAGUAR option is TRUE, it is assumedthat an Intel Boot Block device is being used in x8 mode. If the option is FALSE, an IntelFlashFile memory x8 configuration is used.

ADDRESS_VALIDATION (in lowlvl.c)

Setting this option to TRUE includes code that performs validation on the address parametersent to all low-level functions before executing the low-level function. If the address combinedwith other parameters will cause an access outside of the data partition range, an error isreturned. This assists to ensure that the code partition does not become corrupted through use ofthe low-level functions.

TIME_MONITOR_ENABLED (in lowlvl.c)

Setting this option to TRUE enables time monitoring to occur in the low-level. Timemonitoring is a mechanism in which systems with predictable interrupts can limit interruptlatency by monitoring time and suspending program/erase commands slightly before theinterrupt is expected to minimize interrupt latency. This option should only be used if a systemhas predictable interrupts.

INTERRUPT_POLLING (in lowlvl.c)

Setting this option to TRUE allows the FDI code to poll for interrupts during flash memoryupdates (writes and erases) Setting this to FALSE allows the user to create a direct interrupthandler which would reside in RAM. See lowlvl.c for an example of a direct interrupt handler.

DEBUG_LOWLVL (in lowlvl.c)

Setting this option to TRUE includes various test code for debugging low-level issues. Settingthis option to FALSE does not include this code. This option should be set to FALSE for mostOEM configurations.

E PORTING

6-23

11/3/98 10:48 AM CHPT6.DOC


BIG_ENDIAN_ARCHITECTURE (in lowlvl.c)

Setting this option to TRUE indicates that the system CPU is a big endian processor. Settingthis option to FALSE indicates that the system CPU is a little endian processor. When readinginformation larger than one BYTE in width from memory, big endian processors read memoryassuming the most significant bit (MSB) is first. Little endian processors read memoryassuming the least significant bit (LSB) is first. This define is only used in the low-level whenaccesses are greater than one byte in width (x16 component configuration).

6.9.2 Configuration-Specific DefinesThe following set of defines are used to set up the specific board configuration or the specificflash command set.

6.9.2.1 FLASH COMMAND DEFINES

The following defines indicate the commands sent to the flash component for the specific boardset up. This is an example for the Advanced Boot Block component. There are similar definesfor the other flash components.

#define X16_FLASH_COMMAND_READ_ID 0x0090

#define X16_FLASH_COMMAND_READ 0x00FF

#define X16_FLASH_COMMAND_ERASE 0x0020

#define X16_FLASH_COMMAND_CONFIRM 0x00D0

#define X16_FLASH_COMMAND_CLEAR 0x0050

#define X16_FLASH_COMMAND_WRITE 0x0040

#define X16_FLASH_COMMAND_STATUS 0x0070

#define X16_FLASH_COMMAND_SUSPEND 0x00B0

#define X16_FLASH_COMMAND_RESUME 0x00D0

#define X16_FLASH_COMMAND_READ_CFG 0x0060

#define X16_FLASH_COMMAND_RCD 0x0003

#define X16_FLASH_COMMAND_WRITE_PR 0x00C0

#define X16_FLASH_COMMAND_LOCK 0x0060

#define X16_FLASH_COMMAND_LOCK_CONFIRM 0x0001

PORTING E

6-24

11/3/98 10:48 AM CHPT6.DOC


#define X16_FLASH_COMMAND_UNLOCK_CONFIRM 0x00D0

#define X16_FLASH_COMMAND_LOCKDOWN_CONFIRM 0x002F

#define X16_FLASH_STATUS_READY 0x0080

#define X16_FLASH_STATUS_ERASE_SUSPENDED 0x0040

#define X16_FLASH_STATUS_WRITE_SUSPENDED 0x0004

#define X16_FLASH_STATUS_ERROR 0x003E

#define X16_FLASH_LOCK_ERROR 0x0012

#define X16_FLASH_OTP_ERROR 0x001A

#define X16_FLASH_ADDRESS_RCD 0x0005

6.9.2.2 PLATFORM DEFINES

The following defines are board-specific and relate to the specific configuration#define FLASH_START_ADDRESS 0x000800000

6.9.3 Time MonitoringThe following defines and macros allow the user to substitute similar functions from theirenvironment to allow time monitoring to occur. Time monitoring is defined above in thecompile time options.

TIME_MONITOR

Defines the wait time interval during interrupt polling before proceeding. Interrupts aredisabled to check time left until next periodic interrupt and re-enabled if there is not enoughtime to allow task switching. The task is delayed until the next interrupt before re-checking ifenough time exists.

#define TIME_MONITOR(key0,key1) \for (;;) \{\DISABLE_INTERRUPTS(key0,key1); \if (TICKS_TILL_NEXT_INTERRUPT > time_needed) \break; \ENABLE_INTERRUPTS(key0,key1); \WAIT_FOR_INTERRUPT; \}

E PORTING

6-25

11/3/98 10:48 AM CHPT6.DOC


WAIT_FOR_INTERRUPT

This is a system-specific macro to provide a mechanism to wait for the next regularly scheduledinterrupt while allowing task scheduling to occur in the background.

#define WAIT_FOR_INTERRUPT \SLC_maskSlotInterrupt();\while (SLC_getSlotEvent() == 0) \{ \; \} \SLC_unmaskSlotInterrupt();

MINIMUM_RUN_TIME

This define determines what the minimum number of microseconds of time must be to allowthe erase or program to begin processing. If this amount of time is not available, it does notmake sense to begin processing and the system should wait until after the interrupt occursbefore beginning erase/program processing.

#define MINIMUM_RUN_TIME 25 /* in µs */TICKS_TILL_NEXT_INTERRUPT

This system specific macro determines how much time is available for processing before thenext interrupt will occur. Time is expressed in ticks.

#define TICKS_TILL_NEXT_INTERRUPT \(WORD)(SLC_getClksToNextSlot)

GET_MINIMUM_TICKS

This define determines the minimum processing time required in ticks.

#define GET_MINIMUM_TICKS \SLC_convertTimetoSlotClks(MINIMUM_RUN_TIME);

6.9.4 Interrupt Control DefinitionsThe following defines are interrupt control defines that allow interrupts to be disabled andpolled during the low-level algorithms that exist in RAM. Polling interrupts during this periodprevents interrupts from auto-vectoring to flash while flash is in a status mode instead of theread array mode.

PORTING E

6-26

11/3/98 10:48 AM CHPT6.DOC


Interrupt Level

This define determines the lock out level for interrupts on the system being used. This levelshould be modified to the highest level allowed for interrupts on the system. In order to disableall interrupts when polling.

#define INTERRUPT_LEVEL 0x07

Interrupt Poll Mask

This is a system-specific mask that determines which bits in the interrupt register need to bepolled during low-level algorithms.

#define INTERRUPT_POLL_MASK 0x7A7610B8 /* this is the normal mask *//* #define INTERRUPT_POLL_MASK 0x7a720038 * without T2, T3, T4 */

Interrupt Pending

This is a system-specific macro that reads the interrupt pending register to determine if aninterrupt has occurred.

#define INTERRUPT_PENDING \(*M360_CPM_CIPR(M_ADRS) & INTERRUPT_POLL_MASK));

Disable Interrupts

This is a system-specific macro to:

1. disable task scheduling

2. disable system interrupts

The key2 variable is currently unused and planned for expansion in interrupt sources. Thismacro allows interrupt and task processing to be disabled during low-level algorithms in RAM.This allows interrupt polling to occur instead of auto-vectored interrupts.

E PORTING

6-27

11/3/98 10:48 AM CHPT6.DOC


#ifdef INLINE_ASM

/* Reduce call/return overhead by using inline asm *//* (INTERRUPT_LEVEL is hardcoded) */#define DISABLE_INTERRUPTS(key0,key1) \ asm ("MOVE SR,%0\n" \ "MOVE.L #0x700,%1\n" \ "OR.W %2,%1\n" \ "MOVE SR,%0\n" \ "MOVE %3,SR\n" \ "ANDI.L #0x700,%0\n" \ : "=d" (key0), "=d" (key1): "0" (key0), "1" (key1));#else#define DISABLE_INTERRUPTS(key0,key1) \ key0 = (*intlevelset_funcptr)(INTERRUPT_LEVEL); \ key1 = key0;#endif

Enable Interrupts

This is a system-specific macro to:

1. enable system interrupts

2. enable task scheduling

The key2 variable is currently unused and planned for expansion in interrupt sources. Thismacro allows interrupt and task processing to occur when an interrupt occurs or when low-levelalgorithms are complete.

/* system specific macro to enable system interrupts */#ifdef INLINE_ASM/* Reduce call/return overhead by using inline asm */#define ENABLE_INTERRUPTS(key0,key1) \ asm ("MOVE SR,%1\n" \ "ANDI.L #0xf8ff,%1\n"\ "OR.L %2,%1\n" \ "MOVE %3,SR\n" \ : "=d" (key0), "=d" (key1): "0" (key0), "1" (key1));#else#define ENABLE_INTERRUPTS(key0,key1) \ (void)(*intlevelset_funcptr)(key0); \ key0 = key1;#endif

PORTING E

6-28

11/3/98 10:48 AM CHPT6.DOC


6.9.5 Board-Specific DefinitionsThe following values/defines/variables are primarily for VxWorks and the Motorola 68360processor family development board used by Intel to develop and test FDI. They should becreated, removed or modified based on your specific implementation of your processor andoperating system. Some of these are defined by VxWorks in their board support modules. Theyare provided to assist you in adapting FDI to your specific application.

These are used to control enable and disable VPP for devices that cannot tie VPP permanently to12 V.

This is 68360 base is programmed into MBARBASE = 0x10000000M_ADRS = BASE

This is where the internal registers startM360_REGB_OFFSET = 0x1000

Port B is used to assess/control various board functions.

This is the port B Data Direction Register addressM360_CPM_PBDIR = ((UINT32 *) (BASE + M360_REGB_OFFSET + 0x6b8))

This is the port B Pin Assignment RegisterM360_CPM_PBPAR = ((UINT32 *) (BASE + M360_REGB_OFFSET + 0x6bc))

This is the port B Open Drain Register address */M360_CPM_PBODR = ((UINT16 *) (BASE + M360_REGB_OFFSET + 0x6c2))

This is the port B Data Register address */M360_CPM_PBDAT = ((UINT32 *) (BASE + M360_REGB_OFFSET + 0x6c4))

E PORTING

6-29

11/3/98 10:48 AM CHPT6.DOC


/* THE FOLLOWING DEFINES ARE USED TO SET UP 12V VPP ENABLE / DISABLE *//* for the Advanced Boot Block chip which cannot be tied to 12V rail */#define PORTB_PAR_MASK 0xFFFFFFEF#define VPP_MASK 0x00000010#define VPP_CLEAR_MASK 0xFFFFFFEF

/* The following macro initializes vpp on the Advanced Boot Block * component read data direction register and force vpp bit to be an input * read data register and if vpp bit is zero, switch is closed and an error * should occur else, if no error, write 1 in vpp enable bit of open drain * register to make an open drain output write 1 in vpp enable bit of data * direction register to make an output port write 0 in vpp enable bit of data * register to turn vpp off */#define INITIALIZE_SMART3_VPP \ { \ *M360_CPM_PBPAR(M_ADRS) &= PORTB_PAR_MASK; \ *M360_CPM_PBDIR(M_ADRS) &= VPP_CLEAR_MASK; \ *M360_CPM_PBODR(M_ADRS) |= VPP_MASK; \ *M360_CPM_PBDIR(M_ADRS) |= VPP_MASK; \ *M360_CPM_PBDAT(M_ADRS) &= VPP_CLEAR_MASK; \ }

#define ENABLE_SMART3_VPP \*M360_CPM_PBDAT(M_ADRS) = (*M360_CPM_PBDAT(M_ADRS) | VPP_MASK);

#define DISABLE_SMART3_VPP \ { \ *M360_CPM_PBDAT(M_ADRS) = (*M360_CPM_PBDAT(M_ADRS) &VPP_CLEAR_MASK); \ }

This value, which defines the erase timeout, should be tuned to your system’s actualperformance and requirements.

/* 25 second erase timeout @500us interrupt rate *//* (Use actual application interrupt rate for better accuracy) */#define MAXIMUM_LOOP_COUNT 50000

6.10 DEVELOPMENT ENVIRONMENT CONSIDERATIONS

6.10.1 The UNIX* Development EnvironmentThe reference source code and make files provided, were created in a standard Intel x86 PCenvironment. As such, there are known “issues” that may exist with file translation into aUNIX* development environment. These issues may include but are not necessarily limited to:Tabs vs. Spaces, different interpretations of Carriage Returns and/or Line Feeds, Word* for

PORTING E

6-30

11/3/98 10:48 AM CHPT6.DOC


Windows format of documentation, and other text formatting issues. We have tried to be assensitive to these issues as possible, but some issues are inherent to the differences betweenthese operating system environments. There are utilities in the UNIX environment that can helpto translate these files to minimize the impact on your development. However, some impactshould be anticipated.

6.10.2 The Existing Make FilesThe existing make files have been created for FDI development. They have been included toassist in creating your own make files or adapting them to your environment. All make fileshave directives that should be similar from one system to the next so some portions of the makefiles are reusable. All make files also have operating system specific information and compilertool set specific information. These portions are not directly re-usable when changingenvironments. Below we have listed the make files used in the FDI test environment. Wedescribe the purpose of each file and identify which files need modification if you choose toutilize our make setup.

MAKEANCH

This file is a make anchor file. It exists to set up the home directory for the FDI source code.This is then used as an include in our make macro file and all of our make files to allow all FDIsub-directories to be based from this path. This allows relocation of FDI. You will need tochange this (drive and path) to reflect the base path or root directory necessary to find FDI inyour setup. For example, if the original file has “FDI_PATH = d:\fdi\src” but your setup willplace FDI on your C: drive under the path “\test\fdi\src,” then the file should be changed to“FDI_PATH = c:\test\fdi\src.” This file is not a make file. This file should reside in yourequivalent of the “d:\fdi\src” directory.

MAKEMAC

This file is an FDI make macro file. This file exists to set up all path names and compile timeoptions for the source code, operating system files, and compiler tools for the FDI project. Thisfile is used as an include file for all of the FDI make files. It is not a make file. You will need tocarefully modify this file to set up the appropriate path names for your operating system andcompiler tools as well as the appropriate options. Please follow the porting directions providedin comments inside this file to accomplish modification of this file. This file should reside inthe same directory as the MAKEANCH file.

E PORTING

6-31

11/3/98 10:48 AM CHPT6.DOC


FDI_HI.MAK

This file is the main make file for all of FDI. This file includes make directives to make thevarious FDI sub-directories and to create one output file. The output file is namedFDI_HI.OUT. This file should not require porting unless your make tools are significantlydifferent. Most tool differences should be accounted for through the MAKEMAC file. This fileshould reside in the same directory as the MAKEANCH file.

FDI.MAK

This file is the make file for the FDI (\FDI\SRC\FDI) sub-directory. This file includes makedirectives to build the source code in the FDI sub-directory. It should not require porting unlessyour make tools are significantly different. Most tool differences should be accounted forthrough the MAKEMAC file. This file should reside in the FDI sub-directory below thedirectory specified in the MAKEANCH file.

COMMON.MAK

This file is the make file for the COMMON (\FDI\SRC\COMMON) sub-directory. This fileincludes make directives to build the source code in the COMMON sub-directory. It should notrequire porting unless your make tools are significantly different. Most tool differences shouldbe accounted for through the MAKEMAC file. This file should reside in the COMMON sub-directory below the directory specified in the MAKEANCH file.

LOWLVL.MAK

This file is the make file for the LOWLVL (\FDI\SRC\LOWLVL) sub-directory. This fileincludes make directives to build the source code in the LOWLVL sub-directory. It should notrequire porting unless your make tools are significantly different. Most tool differences shouldbe accounted for through the MAKEMAC file. This file should reside in the LOWLVL sub-directory below the directory specified in the MAKEANCH file.

6.10.3 Make Files–Adapt Existing, or Create Your Own?The decision to create your own make files or adapt the existing make files is dependent onyour familiarity with make tools. If you are familiar with make tools and have a projectstructure in which you wish to add FDI, you may choose to create your own. Adapting the FDImake files should be fairly straightforward for those less familiar with the make utility.

11/3/98 10:49 AM CHPT7.DOC


E7

Test Environment

E

7-1

11/3/98 10:49 AM CHPT7.DOC


CHAPTER 7TEST ENVIRONMENT

7.1 INTRODUCTIONThe Flash Data Integrator software allows users to store real-time system parameters into flashwhile performing code execution from the same flash device. The software is designed to addnew capabilities as market needs arise. The software is primarily directed toward the digitalcellular market. This chapter outlines the test platform and software used to test the FDIsoftware in a system environment similar to a GSM cellular system. While the current systemtest environment concentrates on the GSM cellular system, many other system architectures(such as PHS, CDMA, pagers, or cable modems) can utilize the FDI software.

The FDI test system consists of; 1) an embedded platform on which the software is tested and2) a PC to perform remote debug and run automatic test scripts. The embedded platformprovides an external interface to receive asynchronous communication from the Test ScriptInterface and user interface on the PC. The embedded platform consists of a Motorola 68360-based evaluation board with a flash add-on board. The platform utilizes the Wind RiverSystems VxWorks Operating System and development environment to provide a real-timemulti-tasking environment.

On the Test Script Interface PC, test scripts are generated and run. Commands in the test scriptare verified/translated and downloaded to the embedded controller through an “asynchronous”interface. Once the embedded platform receives a test script, it waits for control on the test PCto indicate that the test should be started. The script is run, and all commands are run, on theembedded platform to emulate communication similar to a digital cellular phone. In addition,the test script PC can cause asynchronous events, such as a key press, to be simulated andcommunicated to the embedded platform through the asynchronous interface. The test script PCalso emulates power loss to ensure the FDI code is capable of recover. The goal of this setup isto simulate realistic cellular phone activity to guarantee applicability of the FDI software. Ascommands are completed on the embedded platform, status is sent to the test script PC to beplaced into a log file. This allows test scenarios to be repeated for reproduction of problems.Figure 7-1 provides an overview of the necessary components.

TEST ENVIRONMENT E

7-2

11/3/98 10:49 AM CHPT7.DOC


Windows 95*/ Windows NT*Remote Debug for

Embedded Platform(Mobile Emulation)

DOS PC Test Script Interface(Network Emulation)

RemoteDebug

Interface(Ethernet)

AsynchronousEvent Generation

Interface(RS-232)

Embedded Platform(SBC 360)

Address TranslationPLD

Intel® Flash Memory

FDI7-1

Figure 7-1. System Overview

7.2 DEFINITIONS AND CONVENTIONSACC Access Control Class

ACM Accumulated Call Meter

ACM Max Accumulated Call Meter Maximum; the maximum value that the ACM field can store

ADN Abbreviated Dialing Numbers

AD Administrative Data

BCCH Broadcast Control Channel

BYTE 8-bit value

CCP Capability Configuration Parameters

CBMI Cell Broadcast Message Id selection

CDMA Code Division Multiple Access (IS-95)

DAMPS Digital American Mobile Phone System (IS-54)

DWORD 32-bit value

EXT1 Extension of LND/ADN/SSC/MSISDN parameters

E TEST ENVIRONMENT

7-3

11/3/98 10:49 AM CHPT7.DOC


EXT2 Extension of FDN/SSC parameters

FDI Flash Data Integrator software

FDN Fixed Dialing Numbers

FNULL 0xFFFFFFFFh; used to refer to flash null media pointers

FPLMN Forbidden Public Land Mobile Network

GSM Global System for Mobile communications, a digital cellular radio system

HPLMN Home Public Land Mobile Network

ICCID SIM identification

IMSI International Mobile Subscriber Identification

KC Ciphering Key

LND Last Number Dialed

LOCI Location Information

LP Language Preference

NULL Zero

Media ControlStructure A structure of data used as a controlling structure in any of the drivers; a

Media Control Structure can exist on the flash card or in RAM

MSISDN Mobile Station Integrated Services Digital Network Number

PCCP PC Consumer Peripheral; a consumer product that is being used as a PC Peripheral

PCN Pacific Digital Cellular

PHASE Phase Identification

PLMN Public Land Mobile Network

PLMN Sel Public Land Mobile Network Selector

PUCT Price per Unit and Currency Table

SIM Subscriber Identity Module. This is a removable memory card used in GSM mobile stations. Many parameters are stored in the SIM or in nonvolatile memory on the mobile station or both memories.

SMS Short Message Service; a feature in GSM cellular networks in which mobile phones may send or receive text messages of a maximum length of 140 bytes

SMSP Short Message Service Parameters

SMS Short Message Service Status

SST SIM Service Table

TEST ENVIRONMENT E

7-4

11/3/98 10:49 AM CHPT7.DOC


TDMA Time Division Multiplexed Access. Each 4.615 ms in time is broken down into eight time slots or logical channels. Each of these logical channels allow a different user to access the shared frequency at a regularly defined interval.

TDMA frame A 4.615 ms period of time that provides eight separate time slots or logical channels for cellular communication.

TDMAhyper-frame A large scale timing interval in the GSM system that consists of 2048 super

frames which is equivalent to 2H : 28M : 53S : 740 ms of time

TDMAmulti-frame A large scale timing interval consisting of 24 frames for a traffic channel or

51 frames for a signaling channel.

TDMAsuper-frame A large scale timing interval consisting of 51 instances of a 24 frame traffic

channel multi-frame or consisting of 24 instances of a 51 frame signaling channel multi-frame

TDMAtime slot One of eight 577 ms pieces of time that combine to make a TDMA frame

WORD 16-bit value

7.3 SYSTEM ENVIRONMENT SOFTWARE ARCHITECTUREThis section covers the system environment software on the embedded platform and the TestScript Interface PC. This software creates the system environment in which the FDI software isverified. The remote debug software for the embedded platform consists of third party vendorsoftware purchased through Wind River Systems. The Test Script Interface (TSI) Software onthe PC provides commands that allow the embedded test platform to emulate the cellularnetwork interface. The software on the embedded platform uses these commands to simulatethe timing and activity of the mobile station.

On the Test Script Interface PC, a test script is passed to the test executable through the userinterface. The test script is parsed through a layer of software that validates all commands andparameters in the script. The test script is then transferred to the embedded platform through adownload message which is communicated over the asynchronous interface. Asynchronousmessages are received by the embedded platform. The asynchronous interface interprets themessages and passes each message to the appropriate handling mechanism. A downloadmessage is passed to the GSM emulation software which breaks the test script down intodistinct commands. Each command is treated as a series of GSM events that require simulation.This software is designed to emulate the behavior of a real-time multi-tasking environmentwhich exists in most cellular phones. Other messages from the user interface on the Test PC areused to simulate asynchronous interrupts (such as keypad interrupts) seen in the mobile stationenvironment. Figure 7-2 provides an overview of the software layers and their interaction.

E TEST ENVIRONMENT

7-5

11/3/98 10:49 AM CHPT7.DOC


Asynchronous MessageInterface

Test Script

Test Script InterfaceSoftware

(PC)

EmbeddedPlatform Software

GSM Cellular Emulation(Layer 2, Layer 3, RSLC,

MMI)FDI

(Foreground API’s/Background Manager,

Interrupt Polling)

Low Level Flash IF

Flash

User Interface

Asynchronous MessageInterface

Ethernet

FDI7-2

Figure 7-2. Software Overview

7.3.1 PC User InterfaceThe user interface allows users to enter commands to download test scripts to the embeddedplatform, control execution of the command scripts on the embedded platform (start, pause,stop, etc.), and send asynchronous commands to the embedded platform while test scripts areexecuting. (Asynchronous commands can also be performed through the test script.) It alsopolls for the receipt of messages sent by the embedded platform and allows reading of storedparameters in flash. These messages contain status updates to be stored in log files to indicatethe progress of command scripts and provide feedback information to the user.

TEST ENVIRONMENT E

7-6

11/3/98 10:49 AM CHPT7.DOC


7.3.2 PC Asynchronous CommunicationThis layer of software controls all asynchronous communication on the PC. Asynchronouscommunication is used to allow emulation of events external to the TDMA emulation. Thisinterface allows for simulation of events such as keypad input, and other events or status toassist with the debug of software on the embedded platform. This interface consists of anethernet port.

7.3.3 Embedded Asynchronous CommunicationThis layer of software receives asynchronous commands from the PC Asynchronous Interface,interprets, and acts upon the command. Commands include test script downloads, script controlcommands, keypad input commands, parameter storage commands, and any future debugmessages necessary to successfully test the system.

All messages on this interface return an ack/nack to indicate if the command/message has beenaccepted as valid. Keypad input allows user input, such as phone numbers, to occur. Once avalid keypad sequence has been received, the information is passed to the parameter storagesystem.

7.3.4 Embedded GSM Emulation SoftwareThe GSM emulation software is used to emulate the timing involved for each of thesecommands and the behavior of the system. This layer of software consists of several tasks thatsimulate the multi-tasking environment of a GSM mobile phone. Each of the tasks track thestates similar to those used in a mobile phone. Test scripts sent from the PC are used tosimulate parameter storage and the overall CPU availability that is seen in cellular phones. TheGSM Emulation software receives the commands, and responds by simulating the activity thatwould occur in a mobile phone.

7.4 PARAMETER STORAGE EMULATIONThe test software must allow for testing of storage, update, and retrieval of a set of parameterssimilar to that used in GSM telephones. The Table 7-1 summarizes the parameters that arecurrently stored to the SIM card or nonvolatile memory in a GSM phone that could be stored toflash memory. This table forms the base set of parameters used for testing and emulation forthe FDI software. Any parameters marked as NV or both in Table 7-1 are candidates for flashand are emulated in the test software.

E TEST ENVIRONMENT

7-7

11/3/98 10:49 AM CHPT7.DOC


Table 7-1. GSM Parameter Storage Summary

Memory(S = SIM,

NV =Nonvolatile)

Param.No.

(Hex)

File ID Description Size(Bytes)

UpdateFrequency

UpdateOccurrences

S 2FF2 ICCID SIM Id 10 Never

NV 6F05 LP Language Preference 1 to N Low User

S 6F07 IMSI International MobileSubscriber Id

9 Never

S 6F20 KC Ciphering Key 9 High Init, Termination,AuthenticationRequest

S/NV 6F30 PLMN Sel PLMN Selector 3N Low Init, User

S/NV 6F31 HPLMN HPLMN Searchperiod

1 Never Service Provider

S/NV 6F37 ACM Max ACM max value 3 Never Service Provider

S 6F38 SST SIM service table 4 Never Service Provider

S/NV 6F39 ACM Accumulated callmeter

3 High Init, periodically duringcall

S/NV 6F41 PUCT Price per unit &currency table


Both 6F45 CBMI Cell Broadcastmessage id selection

2N Low User

Both 6F74 BCCH Broadcast controlchannel list

16 High Init, Termination,Location Updates

S 6F78 ACC Access Control Class 2 Never Service Provider

S 6F7B FPLMN Forbidden PLMN 12 Low Init, Termination,Location UpdateRejection

S 6F7E LOCI Location Info 11 High Init, Termination,Handover (p73: 4.08)

S 6FAD AD Administrative Data 3 + X Never Service Provider

S 6FAE PHASE Phase Identification 1 Never Service Provider

Both 6F3A ADN Abbreviated DialingNumbers

X + 14 Low User

S 6F3B FDN Fixed DialingNumbers

X + 14 Never Service Provider

Both 6F3C SMS Short MessageService

176 High Network SMSprocedure

TEST ENVIRONMENT E

7-8

11/3/98 10:49 AM CHPT7.DOC


Table 7-1. GSM Parameter Storage Summary (Continued)

Memory(S = SIM,

NV =Nonvolatile)

Param.No.

(Hex)

File ID Description Size(Bytes)

UpdateFrequency

UpdateOccurrences

Both 6F3D CCP CapabilityConfigurationParameters


S 6F40 MSISDN MS - ISDN X + 14 Never Service Provider

Both 6F42 SMSP Short MessageService Parameters

28 + Y Low When sending SMS

Both 6F43 SMSS Short MessageService Status

2 + X Low Network SMSprocedure

Both 6F44 LND Last Number Dialed X + 14 High Call Termination

Both 6F4A EXT1 Extension data ofLND, ADN/SSC,MSISDN

13 Low User

S 6F4B EXT2 Extension data ofFDN/SSC

13 Low User

Both XXXX MISC Miscellaneous OEMspecific data (volumecontrol, ring type)

variable

1 to 300

Low User

NOTES:

N = >=8

X = Ranges from 0–241

Y =Y may be zero, uses GetResponse function of SIM Card to determine length

7.5 DATA STREAM EMULATIONThe test software must allow for testing the storage, update, and retrieval of a data stream suchas a voice memo. Data streams of various lengths (duration) and update intervals are stored,modified, and read by the test software.

7.6 TIMING ENVIRONMENTGSM cellular phones share frequency band-width through use of Time Division MultipleAccess, or TDMA. TDMA allows multiple users to share a common frequency channel on atime schedule. All users sharing the frequency resource have their own assigned repeating time

E TEST ENVIRONMENT

7-9

11/3/98 10:49 AM CHPT7.DOC


slot within a group of time slots called a frame. Figure 7-3 shows an overview of the timing in aGSM system. Each of the defined time periods shown in this diagram is further explainedbelow. This timing environment must be simulated by the GSM emulation software on theembedded platform.

3Tail Bit

57Coded Data

57Coded Data

1Stealing

Flag

26Training

Sequence

1Stealing

Flag

8.25Guard Period

0.577 ms = TDMA Time Slot = Logical Channel

2 43 5 6 710

4.615 ms = TDMA Frame

00

01

02

03

04

09

08

07

05

06

10

11

12

13

14

19

18

17

16

15

20

21

22

23

24

29

28

27

26

25

30

31

32

33

34

39

38

37

36

35

40

41

42

43

44

49

48

47

46

45

50

235.38 ms = 51 Frame Signalling Multi-frame

T00

T01

T02

T03

T04

T09

T08

T07

T06

T05

T10

T11

S12

T13

T14

T19

T18

T17

T16

T15

T20

T21

T22

T23

T24

I25

120 ms = 26 Frame Speech Multi-frame

0

0 1 2 3 47 48 49 50

1 2524

6.12 S = 1 Superframe = 26 - 51 Frame Multiframes = 51 - 26 Frame Multi-frames

0 1 2 2047204620453 4 20442043

3H 28M 53S 760 ms = 1 Hyperframe = 2048 Superframes

S = SACCHI = IDLET = TCH / FACCH

For content of Signalling Multi-frame, see p. 93 - 98 of "AnIntroduction to GSM" by Redl,Weber, and Oliphant

FDI7-3

Figure 7-3. Time Division Multiple Access Overview

TEST ENVIRONMENT E

7-10

11/3/98 10:49 AM CHPT7.DOC


7.6.1 TDMA Time SlotsIn GSM cellular phones, all frequencies are divided into a minimum common repeating intervalcalled a time slot. Each time slot is 577 µs in length. The data transferred during this timefollows the structure defined in Figure 7-3.

7.6.2 TDMA FramesEight TDMA time slots are combined to create a TDMA frame. Each of eight users areassigned one time slot within a frame. One TDMA frame lasts 4.615 ms (8 × 577 µs). Thisprovides each user a repeating time slot in which to communicate to the cellular network. Eachuser is assigned a time slot within a time frame and this is called their logical channel. Eachlogical channel consists of a time slot to receive data from the network, and a time slot totransmit data. Transmissions and receiving frames occur on separate frequencies. The GSMspecification requires the time difference between receive and transmit functions to be threetime slots, although the time slot numbering (logical channel) remains the same as if both wereusing the same time slot at the same time. Figure 7-4 shows how time-division duplex occurs inthe GSM system.

0 210765431 27

5 765432106 74

3

0

Base Transmits

Mobile Transmits

FDI7-4

Figure 7-4. Time Division Duplex in the GSM System

7.6.3 TDMA Multi-FramesA multi-frame is a structure that defines logical channels for a multiple number of frames. Thisallows different types of signaling opportunities for the variety of equipment in the cellularnetwork. Due to the limitation of bits transferred in each time slot, user-level messages oftentake several TDMA frames to transmit. Each channel in the multi-frames defined below isconfigured to take the number of consecutive frames typical messages on the channel take (forexample typical messages for the SDCCH channel take four frames to transmit, therefore thechannel takes four consecutive frames). In some situations, several instances of a multi-framemust be received before an entire message can be received (for example, normal SACCHmessages take four frames. However, the traffic multi-frame only allows one frame to be usedfor SACCH per multi-frame. This means it would take four traffic multi-frames to receive oneSACCH message). Section 7.6.7 defines the uses for each of the channels defined in the multi-frames defined below.

E TEST ENVIRONMENT

7-11

11/3/98 10:49 AM CHPT7.DOC


7.6.3.1 SIGNALING MULTI-FRAME

On logical channels that are being used for phone control, 51 consecutive occurrences of alogical channel combine to create what is called a signaling multi-frame. This multi-framedefines certain repeating intervals on a higher level to create a variety of logical controlchannels. These control channels do not move user’s data (such as voice or fax), but move thedata the network and mobile phones need to make sure all events in the system are handledproperly. All control messaging flows in the test environment mirror the signaling multi-framedefined in Figure 7-5 as closely as possible. Figure 7-3 also contains a high level overview ofthe signaling multi-frame. All channels and their purposes are described in Section 7.6.7.

235.38 ms = 51 Frame Signaling Multi-frame

2 3 4 50 1 6 7 8 9

F S BCCH CCCH

12 13 14 1510 11 16 17 18 19

F S CCCH CCCH

22 23 24 2520 21 26 27 28 29

F S SDCCH 0 SDCCH 1

32 33 34 3530 31 36 37 38 39

F S SDCCH 2 SDCCH 3

42 43 44 4540 41 46 47 48 49

F S SACCH 0 SACCH 1

50

I

2 3 4 50 1 6 7 8 9

F S BCCH CCCH

12 13 14 1510 11 16 17 18 19

F S CCCH CCCH

22 23 24 2520 21 26 27 28 29

F S SDCCH 0 SDCCH 1

32 33 34 3530 31 36 37 38 39

F S SDCCH 2 SDCCH 3

42 43 44 4540 41 46 47 48 49

F S SACCH 2 SACCH 3

50

I

16 170 1 2 3

R RSDCCH 3

6 7 8 94 5 10 11 12 13

R R SACCH 2 SACCH 3

14 15

R R

37 38 39 4034 35 41 42 43 44

R R SDCCH 0 SDCCH 1

45 46 47 48 49 50

F S SDCCH 2

36

R

20 21

R R

18 19

R R

24 25

R R

22 23

R R

28 29

R R

26 27

R R

32 33

R R

30 31

R R

16 170 1 2 3

R RSDCCH 3

6 7 8 94 5 10 11 12 13

R R SACCH 0 SACCH 1

14 15

R R

37 38 39 4034 35 41 42 43 44

R R SDCCH 0 SDCCH 1

45 46 47 48 49 50

F S SDCCH 2

36

R

20 21

R R

18 19

R R

24 25

R R

22 23

R R

28 29

R R

26 27

R R

32 33

R R

30 31

R R

1

2

1

2

Base Station to Mobile(Downlink)

Mobile to Base Station(Uplink)

FDI7-5

Figure 7-5. Signaling Multi-Frame

7.6.3.2 TRAFFIC MULTI-FRAME

Logical channels that are being used for speech or data are considered a logical traffic channel.Traffic channels follow the communication structure shown in Figure 7-3. The traffic channelstructure consists of 26 consecutive occurrences of a logical channel. The first 12 occurrencesare used for traffic, one occurrence is used for control, 12 are used for traffic, and the finalchannel is idle. When urgent control data must be communicated, some of the slices reservedfor traffic may be changed to control. This is indicated through use of the stealing flag in eachpacket. All traffic messaging flows in the test environment mirror the traffic multi-framedefined in Figure 7-3 as closely as possible.

TEST ENVIRONMENT E

7-12

11/3/98 10:49 AM CHPT7.DOC


7.6.4 TDMA Super-FrameThe super-frame provides a mechanism for the signaling multi-frame and traffic multi-frame tomeet up at regular intervals. This frame type is not used in the test software emulation definedby this document because this time interval is not critical in the evaluation of using FDIsoftware in GSM systems. A super-frame is defined as 26 instances of the 51 frame signalingmulti-frame, or 51 instances of a 26 frame traffic multi-frame.

7.6.5 TDMA Hyper-FrameThe hyper-frame provides a timing interval on a larger scale. This frame type is not used in thetest software emulation defined by this document because this time interval is not critical in theevaluation of using FDI software in GSM systems.

7.6.6 Background CPU AvailabilityEach OEM’s background CPU availability is different due to architectural differences in eachimplementation. The background CPU availability created by the test software is modifiablethrough several different variables that determine the length of time it takes for a system to doseveral tasks that occur on a regular basis such as transmit, receive, monitoring otherfrequencies, and power level adjustments.

7.6.7 Communication ChannelsSeveral pre-defined channels exist to provide a guaranteed repeating time slot upon whichcertain messages are transmitted. These channels are pre-defined by the signaling and trafficmulti-frames as certain portions of the multi-frame. This provides mechanisms to allow themobile phone to originate messages, as well as to locate information about each cell as it movesabout a network. Below is an overview of the channels that exist and the type of informationsent on these channels. The GSM emulation software emulates the timing associated with usingthe appropriate channels for the appropriate messages.

There are several types of channels. These are defined as follows:

Traffic Channel (TCH)–Reserved for voice and data messaging.

Broadcast Channel (BCH)–Transmitted only by the base station. Intended to provideinformation to the mobile station to allow it to synchronize with the network.

Common Control Channels (CCCH)–Support the establishment of a dedicated link betweena mobile and a base station.

Dedicated Control Channels (DCCH)–Used for message transfers between the network andmobile station, not for traffic.

E TEST ENVIRONMENT

7-13

11/3/98 10:49 AM CHPT7.DOC


Associated Control Channels (ACCH)–Always used in association with a traffic channel(TCH) or Standard Dedicated Control Channel (SDCCH).

Channel Name Type Purpose

TCH Traffic Channel TCH Used to transmit user voice or data.

BCCH Broadcast ControlChannel

BCH Informs mobile station about system parameters itneeds to identify the network (cell options, neighboringcell frequencies, access parameters, location areacode, etc.).

FCCH Frequency CorrectionChannel

BCH Provides the mobile station with the frequencyreference of the system and helps in initialsynchronization.

SCH Synchronization Channel BCH Provides the training sequence the mobile stationneeds to demodulate information coming from thenetwork and indicates current frame number.

RACH Random Access Channel CCCH Used by the mobile station to request a dedicatedcontrol channel from the network.

PCH Paging Channel CCCH Used by the base station to call an individual mobilestation.

AGCH Access Grant Channel CCCH Used by the base station to inform the mobile whichdedicated channel it should use for its signaling needsand provides a channel description.

SDCCH Standalone DedicatedControl Channel

DCCH Used for transfer of information between the mobile andthe network.

SACCH Slow Associated ControlChannel

ACCH Used for control and measurement parameters orroutine data needed to maintain a link between themobile station and the network.

FACCH Fast associated ControlChannel

ACCH Used to replace all or part of a traffic channel totransfer information similar to that carried by theSDCCH.

7.7 POWER LOSS RECOVERY TESTINGTesting to ensure data is not lost when power is lost to the system is essential. The test softwareallows for skewing when power is lost to the system so that as many as possible power lossrecovery instances are emulated. In addition, special tests are performed to ensure a power lossduring recovery results in no loss of data.

11/3/98 10:49 AM CHPT8.DOC


E8

System ValidationTest Plan

E

8-1

11/3/98 10:49 AM CHPT8.DOC


CHAPTER 8SYSTEM VALIDATION TEST PLAN

8.1 INTRODUCTION

8.1.1 PurposeThis chapter describes the procedures used to test the Flash Data Integrator software system.These test activities were designed and executed by Intel’s Software Quality Assurance (SQA).SQA oversees the testing of Intel’s Flash Products Division (FPD) flash software systems, suchas FDI, developed for external customers.

8.1.2 ScopeThese tests were designed primarily by using the software’s specifications. A full systems testof basic FDI functionality and error handling capabilities is executed. Intensive testing isperformed on FDI’s critical features. Since the low-level flash driver may be interchanged orported to other processors, SQA does not design tests explicitly for the low-level code.Although the low-level flash driver is not the focus of these tests, it will be tested indirectlysince this code must execute correctly in order for a test to pass.

8.2 TEST ENVIRONMENT

8.2.1 HardwareThe following hardware is needed to perform the tests:

PC with an Ethernet port

Motorola 68360 evaluation board with a flash board

SYSTEM VALIDATION TEST PLAN E

8-2

11/3/98 10:49 AM CHPT8.DOC


8.2.2 SoftwareThe following software is installed on the PC:

Windows* NT, version 4.0

Wind River Systems - Tornado* environment (VxWorks, remote debugger, compiler,loader), version 1.0.1

System Environment Emulation Software

8.3 FEATURES TO BE TESTEDThe following features and combination of features will be tested.

FDI Feature Description FDI Function Call

Power-On Initialization FDI_Init

Open a Parameter or Data Stream FDI_Open

Close a Parameter or Data Stream FDI_Close

Delete a Parameter or Data Stream FDI_Delete

Get a Parameter or Data Stream FDI_Get

Read a Parameter or Data Stream FDI_Read

Write a Parameter or Data Stream FDI_Write

Reclaim Flash RECL_Task

Get Memory Statistics FDI_Statistics

Get Queue and Reclamation Status FDI_Status

Format FDI_Format

Performance All

ROM/RAM All

Flash Compatibility All

Mixing APIs All

Full Partition All

Stress All

Power Loss Recovery All

Data Streaming All

E SYSTEM VALIDATION TEST PLAN

8-3

11/3/98 10:49 AM CHPT8.DOC


8.4 ASSUMPTIONSMost of FDI’s functionality is controlled by FDI compile time options found in the type.h file.

The compile time options in the Config 1 column shown below were used to run the testsfound in this document. Most of the tests were run in other FDI configurations that are shown.Where applicable, tests have been changed to correspond with the applicable configurations.Some tests apply specifically to certain configurations. For example, data streaming tests areonly applicable when DATA_STREAM = TRUE and fragmented data tests are only applicablewhen INCLUDE_FRAGMENTED_DATA = TRUE.

Compile Options Config 1 Config 2 Config 3 Config 4 Config 5

Boot Blocks 0 0 1 1 16

Data Blocks 8 2 2 16 16

Num Parameters 100 100 100 100 100

Num Streams 10 10 10 20 20

Unit Granularity 128 128 128 128 128

Queue Size 1024 1024 1024 1024 1024

Block Size 8 KB 8 KB 8 KB 64 KB 64 KB

Auto Reclaim TRUE TRUE TRUE TRUE TRUE

Fragmented Data TRUE FALSE TRUE TRUE TRUE

Data Stream FALSE FALSE TRUE TRUE TRUE

TDMA 4615 4615 4615 4615 4615

8.5 APPROACHFDI test cases were created using a three-tier approach. Basic, low-level test cases will test FDIAPI functions for:

basic functionality with each possible sub-command.

boundaries and out of bounds checking of API inputs.

error handling.

Flash management tests involve using several FDI API functions to:

perform moderately complex FDI capabilities–for example, intermixing API calls,filling the flash with data, flash reclamations, etc.

writing data at a constant rate (i.e., data streaming).

Stress testing involves using FDI to:

simulate realistic GSM digital cellular phone activity for long periods of time.

recovery after system power off (power loss recovery).


8-4

11/3/98 10:49 AM CHPT8.DOC


8.6 FUNCTIONALITY, BOUNDARY, AND ERROR HANDLINGThese tests check each FDI API function for basic functionality, boundary input conditions, anderror handling capabilities.

8.6.1 Power-On Initialization (001)A special non-FDI erase flash subroutine will be used to test power-on initialization. This erasesubroutine will be capable of erasing specific data blocks.

8.6.1.1 TEST CASE 0011

Initialize an erased flash array.

Procedural Steps

1. Erase all flash blocks.

2. Call FDI’s initialize function.

3. Check error code returned for expected value.

Expected Results

The call to initialize FDI control structures will fail when the flash is erased. The initialize callwill return ERR_FORMAT.

8.6.1.2 TEST CASE 0012

Corrupt the format on the flash, then run initialize.

Procedural Steps

1. Initialize and format the flash.

2. Use the erase subroutine to erase the first data block.

3. Call FDI’s initialize function.

4. Check error code returned for expected value.

5. Repeat steps 1 through 4, but in step 2 erase the next data block. Repeat until the last datablock has been erased.


8-5

11/3/98 10:49 AM CHPT8.DOC


Expected Results

Each time initialize is called after erasing a data block, error code ERR_FORMAT will bereturned. One of the data blocks is the “spare” block. Initialize will return ERR_NONE aftererasing the spare block.

8.6.1.3 TEST CASE 0013

Execute initialize twice or more.

Procedural Steps


2. Execute initialize, with no other FDI calls in between, ten times.

Expected Results

The FDI initialize will return ERR_NONE after each call.

8.6.2 Open a Parameter or Data Stream (002)The following tests ensure proper operation of the FDI_Open command.

8.6.2.1 TEST CASE 0021

Check open’s ability to handle a variety of invalid input parameters.

Procedural Steps

Call FDI_Open with a number of invalid inputs (i.e., identifiers out of range, invalid types, andinvalid subcommands). Initialize and format the flash before executing this set of tests. Ifobserved error code not equal to expected error code, then fail.

Expected Results

FDI_Open will return ERR_PARAM if called with invalid inputs.


8-6

11/3/98 10:49 AM CHPT8.DOC


8.6.2.2 TEST CASE 0022

Call open function with values specified for input elements that are designated as reserved orunused.

Procedural Steps

This test is run a number of times to test multiple cases. The flash should be initialized andformatted before running this set of tests. If the error code returned is not equal to the expectederror code, then fail.

Expected Results

Entering input into unused and reserved input elements will not cause the function to fail. Alltest cases will complete normally and will return code ERR_NONE.

8.6.2.3 TEST CASE 0023

Open a parameter or data stream, then open the same parameter or data stream again.

Procedural Steps

Call FDI_Open with a variety of subcommands with consecutive calls to open the sameparameter or data stream. Before each test case, initialize and format the flash. If the observederror code does not equal the expected error code, then test fails.

Expected Results

Every test performed will return an error code. If a parameter is open more than once, the errorcode will be ERR_MAX_OPEN. If a data stream is open more than once, the error code equalsERR_OPEN.

8.6.2.4 TEST CASE 0024

Open a parameter or data stream that does not exist on the flash.

Procedural Steps

Call FDI_Open a number of times with identifiers that do not exist. Initialize and format theflash before executing this set of tests. If the observed error code does not equal the expectederror code, then test fails.

Expected Results

Trying to open a parameter or data stream which does not exist on the flash will causeFDI_Open to return ERR_NOTEXISTS.


8-7

11/3/98 10:49 AM CHPT8.DOC


8.6.3 Close a Parameter or Data Stream (003)The following tests ensure proper operation of the FDI_Close command.

8.6.3.1 TEST CASE 0031

Check close’s ability to handle a variety of invalid input parameters.

Procedural Steps

Call FDI_Close with a number of invalid inputs such as invalid identifiers and types. Callinitialize and format before each call to FDI_Close. If observed error code not equal toexpected error code, then fail.

Expected Results

FDI_Close will return ERR_PARAM if called with invalids inputs.

8.6.3.2 TEST CASE 0032

Call close function with values specified for input elements that are designated as reserved orunused.

Procedural Steps

Call FDI_Close with a number of “reserved” elements specified. Start with initializing andformatting the flash one time before running this set of tests. If error code returned is not equalto expected error code, then fail.

Expected Results


8.6.3.3 TEST CASE 0033

Close a parameter or data stream that does not exist.

Procedural Steps

Call FDI_Close specifying the identifier as a parameter or data stream that does not exist. Callinitialize and format before running these tests. If observed error code is not equal to expectederror code, then fail.


8-8

11/3/98 10:49 AM CHPT8.DOC


Expected Results

Closing a parameter which does not exist on the flash will cause FDI_Close to returnERR_NOTOPEN.

8.6.3.4 TEST CASE 0034

Close a parameter or data stream that is not open.

Procedural Steps

Call FDI_Close with a number of identifiers of parameter or data streams that exist, but are notopen. Call initialize and format before running these tests.

Expected Results

Closing a parameter that is not open will cause FDI_Close to return ERR_NOTOPEN.

8.6.4 Delete a Parameter or Data Stream (004)The following tests will ensure proper operation of the FDI_Delete function.

8.6.4.1 TEST CASE 0041

Check delete’s ability to handle a variety of invalid input parameters.

Procedural Steps

Call FDI_Delete with a number of invalid inputs such as invalid identifiers, types and priority.Call initialize and format before running these tests. If observed error code not equal toexpected error code, then fail.

Expected Results

FDI_Delete will return ERR_PARAM if called with invalid inputs.


8-9

11/3/98 10:49 AM CHPT8.DOC


8.6.4.2 TEST CASE 0042

Call delete function with values specified for input elements that are designated as reserved orunused.

Procedural Steps

Call FDI_Delete a number of times specifying values for reserved elements. Initialize andformat the flash before running this set of tests. If error code returned is not equal to expectederror code, then fail.

Expected Results

Entering input into unused and reserved input elements will not cause FDI_Delete to fail. Alltest cases will complete normally and will return code ERR_NONE.

8.6.4.3 TEST CASE 0043

Delete a parameter or data stream that does not exist.

Procedural Steps

Call FDI_Delete a number of times specifying an identifier of a parameter or data stream thatdoes not exist. Call initialize and format before running these tests. If observed error code notequal to expected error code, then fail.

Expected Results

Deleting a parameter which does not exist on the flash will cause FDI_Delete to returnERR_NOTEXISTS.

8.6.4.4 TEST CASE 0044

Delete a parameter or data stream that is open.

Procedural Steps

Call FDI_Delete several times, specifying identifiers of parameter or data streams that arealready open. Call initialize and format before running these tests.

Expected Results

Deleting a parameter that is open will cause FDI_Delete to return ERR_OPEN.


8-10

11/3/98 10:49 AM CHPT8.DOC


8.6.4.5 TEST CASE 0045

Fill the flash with the maximum number of parameters. Delete the first parameter, then try toopen it. Repeat these steps, deleting the next parameter until the last parameter has beendeleted.

These tests will first be run using multiple instance parameters of size 16, then repeated withsingle instance parameters of size 100, and finally run with fragmented parameters of size 513.

Procedural Steps

Before each test case, initialize and format the flash. If the observed error code does not equalthe expected error code, then test fails.

Expected Results

Each FDI_Delete call will return ERR_NONE. Each parameter deletion will be verified bytrying to open the parameter and then checking that ERR_NOTEXISTS is returned.

8.6.5 Get a Parameter or Data Stream (005)The following tests will ensure proper operation of the FDI_Get function.

8.6.5.1 TEST CASE 0051

Check get’s ability to handle a variety of invalid input parameters.

Procedural Steps

Call FDI_Get with several invalid inputs such as identifiers out of range, invalid subcommands,types and priorities. Call initialize and format before running these tests. If error code returnedis not equal to expected error code, then the test fails.

Expected Results

Calling FDI_Get with invalid inputs will cause the function to return ERR_PARAM.


8-11

11/3/98 10:49 AM CHPT8.DOC


8.6.5.2 TEST CASE 0052

Call get function with values specified for input elements that are designated as reserved orunused. Also, specify values for input elements that are not used with a specific subcommand(i.e., identifier is not used with GET_FIRST or GET_NEXT).

Procedural Steps

Call FDI_Get with values specified in reserved or unused locations. Start with initializing andformatting the flash before running these tests. If error code returned is not equal to expectederror code, then fail.

Expected Results


8.6.5.3 TEST CASE 0053

Get parameter or data stream that does not exist.

Procedural Steps

Call FDI_Get with the identifier specifying a parameter or data stream that does not exist. Callinitialize and format before running each test case. If observed error code not equal to expectederror code, then fail.

Expected Results

Calling get for a parameter or data stream that does not exist results in the errorERR_NOTEXISTS.

8.6.5.4 TEST CASE 0054

Get parameter or data stream that is open.

Procedural Steps

Call FDI_Get with several identifiers of parameters or data streams that are already open. Callinitialize and format before running these tests. If the observed error code does not equal theexpected error code, then test fails.

Expected Results

Calling get for a parameter that is open should return the error code ERR_NONE.


8-12

11/3/98 10:49 AM CHPT8.DOC


8.6.5.5 TEST CASE 0055

Open a parameter for create, close the parameter, then get the parameter. Run the same tests fora data stream.

Procedural Steps

Call FDI_Get for a number of parameters and data streams. Call initialize and format beforerunning these tests. If the observed error code and count do not equal the expected results, thentest fails.

Expected Results

A zero-size file is not allowed, and therefore when a parameter or data stream is opened andclosed, without any writing in between, no parameter is created. The FDI_Get call in all testcases will return ERR_NOTEXISTS.

8.6.5.6 TEST CASE 0056

Get different parameter types.

Procedural Steps

1. Create six streams of types 1 through 6.

2. Get the six streams using get first.

3. Create four more streams of type 6.

4. Get the first and second type 6 streams.

5. Get all streams using get matched.

Expected Results

The FDI_Get function will successfully get all of the streams and return ERR_NONE.


8-13

11/3/98 10:49 AM CHPT8.DOC


8.6.6 Read a Parameter or Data Stream (006)The following tests will ensure proper operation of the FDI_Read function.

8.6.6.1 TEST CASE 0061

Check read’s ability to handle a variety of invalid inputs.

Procedural Steps

Call FDI_Read with a number of invalid inputs such as identifiers, types and priorities. Callinitialize and format before running these tests. If observed error code not equal to expectederror code, then test fails.

Expected Results

Calling FDI_Read with invalid inputs will cause the function to return ERR_PARAM.

8.6.6.2 TEST CASE 0062

Read a parameter without opening the parameter or data stream.

Procedural Steps

Call FDI_Read for a number of closed parameters and data streams. Call initialize and formatbefore executing this set of tests. If observed error code is not equal to the expected error code,then test fails.

Expected Results

A or parameter or data stream can be read without opening the parameter. Therefore, all testcases will complete normally with ERR_NONE.

8.6.6.3 TEST CASE 0063

Read parameters with input’s count and offset that are inconsistent with the actual parameterson the flash to be read.

These tests will first be run using multiple instance parameters of size 3, then repeated withsingle instance parameters of size 124, and finally run with fragmented parameters of size 900.

Procedural Steps

Call FDI_Read for several different parameters. Call initialize and format before executing thisset of tests. If the error code returned is not equal to the expected error code, then test fails.Also, if output element “actual” is not equal to the expected value, then test fails.


8-14

11/3/98 10:49 AM CHPT8.DOC


Expected Results

Calling FDI_Read with invalid parameters will result in ERR_PARAM being returned.

8.6.6.4 TEST CASE 0064

Call the read function with values specified for input elements that are defined as reserved orunused. Also, specify values for input elements that are not used.

Procedural Steps

Call FDI_Read with a number of reserved or unused elements specified. Start with initializingand formatting the flash one time before running this set of tests. If error code returned is notequal to expected error code, then fail.

Expected Results


8.6.7 Write a Parameter or Data Stream (007)The following set of tests ensure the proper operation of the FDI_Write function.

8.6.7.1 TEST CASE 0071

Check write’s ability to handle a variety of invalid inputs.

Procedural Steps

Call FDI_Write with a number of invalid inputs (i.e., identifiers out of range, invalid types, andpriorities). Call initialize and format before each call to FDI_Write. If observed error code notequal to expected error code, then test fails.

Expected Results

Calling FDI_Write with invalid inputs will cause the function to return ERR_PARAM.


8-15

11/3/98 10:49 AM CHPT8.DOC


8.6.7.2 TEST CASE 0072

Write a parameter or data stream without opening it first.

Procedural Steps

Call FDI_Write several times for writing a variety of parameters and data streams. Initializeand format the flash before executing this set of tests. If observed error code is not equal to theexpected error code, then test fails.

Expected Results

A parameter or data stream can be written without being open first. Therefore, all test caseswill complete normally with ERR_NONE.

8.6.7.3 TEST CASE 0073

Write data with input’s count and offset that are inconsistent with the parameter on the flash.

Procedural Steps

Call FDI_Write several times with invalid elements. Initialize and format the flash beforeexecuting this set of tests. If observed error code is not equal to the expected error code, thentest fails.

Expected Results

When calling FDI_Write with invalid parameters, ERR_PARAM is expected.

8.6.7.4 TEST CASE 0074

Create maximum number of parameters on the flash. Read the contents of each parameterwritten and compare against what is known to have been written.

These tests will first be run using multiple instance parameters of size 14 bytes, then repeatedwith single instance parameters of size 124 bytes, and finally run with fragment parameters ofsize 600 bytes.


8-16

11/3/98 10:49 AM CHPT8.DOC


Procedural Steps


2. Open for create, write, and close 100 parameters containing a known binary pattern to theflash.

3. Read parameter from flash. When executing this line for the first time, read the firstparameter, or else read the next parameter.

4. Compare the parameter contents against the binary pattern. If mismatch, then test fails.

5. Repeat steps 3 and 4 until all parameters have been read.

Expected Results

The contents of each parameter written will be read and verified to contain the correct data. Allfunctions should return ERR_NONE.

8.6.7.5 TEST CASE 0075

Append data to parameters on the flash.

These tests will first be run using multiple instance parameters of size 16, then repeated withsingle instance parameters of size 100, and finally run with fragment parameters of size 514.

Procedural Steps


2. Open for create, write, and close 100 parameters containing a known binary pattern to theflash.

3. Open for modify, write append, and close the 100 parameters. For each write append writeX bytes of a second known binary pattern to the end of the first X bytes.

4. Verify the data contents of each parameter.

Expected Results

All test cases will complete successfully, and all API calls will return ERR_NONE.

8.6.7.6 TEST CASE 0076

Replace existing data on the flash.



8-17

11/3/98 10:49 AM CHPT8.DOC


Procedural Steps


2. Open for create, write, and close 100 parameters.

3. Open for modify, replace the last half, and then close each parameter.


Expected Results

All test cases will complete normally, and all API calls will return ERR_NONE.

8.6.7.7 TEST CASE 0077

Reserve and modify data.


Procedural Steps


2. Open for create, write, and close 100 parameters.

3. Open for modify, write modify X bytes, and close each parameter.


Expected Results

All test cases will complete normally, and all API calls will return ERR_NONE.

8.6.7.8 TEST CASE 0078

Call the write function with specified values for input elements that are designated as reservedor unused.

Procedural Steps

Call FDI_Write with a number of input elements specified that are unnecessary. Start withinitializing and formatting the flash one time before running this set of tests. If error codereturned is not equal to expected error code, then fail.

Expected Results



8-18

11/3/98 10:49 AM CHPT8.DOC


8.6.7.9 TEST CASE 0079

Create a multi-instance parameter that gets changed to fragmented parameter.

Procedural Steps

1. Write append 30 bytes to a parameter.

2. Write append 970 bytes at offset 30.

3. Write append 970 bytes at offset 1000.

4. Verify parameter 0.

Expected Results

Parameter 0 will be verified to contain the correct data.

8.6.8 Reclaim Flash (008)The following tests are run to ensure proper operation of the reclaim function in FDI.

8.6.8.1 TEST CASE 0081

Test automatic reclaim by filling the flash with data and then deleting several times.

Procedural Steps


2. Write data streams to flash until out of space.

3. Delete all data streams on flash.

4. Repeat steps 2 and 3 five times.

Expected Results

Data will be written to the flash until full and then deleted five times with no errors. Reclaimswill occur in the background when necessary.


8-19

11/3/98 10:49 AM CHPT8.DOC


8.6.9 Get Memory Statistics (009)The following tests will be run to ensure proper operation of the statistics function.

8.6.9.1 TEST CASE 0091

Validate free units after formatting the flash and writing some parameters.

Procedural Steps

1. Initialize and format flash. Get free units.

2. Create one multi-instance parameter. Get free units and compare against expected.

3. Create one single-instance parameter. Get free units and compare against expected.

4. Create one small fragmented parameter. Get free units and compare against expected.

5. Create one large fragmented parameter. Get free units and compare against expected.

Expected Results

The expected free units, which is manually calculated for each parameter written, will equal theactual free units returned from FDI_Statistics.

8.6.9.2 TEST CASE 0092

Check free and dirty units for negative results.

Procedural Steps

1. Fill the flash with a variety of different size parameters.

2. Call FDI_Statistics and check free and dirty units for negative results.

Expected Results

Free and dirty units will never be negative.


8-20

11/3/98 10:49 AM CHPT8.DOC


8.6.10 Get Queue and Reclamation Status (010)The following tests ensure proper operation of the status function.

8.6.10.1 TEST CASE 0101

Check output of FDI_Status after performing some basic parameter management tasks.

Procedural Steps

Initialize and format the flash, then execute a number of tests all followed by the FDI_Statuscommand. If the status returned by FDI_Status is not equal to the expected status code, thenthe test fails.

Expected Results

FDI_Status will successfully report the correct status after each test.

8.6.11 Format (011)The following tests will ensure proper operation of the format command.

8.6.11.1 TEST CASE 0111

Format an erased flash array.

Procedural Steps

1. Erase the flash.

2. Format the flash.

3. Check error code returned for expected results.

Expected Results

The call to format the flash will return ERR_NONE. The FDI formatter can format an erasedflash.


8-21

11/3/98 10:49 AM CHPT8.DOC


8.6.11.2 TEST CASE 0112

Corrupt the format on the flash, then format the flash.

Procedural Steps


2. Erase the first data block.

3. Call initialize, and then format the flash.

4. Check error code returned from format in step 3 for expected value.

5. Repeat steps 1 through 4, but erase the next data block (step 2), until the last data block hasbeen erased.

Expected Results

The call to format the flash will return ERR_NONE. The FDI formatter can format the flashthat has a corrupt format.

8.6.12 Performance (012)

8.6.12.1 TEST CASE 0121

Measure FDI’s read and write speed.

Procedural Steps


2. Open a parameter.

3. Start timer, write a 100-KB parameter, and stop timer.

4. Close the parameter.

5. Repeat step 1, but this time read the parameter.

6. Repeat this procedure with different FDI configurations.

Expected Results

Performance shall meet or exceed marketing requirements.


8-22

11/3/98 10:49 AM CHPT8.DOC


8.6.13 ROM/RAM (013)

8.6.13.1 TEST CASE 0131

Measure FDI’s ROM/RAM usage.

Procedural Steps

1. Compile FDI with VxWorks.

2. Use symbol map to determine ROM/RAM usage.

3. Repeat this procedure with different FDI configurations.

Expected Results

ROM/RAM usage shall meet or be less than marketing requirements.

8.6.14 Flash Compatibility (014)

8.6.14.1 TEST CASE 0141

Test FDI with different flash components.

Procedural Steps

All previously monitored test cases will be run using different Intel Flash components.

Expected Results

All test cases will execute successfully.


8-23

11/3/98 10:49 AM CHPT8.DOC


8.7 FLASH MANAGEMENT TESTSThese tests are run to test FDI’s overall ability to manage the flash memory.

8.7.1 Mixing APIs (015)

8.7.1.1 TEST CASE 0151

Intermix writes to different parameters and data streams.

Procedural Steps

1. Create five parameters.

2. Write append some data to each of the parameters.

3. Repeat step 2 but change the order of the parameters that are appended.

4. Get and verify each parameter.

Run tests several times for different size parameters and data streams.

Expected Results

Each test will complete successfully.

8.7.1.2 TEST CASE 0152

Procedural Steps

Fill the flash with a variety of parameters and data streams.

Procedural Steps

1. Fill the flash with a variety of parameters and data streams.

2. Delete parameters which fill half of the flash.


Expected Results

The test will complete successfully.


8-24

11/3/98 10:49 AM CHPT8.DOC


8.7.1.3 TEST CASE 0153

Create, delete, and re-create parameters.

Procedural Steps

1. Fill flash with four parameters and four data streams of various sizes.

2. Delete two parameters.

3. Write replace other two parameters and two of the data streams.

4. Re-create the two parameters that were deleted.

5. Repeat steps 2 through 4 ten times.

Expected Results

The test will complete successfully

8.7.2 Full Partition (016)

8.7.2.1 TEST CASE 0161

Replace parameters which occupy all of the flash.

Procedural Steps

1. Create some small parameters.

2. Create one large data stream which fills the rest of the flash.

3. Replace the one small parameter and the large data stream ten times.

Repeat this test with a number of different size parameters.

Expected Results



8-25

11/3/98 10:49 AM CHPT8.DOC


8.7.2.2 TEST CASE 0162

Read a parameter while write reserving and modifying another parameter when the flash isalmost full.

Procedural Steps

1. Write a parameter which almost fills the flash.

2. Write reserve and modify another parameter which fills the rest of the flash. While writereserve and modifying this parameter, read portions of the other parameter which hasalready been written.

Expected Results


8.7.2.3 TEST CASE 0163

Write past the end of the flash partition.

Procedural Steps

1. Write several parameters which fill the flash.

2. Once the flash is full, write another parameter 50 times.

Expected Results

FDI_Write will return ERR_FLASH_FULL error messages when writing past the end of thepartition.


8-26

11/3/98 10:49 AM CHPT8.DOC


8.7.2.4 TEST CASE 0164

Write past the end of the flash partition.

Procedural Steps

1. Write several parameters and data streams which fill the flash using write appends andreserves/modifies.

2. Replace part of a data stream.

3. Read some parameters. While reading, delete some parameters,

4. Create a parameter which fills the partition. Create the parameter using first write reservesand modifies, and then write appends.

5. Repeat steps 2 through 4 five times.

Expected Results

FDI_Write will return ERR_FLASH_FULL error messages when writing past the end of thepartition.

8.8 STRESS, POWER LOSS RECOVERY, AND DATASTREAMING TESTS

These tests simulate realistic GSM digital cellular phone activity for long periods of time.

8.8.1 Stress (017)

8.8.1.1 TEST CASE 0171

Create and delete random sized parameters and data streams.

Procedural Steps

1. Create random size parameters between 512 bytes and 100 KB until the flash is full.

2. Delete all parameters.

3. Repeat steps 1 and 2 fifty times.

Expected Results

The test will complete with no errors.


8-27

11/3/98 10:49 AM CHPT8.DOC


8.8.2 Power Loss Recovery (018)A power loss recovery test resets the flash at specific points in time after starting an FDIcommand, and then performs an FDI_Init to validate the contents of the flash immediately afterrecovering from the power loss. A thorough power loss recovery test slews the reset at all clocktimes throughout the duration of an FDI command. In this manner, we can simulate a powerloss occurring at all possible times during the execution of an FDI command.

8.8.2.1 TEST CASE 0181

Testing single power loss.

Procedural Steps

Create a loop around various types of FDI operations, causing a reset and FDI_Init to occurduring each possible time during the operation.

The operations to be tested include creating single instance data, creating fragmented data,creating multi-instance data, deleting the different data types, replacing the different data types,creating a second sequence table, creating a second group table, appending data to existing data,and performing a reclaim.

Expected Results

FDI_Init after the reset returns an ERR_NONE.

8.8.2.2 TEST CASE 0182

Testing power loss during power loss.

Procedural Steps

To test power loss during power loss recovery, add a second reset and FDI_Init that occur whileFDI is performing its recovery from the first reset. Slew the reset at all clock times throughoutthe duration of the recovery operation that was caused by the first reset.

The set of FDI operations to be tested are the same as for single power loss.

Expected Results

The second FDI_Init will return an ERR_NONE.


8-28

11/3/98 10:49 AM CHPT8.DOC


8.8.3 Data Streaming (019)

8.8.3.1 TEST CASE 0191

Write data streams at a constant data rate but with various periods and write sizes.

Procedural Steps


2. Write six data streams to the flash at data rate 1024 bytes/sec. Write the first data streamwith write size of 512 bytes and period necessary to maintain the data rate.

3. Decrease the write size by one half and the period as needed to maintain the data rate, andthen write the stream.

4. Get and delete the six streams.

5. Repeat steps 1 through 4 with data rates 1800 bytes/sec and 2048 bytes/sec.

Repeat these tests using FDI_Write with subcommands append and reserve/modify.

Expected Results

The data streams will be created successfully at 1024, 1800, and 2024 bytes/sec.

8.8.3.2 TEST CASE 0192

Write data streams to flash with increasing data rates and fixed write sizes.

Procedural Steps

1. Write a stream with write count of 512 bytes, and total size of 75 KB.

2. Repeat step 1 five more times, but increase the data rate each time a new stream is written.

3. Get and delete the six streams.

Repeat the above test using FDI_Write with subcommands append and reserve/modify

Expected Results

The test will create streams at increasing data rates until FDI’s maximum sustainable data rateis reached.


8-29

11/3/98 10:49 AM CHPT8.DOC


8.8.3.3 TEST CASE 0193

Fill the flash with data and then write a data stream with increasing data rates and fixed size.

Procedural Steps

1. Write fourteen 48128-byte parameters.

2. Delete the last parameter.

3. Write a data stream of size 512 bytes.

4. Repeat steps 2 and 3 until FDI maximum sustainable data rate is reached. In step 3,increase the data rate each time a new parameter is written.

Repeat the above test using the append reserve/modify subcommands of FDI_Write.

Expected Results


8.8.3.4 TEST CASE 0194

Write large data streams at increasing data rates and fixed sizes.

Procedural Steps

1. Write a data stream until an ERR_FLASH_FULL error occurs.

2. Delete the data stream.

3. Repeat steps 1 and 2 until FDI’s maximum sustainable data rate is reached. In step 1,increase the data rate each time a stream is written.

Run the test using both the append and reserve/modify methods of FDI_Write.

Expected Results



8-30

11/3/98 10:49 AM CHPT8.DOC


8.8.3.5 TEST CASE 0195

Simulate voice message storage management.

Procedural Steps

1. Create ten parameters of various sizes.

2. Write reserve eleven data streams which fill about 70% of the flash.

3. Write modify ten data streams at 2 KB/s data rate.

4. Delete the oldest stream modified.

5. Write modify the data stream that was reserved last at 2 KB/s.

6. Write reserve the data stream that was deleted last.

7. Repeat steps 4, 5, and 6, 50 times.

Expected Results

The test will complete execution with no errors. Streams will be created in a circular bufferprocess.

8.8.3.6 TEST CASE 0196

Create random size data streams at 2 KB/s until the flash is full, delete all, and repeat.

Procedural Steps

1. Create a number of data streams at 2 KB/s until flash is full.

2. Delete all data streams.

3. Repeat this test 20 times.

Repeat this test using the append and reserve/modify subcommands in FDI_Write.

Expected Results

This test will complete with no errors.


8-31

11/3/98 10:49 AM CHPT8.DOC


8.8.3.7 TEST CASE 0197

Create a fixed number of random size data streams, get, read, and delete them.

Procedural Steps

1. Write ten data streams which almost fill the partition.

2. Delete the streams created in step 1.

3. Write ten random size data streams at 2KB/s. The streams will range in total size from 512bytes to maximum size divisible by 512 bytes.

4. Get the ten streams using get first, get next, and get matched, and then read the streams.

5. Delete the data streams created in step 3.

6. Repeat steps 3 and 5 ten times.

Run this test using both the append and reserve/modify subcommands in FDI_Write.

Expected Results


8.7.3.8 TEST CASE 0198

Intermix data streaming and non-data streaming.

Procedural Steps

1. Create four parameters.

2. Write a 20 KB data stream at 2 KB/s.

3. Write append to the first parameter.

4. Write another 20 KB to the data stream at 2 KB/s.

5. Write replace the second parameter.


7. Write modify the third parameter.


9. Read the fourth parameter.


11. Get the parameters and data stream.

Run this test by writing to the data stream using both the append and reserve/modify FDI_Writesubcommands.


8-32

11/3/98 10:49 AM CHPT8.DOC


Expected Results


8.8.3.9 TEST CASE 0199

Create and replace many multi-instance, single instance, and fragmented parameters at 2 KB/s.

Procedural Steps

1. Create and replace 100 parameters and 20 data stream multi-instance parameters at 2 KB/s.


3. Create and replace 100 parameters and 20 data stream single-instance parameters at 2KB/s.


5. Create and replace 100 parameters and 20 data stream fragmented parameters at 2 KB/s.


Expected Results


8.8.3.10 TEST CASE 0190

Data stream without loops.

Procedural Steps

1. Write ten streams of various sizes at 2 KB/s. Do not use any loops. The write reserves andwrite modifies are coded sequentially.

2. Delete the ten streams.


Expected Results


11/3/98 1:49 PM APPENA.DOC


EA

FAQs

E

A-1



APPENDIX AFAQs

A.1 OVERVIEWThis appendix contains questions and answers relating to Intel’s Flash Data Integrator softwareused for real-time code plus data storage in a single flash memory component. This documentassumes the reader is familiar with the information in Chapter 5, Architecture and APISpecification.

Q & As are organized in the following categories:

• Hardware

• Software

• Reclaim

• General

A.2 HARDWARE QUESTIONS

1. What if the system cannot withstand a 20 µs latency for erase suspend or 10 µs for programsuspend?

The 20 µs latency is only associated with Erase suspend. An erase operation occurs onlyduring a reclaim process. FDI includes a mechanism to allow the programmer to schedulereclaims during non-critical times. Then maximum latency is based on program suspend,which is a maximum 10 µs. If the system cannot support scheduled reclaims, a portion ofthe interrupt handler would need to be loaded into system RAM to allow code execution forthe 10 µs or 20 µs period. Intel continues to evaluate improvement of suspend latencyperformance.

2. Are nested erase and program suspends supported? In other words, can you suspend a writeto read after you have suspended an erase?

Yes, the architecture supports erase suspend to program and a subsequent program suspendto read.

FAQs E

A-2



A.3 SOFTWARE QUESTIONS

1. What SW effort is there in integrating FDI?

Feature Intel FDI OtherOEM Solution

Flash Data Integrator (FDI) Architecture included 2400 devl.-hrs

Flash Parameter Storage Management included 3000 devl.-hrs

Flash Storage Management Reclaim included 3000 devl.-hrs

EEPROM Interface included 450 devl.-hrs

Power Loss Recovery included 2350 devl.-hrs

Flash Suspend/Resume Interface and Testing included N/A

API Integration 400 devl.-hrs N/A

Total 400 devl.-hrs 11,200 devl.-hrs

2. What is the FDI code size? What is the RAM size requirement for FDI?

Code size equals 20 KB–40 KB depending on which features are enabled. RAM usage is2 KB–3 KB for the data queue and flash memory drivers; RAM usage will be slightlylarger when operating with high-speed data streams.

3. What variables affect the RAM buffer size when using FDI? And, how does the FDI RAMbuffer size compare to that required for RWW solutions with specialized circuits (HWRWW) and for EEPROM?

The estimated data throughput affects the RAM buffer size. The available MIPS from theprocessor also affects the RAM buffer size. The FDI RAM buffer size is identical to whatwould be needed for HW RWW. The RAM buffer for FDI is actually less, in most cases,than what OEMs are using today with EEPROM. Many OEMs mirror all parameters inRAM and EEPROM.

4. What happens if a higher priority read occurs during a lower priority read?

Read operations are not queued. The lower priority read will complete and then the higherpriority read will be executed.

5. Why are unit headers independent of data?

Having unit headers independent of data allows any algorithms that scan information in ablock to automatically index through the headers instead of having to calculate the size ofthe information it must skip over to reach the next unit header. This gives an applicationfaster access to the data it is needing to read or write.

E FAQs

A-3



6. Can you stream data over a block boundary?

Group and sequence tables are included in the FDI architecture to support the managementof large pieces of data. The group and sequence tables are used to point to data across blockboundaries.

7. Does FDI support data re-packing?

Data re-packing consumes power to rewrite data that already exists in flash. Rather than re-packing data, FDI uses an instance table to track data.

8. Is there flexibility in FDI to limit EEPROM replacement across a smaller number ofparameter blocks (e.g., use three or four blocks instead of six or eight)? Can code be storedin the non-used parameter blocks?

FDI requires that at least two blocks are used for data storage. There are compile timeoptions to identify the data block size (8 KB or 64 KB) and exactly which blocks are usedfor data storage. Code can be stored in all blocks not designated for use by FDI.

9. Will stale data be read if a read occurs prior to queued data being written to flash?

FDI uses a look aside technique: the valid instance is first read from flash then FDI looks inthe RAM queue to see if the data has been superseded. The most current instance of thedata is returned.

10. Why is cycle count contained in the block information?

The cycle count is incremented every time the block is reclaimed. This information is usedby FDI for wear-leveling. Wear-leveling ensures that all FDI blocks are erased a similarnumber of times which can significantly extend the life of the flash device. A compileoption allows users to determine if they would like this information to be used and toinfluence which block is chosen during a reclaim.

11. What are the benefits of wear-leveling?

Wear-leveling allows all blocks to be used at an equal rate. If wear-leveling is not used, thiscan cause some blocks to reach maximum erase cycling before other blocks. For example,without wear-leveling, blocks with fixed data (does not get updated) are not cycled as muchas blocks with changing data. If wear-leveling is used, it may require the reclaim of a blockthat has little or no invalid data in the block. This causes an occasional extra reclaim,however, the block with a lower cycling count can now be cycled with changing data.

12. How are variable size parameters handled by FDI?

FDI has three different types of data structures to handle small, medium, and largeparameters. Multiple instance data structures allow several instances of a small parameterto be stored in one unit granularity. Medium-size parameters, ones that can typically bestored within three unit granularities, are stored in a single instance data structure. Finally,very large parameters are stored in fragments which are indexed into via group andsequence tables.

FAQs E

A-4



13. Why did Intel select the multiple instance data structure? What is the “expense” ofmanaging smaller granularity data?

The multiple instance data structure allows a parameter or small data object to be updatedwith minimal modifications to overhead. Typically an update to data that is being trackedin a multiple instance structure entails updating three status bits in addition to the data.When a new multiple instance structure is created, it entails updating an 8-byte unit headeralong with the size and status information in the multiple instance structure. In comparison,using a single instance structure would waste several bytes in the allocated data unit, aswell as cost an 8-byte unit header update and a single bit status update with each update tothe parameter.

14. How does FDI handle high priority data writes if data is pending in the RAM queue?

The FDI data queue is prioritized. The most important parameter is written first.

15. Is FDI as safe as using an EEPROM in the event of power failure?

FDI includes status fields within the data parameter structure as well as the physical blockinformation field. This information is used during the initialization process to detect if datawas not successfully written or if a reclaim process did not complete. EEPROMmanagement software does not normally include similar levels of protection. If power isremoved during an EEPROM write, the data may be corrupted. In general, FDI offers anincreased level of data protection over EEPROM use.

A.4 RECLAIM QUESTIONS

1. What is reclaim?

When a flash block is full (or near full), the valid data within that block must be copied toanother block. Data writes are then done to the new block. The reclaim process (a) copiesvalid data from a full or near full block to a spare block and (b) erases the full or near fullblock. Reclaim is sometimes referred to as “garbage collection.”

2. How do you suspend a reclaim?

A reclaim is suspended through system interrupts. This can be a hardware or softwareinterrupt.

3. What feedback does FDI provide following a reclaim?

An API function (FDI_Statistics) exists to allow the application to monitor the state ofmemory. An API function (FDI_Status) exists to allow the application to monitor the statusof reclaim as well as the status of the RAM data queue.

4. How long does it take to reclaim as a function of data reclaimed?

Reclaim time = erase time + (write time * number bytes copied in reclaim) + softwareoverhead time.

E FAQs

A-5



5. What if RP# is asserted during a reclaim? Is the reclaim operation aborted? If it is, how isthis handled since power was not removed and the initialization routine will not beexecuted?

If RP# is connected to the system reset, power loss recovery algorithms will deal with anyissues during the normal FDI_Init call.

6. What statistics are available on how often is it necessary to do a reclaim?

The FDI_Statistics function provides the total free space available as well as the totalinvalid space. There is one threshold that is user-configurable that allows the user todetermine when a reclaim should be initiated by the file system. Once the file systemdetermines that a reclaim should occur, it can either handle the reclaim automatically, orrequest permission from the application (through the use of a semaphore). Permission toreclaim can be granted through the FDI_Reclaim function. During reclaim, new data can bewritten until a second threshold is reached that indicates a full memory.

7. Can you write data during a reclaim suspend?

The Intel’s Flash drive device architecture supports erase suspend to read or program. So,during the erase portion of a reclaim, the reclaim can be suspended to write data. Allportions of the reclaim can be suspended to read.

A.5 GENERAL QUESTIONS

1. Can I implement FDI on a device that does not have program suspend? Can I implementFDI on a device that does not have erase suspend?

This depends on the latencies that are allowable on the system. If the system can accept alatency as large as the device’s maximum program time, then FDI can be used on a devicewithout program suspend. If the system can accept a latency as large as the device’smaximum erase time, then FDI can be used on a device without erase suspend. This mayalso require that the system has latched or “sticky” interrupts.

2. If the CPU does not support “sticky” interrupts, how can FDI work?

Any interrupt line is raised high for a minimum period of time. If this time is greater thanthe maximum interrupt detection time in the flash interrupt polling algorithm, then FDI willdetect the interrupt before the interrupt line transitions.

3. Can data be stored in the main blocks as well?

FDI allows data to be stored in either the 8-K parameter blocks or 64-K main blocks.

4. Will FDI support data storage in both the parameter and main blocks simultaneously?

Combining 8-KB and 64-KB blocks together is not impossible, however, the currentsoftware algorithms do not support this option. The spare block must remain the size of thelargest data block. Extra algorithms are required to allow a combination file system.

FAQs E

A-6



5. Does FDI have any “security” built into it to ensure that my code is safe when writingdata?

The flash program and erase algorithms perform boundary checks on the flash addressespassed in to the algorithm. This boundary check ensures that the address being accessedfalls within the flash data area being managed.

6. Has FDI been verified on other digital cellular standards like CDMA, DAMPS, or PDC?

Yes, Intel has customers using FDI with each of these cellular standards as well as others.

7. Does Intel have any intentions to standardize this software?

Yes, Standardization at the API level is currently being pursued.

8. What are the licensing rights?

OEMs have royalty-free derivative rights to all source code.

9. What if I need a multi-chip solution? Will FDI still work?

Yes, As long as the memory map for the area being managed by FDI is contiguous.

10. Is FDI affected by voltage?

Reclaim and programming performance are directly impacted by voltage. Lower voltagesresult in slower reclaim performance and program throughput.

11. Should fixed parameters be handled in the same manner as parameters that are updateable?

Fixed parameters should be grouped together into larger parameters. Any of the individualportions of the larger parameter can still be read using an offset with the FDI_Readcommand. Grouping fixed parameters in this manner allows less media waste due togranular memory allocations and prevents the data from being placed into multiple instancestructures in which the extra instances will never get used.

11/3/98 10:58 AM APPENB.DOC


EB

Documentation andTechnical Support

E

B-1



APPENDIX BDOCUMENTATION AND TECHNICAL SUPPORT

B.1 DOCUMENTATION

Order Number Document/Tool

210830 Flash Memory Databook

290644 3 Volt Fast Boot Block Flash Memory 28F800F3, 28F160F3 (x16) Datasheet

290645 3 Volt Advanced+ Boot Block Memory 28F008/800C3, 28F016/160C3,28F032/320C3 (x8/x16) Datasheet

290580 3 Volt Advanced Boot Block Flash Memory28F004/400B3,28F008/800B3,28F016/160B3, 28F032/320B3 (x8/x16) Datasheet

292213 AP-655 Fast Boot Block Design Guide

292216 AP-658 Designing for Upgrade to the Advanced+ Boot Block Flash Memory

292148 AP-604 Using Intel’s Boot Block Flash Memory Parameter Blocks to ReplaceEEPROM

292199 AP-641 Achieving Low Power with 3 Volt Advanced Boot Block Flash Memory

292200 AP-642 Designing for Upgrade to 3 Volt Advanced Boot Block

297874 FDI Interactive

Contact your local IntelSales Representative

FDI Developer’s Kit

297846 Comprehensive User’s Guide for µBGA* Packages

See Intel’s Website µBGA* Package Mechanical and Shipping Media Specifications

NOTES:

1. Please call the Intel Literature Center at (800) 548-4725 to request Intel documentation. Internationalcustomers should contact their local Intel or distribution sales office.

2. Visit Intel’s World Wide Web home page at http://www.Intel.com for technical documentation and tools.

DOCUMENTATION AND TECHNICAL SUPPORT E

B-2



B.2 TECHNICAL SUPPORTIntel provides extensive customer support for all of its products. For technical assistance onflash memory products, please contact Intel’s Customer Support (ICS) team at 1-800-628-8686.You may also send electronic mail to the ICS team [e-mail* address: [email protected]].The e-mail* must be of the following form (Note: the colon following each keyword isrequired):

Company: [Enter your company’s name]

Name: [Enter your name]

Product: [Enter the specific flash product name, e.g. TE28F160B3-T120]

Question: [Enter your question]

For FDI support, check the FAQ section of this manual. Documentation is available fromIntel’s Flash memory WWW (http://www.intel.com/design/flash) page or Bulletin BoardSystem (BBS). For specific software questions, send e-mail to the flash software team [e-mailaddress: [email protected]]. Also the flash software team can be reached at 1-916-356-8922.

11/3/98 10:59 AM APPENC.DOC


EC

System/FlashHardwareRequirements

E

C-1



APPENDIX CSYSTEM/FLASH HARDWARE REQUIREMENTS

This appendix outlines the system and hardware requirements for implementing the Flash DataIntegrator (FDI): a real-time operating system, interrupt polling, flash, and RAM.

C-1 REAL-TIME OSA real-time operating system is required to allow certain FDI tasks to be time sliced with othersystem processes. During a reclaim operation for example, the Background Manager (seeChapter 5, Architecture and API Specification) shares processing time with other system tasks.The real-time operating system must include multi-tasking and the ability to communicatebetween tasks via semaphores or flags. Intel has worked with several OEMs to enhance theirOS to allow optimal performance with FDI.

C-2 INTERRUPTSInterrupt polling is required to handle real-time interrupts that may occur during flash erase andprogramming operations. FDI disables interrupts before initiating a program or erase command.If a higher level interrupt occurs, a TDMA frame interrupt for example, the program or erasecommand is suspended and the required interrupt service routine is then allowed to execute.

C-3 FLASHIn order to implement FDI, the flash device must support a deterministic program and erasesuspend to read. The suspend capability allows the servicing of real-time interrupts (Figure C-1shows an erase suspend example). A spare flash block is also required. This spare block is usedfor reclaim (garbage collection). Lastly, the FDI code is between 20 KB–40 KB in sizedepending on the features enabled.

SYSTEM/FLASH HARDWARE REQUIREMENTS E

C-2



Flash blockis beingerased

TDMAframe

interruptoccurs

Interruptdetectedthroughpolling

algorithms

Flasherase

suspended

TDMAframe

processedby

appropriateISR

Eraseresumed

FDIC-1

Figure C-1. Example of a Program Suspend

Any flash device which satisfies the above conditions may also use FDI to achieve codeexecution plus data storage within a single flash memory device. Many of Intel’s memoryproducts provide deterministic suspend capability: program can be suspended in 10 µsmaximum (5 µs typical) and erase can generally be suspended in 20 µs maximum (10 µstypical).

C-4 RAMRAM is required to assist FDI in managing data storage to flash—2 Kbytes–3 Kbytes total isrequired. One Kbyte is used to store the flash program and erase routines (executed by theBackground Manager from flash); the remaining RAM is used as a data queue and for systemvariables. When implementing high-speed data streaming such as storing voice messages, moreRAM is generally required to ensure messages are not lost. Intel can help an OEM determinetheir optimal data queue size.

The Foreground Manager stores pending data to be written to flash in the RAM queue; whenspawned, the Background Manager writes the data to flash.

11/3/98 10:59 AM APPEND.DOC


ED

License Agreement

E

D-1



APPENDIX DLICENSE AGREEMENT

INTEL OEM

SOFTWARE LICENSE AGREEMENT

BY USING THIS SOFTWARE, YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THISAGREEMENT. DO NOT USE THE SOFTWARE UNTIL YOU HAVE CAREFULLY READ AND AGREEDTO THE FOLLOWING TERMS AND CONDITIONS. IF YOU DO NOT AGREE TO THE TERMS OF THISAGREEMENT, PROMPTLY RETURN THE SOFTWARE PACKAGE AND ANY ACCOMPANYING ITEMS.YOU MUST BE AN ORIGINAL EQUIPMENT MANUFACTURER (“OEM”) SYSTEM DEVELOPER TOACQUIRE ANY RIGHTS IN THE SOFTWARE UNDER THIS LICENSE AGREEMENT.

LICENSE: Intel Corporation (“Intel”) grants you the non-exclusive and royalty-free right to use the enclosedsoftware program (“Software”) in source code form on the terms set forth below. You will not use, copy, modify,rent, sell or transfer the Software or any portion thereof, except as provided in this Agreement.

OEM System Developers may:

1. Copy the Software for support, backup or archival purposes;

2. Install or distribute the Software in object code form only;

3. Modify and/or use Software source code that Intel directly ships to you as an OEM;

4. Allow authorized contractors (“Subcontractors”) engaged by You for the sole purpose of productdevelopment work to have access to the Software solely for that purpose. Subcontractors do NOT acquireany of the OEM rights to the Software provided in this Agreement;

5. Install, use, modify, distribute, and/or make or have made derivative works based on the Software(“Derivatives”) subject to the terms and conditions in this Agreement.

RESTRICTIONS:

YOU WILL NOT:

1. Copy, disclose or distribute the Software, in whole or in part, except as provided for in this Agreement;

2. Remove or modify the “Compatibility” module, if any, in the Software or in any Derivative work,

3. Decompile or reverse engineer any Software delivered in object code form.

TRANSFER: Except as provided above, you may not transfer or disclose the Software to another party .

OWNERSHIP AND COPYRIGHT OF SOFTWARE: Title to the Software and all copies thereof remain withIntel. The Software is copyrighted and is protected by United States and international copyright laws. You willnot remove the copyright notice from the Software. You agree to prevent any unauthorized copying of theSoftware.

LICENSE AGREEMENT E

D-2



DERIVATIVE WORK: You will not be required to provide Intel with a copy of the source or object code for anyDerivatives created by You. You are authorized to use, market, sell, and/or distribute Derivatives, other thanany source code for the Software, at your own risk and expense. Title to Derivatives, other than the portion ofthe Derivative consisting of any of the Software, shall remain with you.

CONFIDENTIALITY: You will maintain the confidentiality of the source code for the Software with at least thesame degree of care that you use to protect your own confidential and proprietary information, but with no lessthan a reasonable degree under the circumstances. Disclosure will only be made to Your employees on aneed-to-know basis. Subject to the licenses granted hereunder, You agree to maintain the Software sourcecode and all other proprietary information relating to the Software in confidence and shall not disclose to othersany such source code or other Intel proprietary information relating to the Software. Any Subcontractors towhom you disclose the source code for the Software must sign a written confidentiality agreement whichcontains terms regarding the Software no less restrictive than those set forth in this Agreement.

DUAL MEDIA SOFTWARE: If the Software package contains multiple media, you may only use the mediumappropriate for your system.

WARRANTY: The Software is provided “AS IS.” Intel warrants that the media on which the Software isfurnished will be free from defects in material and workmanship for a period of one (1) year from the date ofpurchase. Upon return of such defective media, Intel's entire liability and your exclusive remedy shall be thereplacement of the Software.

THE ABOVE WARRANTIES ARE THE ONLY WARRANTIES OF ANY KIND GIVEN BY INTEL UNDER THISAGREEMENT. INTEL SPECIFICALLY DISCLAIMS ANY OTHER WARRANTIES, EXPRESS OR IMPLIED,INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT OR FITNESS FOR ANYPARTICULAR PURPOSE.

LIMITATION OF LIABILITY: NEITHER INTEL NOR ITS VENDORS OR AGENTS SHALL BE LIABLE FORANY LOSS OF PROFITS, LOSS OF USE, LOSS OF DATA, INTERRUPTION OF BUSINESS, NOR FORINDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND WHETHER UNDERTHIS AGREEMENT OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

TERMINATION OF THIS LICENSE: Intel reserves the right to conduct or have conducted audits to verify yourcompliance with this Agreement. Intel may terminate this Agreement at any time if you are in breach of any ofits terms and conditions. Upon termination, you will immediately destroy, and certify in writing the destructionof, the Software or return all copies of the Software and documentation to Intel.

U.S. GOVERNMENT RESTRICTED RIGHTS: The Software and documentation were developed at privateexpense and are provided with “RESTRICTED RIGHTS.” Use, duplication or disclosure by the Government issubject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.

EXPORT LAWS: You agree that the distribution and export/re-export of the Software is in compliance with thelaws, regulations, orders or other restrictions of the U.S. Export Administration Regulations.

APPLICABLE LAW: This Agreement is governed by the laws of the State of Delaware and the United States,including patent and copyright laws. Any claim arising out of this Agreement will be brought in Santa ClaraCounty, California.

11/3/98 11:00 AM APPENE.DOC


EE

Application ExampleCode

E

E-1



APPENDIX EAPPLICATION EXAMPLE CODE

E.1 CREATING A PARAMETER/**********************************************************************************************

* *

* EXAMPLE 1: Creating an E² parameter. *

* *

* This example illustrates how to initially create an "EEPROM" data parameter *

* with FDI. EEPROM data is data that is generally only a few bytes, and does not *

* change in size. It may be either static data, or data that is updated on a *

* frequent basis. *

* *

* FDI handles EEPROM data in a number of different ways, depending on the *

* total size of the data. Ideally, the total size of the EEPROM data will be slightly *

* less than 1/3 of the size specified in the UNIT_GRANULARITY compile option. *

* For a granularity of 128 bytes, this works out to be approximately 40 bytes. *

* EEPROM data which fits into this size category will be stored in a "multi- *

* instance" fashion in flash, which results in more efficient use of flash memory *

* for frequently updated data. *

* *

* Larger data will generally be stored as "single-instance" data unless it is very *

* large (greater than the value of the MAX_NUM_UNITS_PER_FRAG compile *

* option, times the unit granularity). Very large parameters such as these are *

* known as "fragmented" data. Each parameter size class uses flash in the most *

* efficient way, for the size of data it is associated with *

*. *

APPLICATION EXAMPLE CODE E

E-2



* Creating new data parameters is extremely simple. All that is required is a single*

* call to FDI_Write(), using a sub-command of WRITE_APPEND. FDI will interpret*

* this as a request to create a new parameter, if the one specified does not exist. *

* FDI will automatically determine whether the parameter should be created as *

* multi-instance, single-instance, or fragmented data. *

* *

***********************************************************************************************/

void FDI_Example1(void)

{

BYTE data[8] = { 255, 255, 255, 64, 96, 128, 192, 255 };

ERR_CODE results; /* Stores return value from FDI */

COMMAND_CONTROL ccs; /* Command Control Structure to call FDI */

/* The "buffer_ptr" member of the Command Control Structure must be */

/* filled in with the address in memory where the parameter data */

/* resides. For this example, it is the address of the local */

/* array "data", which has been filled with arbitrary values. */

ccs.buffer_ptr = data;

/* Next, the total number of bytes to write must be placed in the */

/* "count" member of the Command Control Structure. The size of */

/* the local data array in this example is 8 bytes. */

ccs.count = 8;

/* The offset at which to write the data must be zero, since this is */

/* a new parameter. The sub command must be set to WRITE_APPEND, to */

/* tell FDI to create the parameter if it does not already exist. */

ccs.offset = 0;

ccs.sub_command = WRITE_APPEND;

E APPLICATION EXAMPLE CODE

E-3



/* Next, a unique type/identifier pair must be chosen for the new */

/* parameter. For EEPROM data, a type of DATA_PARAMETER is always */

/* used. The identifier can be any integer between 0 and 99. An */

/* identifier of 20 has been arbitrarily chosen for this example. */

/* The default range of 0-99 can be changed via FDI compile option. */

ccs.type = DATA_PARAMETER;

ccs.identifier = 20;

/* The last thing to do is to assign a priority to the parameter. */

/* This allows FDI to determine which items to flush from the */

/* queue first. Generally, parameters with a higher frequency of */

/* updates will be given higher priorities. The same priority */

/* level must be used on a given parameter, for the entire life */

/* of that parameter in flash. A value of 5 has been arbitrarily */

/* chosen for this example. */

ccs.priority = 5;

/* The two remaining members of the Command Control Structure, */

/* "aux" and "actual", are not used as inputs for FDI_Write(). */

/* This example sets these values to zero, however, this is */

/* not required in normal practice since these values are */

/* ignored. Note that these "unused" values can not be used */

/* as "scratch space", as their contents are not guaranteed */

/* to be preserved upon return from FDI_Write(). */

ccs.aux = 0;

ccs.actual = 0;

/* At this point, FDI_Write() can be called, giving it the address */

/* of the Command Control Structure that was just filled in. When */

/* FDI_Write() returns, the parameter data will have been copied */

/* to the FDI queue, and flagged for committal to flash by FDI’s */


E-4



/* background task. The data buffer pointed to by the "data" input */

/* variable can then be reused by the application for other things. */

results = FDI_Write(&ccs);

/* The "results" variable now contains the return code */

/* from FDI_Write(). Normally, this will be ERR_NONE, */

/* unless the FDI queue was too full to accept the new */

/* data, or a serious internal error occurred. */

if (results != ERR_NONE)

{

/* It is left as an exercise to the user to */

/* perform additional error-handling as is */

/* appropriate to the specific situation. */

}

}

E.2 UPDATING A PARAMETER/**********************************************************************************************

* *

* EXAMPLE 2: Updating an E² parameter. *

* *

* This example illustrates how to update an existing "EEPROM" data parameter *

* with FDI. EEPROM data is data that is generally replaced with newer data, either*

* in part or in whole. It is uncommon to "add on" to an EEPROM parameter, *

* by appending new data to it. *

* *

* While appending to a parameter is uncommon, it can be done, and is fully *

* supported by FDI. However, doing so will cause any parameters to be *

* automatically converted from multi-instance to single-instance, even if they would*

* still be small enough to qualify as multi-instance data. If an append causes *


E-5



* a data object to grow beyond the capacity of a single-instance object, it will be *

* converted to fragmented data. *

* *

* Note that an update cannot extend beyond the existing size of the parameter, *

* and that appends can only be performed at the end of the parameter. This *

* requires careful setting of the "offset" and "count" members of the Command *

* Control Structure when performing complex updates.*

* *

***********************************************************************************************/


{

BYTE data[8] = { 0, 0, 32, 64, 96, 255, 192, 255 };



/* The "buffer_ptr" member of the Command Control Structure must be */

/* filled in with the address in memory where the replacement data */

/* resides. For this example, it is the address of the local */

/* array "data", which has been filled with arbitrary values. */


/* Next, the total number of bytes to update must be placed in the */

/* "count" member of the Command Control Structure. The offset at */

/* which to write these bytes must also be copied to the CCS. For */

/* this example, it is assumed that the existing parameter is at */

/* least 8 bytes long. The update will be performed starting at */

/* offset zero, and spanning the first eight bytes of the parameter. */

ccs.count = 8;

ccs.offset = 0;

/* Since the assumption has been made that the data being updated */


E-6



/* is within the bounds of existing data for the target parameter, */

/* the sub command must be set to WRITE_REPLACE. This is the */

/* usual sub command that will be used when updating EEPROM data. */

/* More complex updates may require a replace, followed by an */

/* append, if the data is to be updated and expanded. */

ccs.sub_command = WRITE_REPLACE;

/* Next, a unique type/identifier pair must be provided as the target */

/* of the update. For EEPROM data, a type of DATA_PARAMETER is always */

/* used. The identifier must be that of an existing parameter. An */

/* identifier of 20 has been arbitrarily chosen for this example, and */

/* is assumed to already exist on the flash (or in the queue). */



/* The last thing to do is to assign a priority to the parameter. */

/* This allows FDI to determine which items to flush from the */

/* queue first. Generally, parameters with a higher frequency of */

/* updates will be given higher priorities. The same priority */

/* level must be used on a given parameter, for the entire life */

/* of that parameter in flash. A value of 5 has been arbitrarily */

/* chosen for this example, assuming that the parameter was */

/* originally created with this same priority. */

ccs.priority = 5;

/* The two remaining members of the Command Control Structure, */

/* "aux" and "actual", are not used as inputs for FDI_Write(). */

/* This example sets these values to zero, however, this is */

/* not required in normal practice since these values are */

/* ignored. Note that these "unused" values can not be used */


E-7



/* as "scratch space", as their contents are not guaranteed */

/* to be preserved upon return from FDI_Write(). */

ccs.aux = 0;

ccs.actual = 0;



/* FDI_Write() returns, the parameter data will have been copied */

/* to the FDI queue, and flagged for committal to flash by FDI’s */

/* background task. The data buffer pointed to by the "data" input */

/* variable can then be reused by the application for other things. */







{




}

}


E-8



E.3 STORING LARGE DATA WITH FDI_OPEN AND FDI_CLOSE/**********************************************************************************************

* *

* EXAMPLE 3: Large Data. *

* *

* This example illustrates how to work with "large data", or data that is stored by *

* FDI as "fragmented" data. Fragmented data is most efficient for large files, as *

* it prevents having to update an entire file when a change is made to onelocalized*

* portion of the file. Multiple granularities are grouped into fragments, each of *

* which is handled semi-independently by FDI. *

* *

* In order to speed up the process of looking up which fragment is being worked *

* with, FDI supports an "open/close" mechanism for these large files. Note that *

* while FDI_Open() and FDI_Close() can be used on any FDI data object *

* (including small, multi-instance parameters) an increase in performance is only *

* enjoyed when used with fragmented data. *

* *

* FDI currently only supports one open file at a given time, which means that open/*

* close operations should be reserved for time-critical objects, such as voice data *

* streams being saved to flash. Lower priority data can make use of fragmented *

* data without the aid of FDI_Open() and FDI_Close(), at the expense of somewhat*

* slower throughput. *

* *

* The typical usage model for real-time data streaming of this kind is to open/ *

* create a target file, then "trickle" data into it through a series of small writes *

* from an intermediate data buffer. These are typically "write-once" operations, *

* although the performance for modifying data within an existing stream can be *

* improved slightly by using the same open/close mechanisms. *

***********************************************************************************************/



E-9



{

int i; /* Generic loop counter */

BYTE status; /* Used to get FDI status */

BYTE data[128]; /* Intermediate data buffer for writes */



/* The first step is to open the target file. The sub command */

/* member of the Command Control Structure for the open command */

/* must indicate whether the target file is being opened for read, */

/* modify, or being created for the first time. For this example, */

/* it is assumed that the files is being created. */

ccs.sub_command = OPEN_CREATE;

/* Next, a type and ID must be chosen for the stream file. While */

/* any type can be used, streams are typically stored in a separate */

/* type from parameters. The current defaults for FDI are for */

/* parameters to be type 0 (DATA_PARAMETER define), and for streams */

/* to be types 1-6. When using a stream type, the valid range for */

/* identifiers is 101-110, rather than 0-99. When creating a new */

/* stream, the user can either specify a specific identifier, or */

/* can ask FDI to assign the next available identifier to the stream. */

/* In this example, the identifier will be explicitly assigned. Note */

/* that the ranges of valid type/identifiers combinations can be */

/* changed by modifying FDI compile options. */

ccs.type = 1;



E-10



/* Finally, a priority must be chosen for the stream file. A */

/* priority of 2 has been chosen arbitrarily for this example. */

ccs.priority = 2;

/* The remaining members of the Command Control Structure are */

/* not used as inputs for FDI_Open(). This example sets these */

/* values to zero, however, this is not required in normal */

/* practice since these values are ignored. Note that these */

/* "unused" values can not be used as "scratch space", as */

/* their contents are not guaranteed to be preserved upon */

/* return from FDI_Open(). */

ccs.buffer_ptr = 0;

ccs.count = 0;

ccs.offset = 0;

ccs.aux = 0;

ccs.actual = 0;

/* At this point, FDI_Open() can be called, giving it */

/* the address of the Command Control Structure that */

/* was just filled in. This will create the file, */

/* and set up the open stream information in RAM. */

results = FDI_Open(&ccs);


/* from FDI_Open(). Normally, this will be ERR_NONE, */

/* unless there is already an open file, or if the */

/* inputs in the CCS were invalid in some way. */


{


E-11






}

/* The next step, now that the file has been created, is to actually */

/* write the stream data. Normally, this will be done a little bit */

/* at a time, as new data "trickles in" and becomes available. The */

/* best strategy is to gather up a reasonable amount of streamed data */

/* in an intermediate buffer (e.g. 128 byes), and then call */

/* to write the consolidated data. Once FDI_Write() returns, the */

/* data will have been copied into FDI’s queue, and the intermediate */

/* buffer can be used once again for collecting the next 128 bytes. */

/* */

/* To further increase performance, the application can call */

/* FDI_Write() with a sub command of WRITE_RESERVED, and reserve a */

/* larger amount of flash, such as an entire fragment (which defaults */

/* to 512 bytes). The fragment is then filled in using WRITE_MODIFY, */

/* which simply lays down the data in the pre-reserved space. By */

/* doing this, an application can minimize the amount of changes made */

/* made to FDI’s internal sequence tables, by doing it once with the */

/* modify, rather than every time an append is performed. */

/* */

/* This sequence of procedures for performing a streamed write is */

/* provided solely as an illustration of the basic algorithm, and can */

/* be scaled and modified to suit the needs of the application. */

/* To do the reserve, FDI_Write() is called with a sub */

/* command of WRITE_RESERVED. Since this is a newly */

/* created file, the offset will be zero. As indicated */

/* previously, a reserve of 512 bytes will be performed. */


E-12



ccs.sub_command = WRITE_RESERVED;

ccs.offset = 0;

ccs.count = 512;

/* The type, identifier, and priority must all match the */

/* values given when the file was first created. */

ccs.type = 1;


ccs.priority = 2;

/* All unused members are set to zero */

ccs.buffer_ptr = 0;

ccs.aux = 0;

ccs.actual = 0;

/* Calling write will reserve the space in flash, and ensure that */

/* no further overhead will be generated due to manipulation of */

/* the sequence tables, for the next 512 bytes. */







{




}


E-13



/* At this point, the next 512 bytes of data can be streamed */

/* into the file. For this example, only 512 bytes will be */

/* written, as it is enough to illustrate the basic steps of */

/* performing a streamed write. */

for (i = 0; i < 4; i++)

{

/* Typically, there would be a small delay at this point */

/* while the system waits for the intermediate 128 byte */

/* buffer to be filled with incoming stream data. */

/* Once the data is available, it can be written. The first step */

/* is to set up a Command Control Structure for FDI_Write(), */

/* specifying a sub command of WRITE_MODIFY, and supplying the */

/* offset and number of bytes to be written. */

ccs.sub_command = WRITE_MODIFY;

ccs.offset = (i * 128);

ccs.count = 128;

/* For the purposes of this example, it is assumed that */

/* the local intermediate buffer "data" is filled in by */

/* the system as new stream data trickles in. The */

/* address of this buffer must be passed to FDI_Write(). */


/* As before, the type, identifier, and priority must all */

/* match the values given when the file was first created. */

ccs.type = 1;


ccs.priority = 2;


E-14




ccs.aux = 0;

ccs.actual = 0;



/* FDI_Write() returns, the stream data will have been copied from */

/* the intermediate buffer into the FDI queue, and flagged for */

/* committal to flash by FDI’s background task. The intermediate */

/* buffer can then be reused by the application for new data. */







{




}

}

/* Now that the whole 512 bytes has been written, the file can */

/* be closed. Before doing so, however, the system should wait */

/* for the modifies in the FDI queue to be processed. Closing */

/* the file with this information still in the queue will */

/* destroy the open stream info structures in RAM, forcing each */

/* remaining write to perform a full lookup through the FDI */


E-15



/* sequence tables, thereby negating the performance gains of */

/* using FDI_Open() and FDI_Close(). */

do

{

/* Note that some kind of task delay should be placed */

/* here, to allow the FDI background task to run and */

/* work on flushing the queue. Since a scheduling */

/* function of this type is highly system specific, */

/* it is omitted from this example. */

/* FDI_Status() can be called to determine if any items */

/* are waiting in the queue to be flushed to flash. */

FDI_Status(&status);

}

while (status & 0x02);

/* Now that is has been confirmed that all data has been flushed */

/* from the queue, the file can be closed. FDI_Close() is a */

/* simple function, requiring only the type, identifier, and */

/* priority of the stream file that is to be closed. */

ccs.type = 1;


ccs.priority = 2;


ccs.buffer_ptr = 0;

ccs.sub_command = 0;

ccs.count = 0;

ccs.offset = 0;

ccs.aux = 0;

ccs.actual = 0;


E-16



/* Now the close function can be called to finish the process */

results = FDI_Close(&ccs);


/* from FDI_Close(). Normally, this will be ERR_NONE, */

/* unless the inputs in the CCS were invalid in some way. */


{




}

}

E.4 READING LARGE DATA WITH FDI_OPEN AND FDI_CLOSE/**********************************************************************************************

* *

* EXAMPLE 4: Reading data. *

* *

* This example illustrates how to read data from a data object stored by FDI in *

* flash. Reading data is a fairly straightforward process, and is the same for all *

* data types (i.e. multi-instance, single-instance, and fragmented). *

* *

* Note that FDI_Open() and FDI_Close() can be used on fragmented data to *

* improve read speed, if very high throughput is required. The steps taken to do *

* this are nearly identical to those in example 3, and are left as an exercise *

* to the user. Using FDI_Open() and FDI_Close() on multi-instance or single- *

* instance data will have no effect on read throughput. *


E-17



* *

* The example below reads the first eight bytes from a simple parameter data *

* type, similar to the ones created in examples 1 and 2. *

* *

***********************************************************************************************/


{

BYTE buffer[8]; /* Stores data that is read from parameter */



/* The "buffer_ptr" member of the Command Control Structure */

/* must be filled in with the address in memory where the */

/* data will be copied to once it is read. For this example, */

/* it is the address of the local array "buffer". */

ccs.buffer_ptr = buffer;

/* Next, the total number of bytes to read must be placed */

/* in the "count" member of the Command Control Structure. */

/* The offset at which to read these bytes from must also */

/* be copied to the CCS. For this example, the */

/* first eight bytes will be read from the parameter. */

ccs.count = 8;

ccs.offset = 0;

/* Next, a unique type/identifier pair must be provided as the target */

/* of the read. For EEPROM data, a type of DATA_PARAMETER is always */

/* used. The identifier must be that of an existing parameter. An */

/* identifier of 20 has been arbitrarily chosen for this example, and */


E-18



/* is assumed to already exist on the flash (or in the queue). */



/* The priority that the parameter was originally written at */

/* must be supplied, in case some portion of the parameter */

/* is still in the queue. A value of 5 has been arbitrarily */

/* chosen for this example, assuming that the parameter was */

/* originally created with this same priority. */

ccs.priority = 5;

/* The remaining members of the Command Control Structure */

/* are not used as inputs for FDI_Read(). This example */

/* sets these values to zero, however, this is not required */

/* in normal practice since these values are ignored. Note */

/* that these "unused" values can not be used as "scratch */

/* space", since their contents are not guaranteed to be */

/* preserved upon return from FDI_Read(). */

ccs.sub_command = 0;

ccs.aux = 0;

ccs.actual = 0;

/* At this point, FDI_Read() can be called, giving it the address */

/* of the Command Control Structure that was just filled in. */

results = FDI_Read(&ccs);


/* from FDI_Read(). Normally, this will be ERR_NONE, */

/* unless the specified parameter did not exist, or a */

/* serious internal error occurred. Also, the "actual" */


E-19



/* member of the Command Control Structure will have been */

/* set by FDI_Read() to the actual number of bytes read. */

/* This value can differ from the amount requested if the */

/* end of the parameter was encountered before all bytes */

/* could be read. */

if ((results != ERR_NONE) || (ccs.actual != 8))

{




}

}


E-20



E.5 USING FDI_GET TO RETRIEVE DATA/**********************************************************************************************

* *

* EXAMPLE 5: FDI_Get(). *

* *

* This example illustrates how to use FDI_Get() to browse through files stored in *

* flash. The user begins the search by instructing FDI to find either the first *

* file within a given type (sorted by identifier), or to find a specific file. *

* From there, FDI can be instructed to successively find the next file in order, *

* until no more valid files exist for that type. *

* *

* Typically, this will not be used for EEPROM data types, since those parameters *

* are usually created and maintained explicitly by the application software. *

* Dynamic files (e.g. voice recordings, faxes, etc) may be harder to track *

* without setting up special tracking parameters disguised as EEPROM data *

*. FDI_Get() allows an application to create and delete these dynamic files at *

* will, and simply browse through them at a later time to get a "directory" *

* of what is still on the flash. *

* *

* The function below performs a simple search for all files within a particular *

* "stream data" type. Once the file has been found, and identified as valid *

* by FDI_Get() the application has the option of reading the contents of that file, *

* or continuing on to find the next one. *

* *

***********************************************************************************************/


E-21




{

BYTE next_flag = 0; /* Used to keep track of first/next */

WORD last_id; /* Used to save last identifier found */



do

{

/* The first thing to do is find the first file. This is done */

/* by sending a value of GET_FIRST to FDI_Get() in the Command */

/* Control Structure. Subsequent gets will use GET_NEXT. */

/* Tracking of whether or not this is the first get, or a */

/* subsequent get is done through the "next_flag" variable. */

if (next_flag == 0)

{

/* This is the first time, so GET_FIRST will be used */

ccs.sub_command = GET_FIRST;

/* The only other information FDI_Get() needs to do a "find */

/* first" is which type it should start the search in. For */

/* this example, type 1 was chosen arbitrarily. */

ccs.type = 1;

/* The identifier member is not used when performing a */

/* GET_FIRST, and can be set to zero. See the comment */

/* below regarding the setting of unused values to zero. */

ccs.identifier = 0;

/* The "next_flag" is now incremented, so that the GET_FIRST */


E-22



/* case is only executed the first time through. */

next_flag++;

}

else

{

/* All subsequent gets will use GET_NEXT */

ccs.sub_command = GET_NEXT;

/* The only other information FDI_Get() needs to do a "find */

/* next" is which type it should start the search in, and */

/* which identifier it last found. For this example, type 1 */

/* was chosen arbitrarily. The local variable "last_id" */

/* will contain the last identifier found, from the previous */

/* pass through the do...while loop. */

ccs.type = 1;

ccs.identifier = last_id;

}

/* Priority is used when doing a FIND_MATCHED, however since */

/* this type of find will not be performed in this function, */

/* the priority member can be set to zero. See the comment */

/* below regarding the setting of unused values to zero. */

ccs.priority = 0;

/* The remaining members of the Command Control Structure are not */

/* used as inputs for FDI_Get() when performing any type of find. */

/* This example sets these values to zero, however, this is not */

/* required in normal practice since these values are ignored. */

/* Note that these "unused" values can not be used as "scratch */


E-23



/* space", since their contents are not guaranteed to be preserved */

/* upon return from FDI_Get(). */

ccs.buffer_ptr = 0;

ccs.count = 0;

ccs.offset = 0;

ccs.aux = 0;

ccs.actual = 0;

/* At this point, FDI_Get() can be called, giving it the address */

/* of the Command Control Structure that was just filled in. */

results = FDI_Get(&ccs);


/* from FDI_Get(). Normally, this will be ERR_NONE, */

/* unless the specified parameter did not exist, or */

/* there are no more parameters of the given type. */


{

/* This error means there are no more files of this type */

if (results == ERR_NOTEXISTS)

break;




}

/* Since a file was found, save the identifier (which is an */

/* output value of FDI_Get() in the CCS) for the next time */

/* through the do...while loop. */

last_id = ccs.identifier;


E-24



/* At this point, the application could read the contents of */

/* the file that was found (using the technique shown in */

/* example 4). What the application chooses to do with the */

/* data read from the file will depend on the situation. If */

/* the application continues to let the do...while loop run, */

/* these steps will be performed for every file encountered. */

}

while (results == ERR_NONE);

}

Flash Data Integrator (FDI) User’s Guide - Welcome …cpop/Documentatie_SMP/Intel...Copies of...

Documents

Transcript of Flash Data Integrator (FDI) User’s Guide - Welcome …cpop/Documentatie_SMP/Intel...Copies of...