Architecture for a universal serial bus-based pc flash disk

ES 2 344 359 T3

DESCRIPTION

Lightning disk architecture for personal computer based on universal serial communication channel.

Field and background of the invention

The present invention relates to semiconductor memory devices and, in particular, to non-volatile, erasable and programmable memory modules, which are connected to a host platform using the USB communication channel of the PC (personal computer).

Erasable and programmable non-volatile memory modules, hereinafter referred to as flash memories or flash devices, are known in the information storage art. Flash devices include electrically erasable and programmable read-only memories (EEPROMs) made of lightning-type floating command electrode transistors and are non-volatile memories with similar functionality and behavior to EPROM memories, with the added functionality of allowing a In-loop operation, programmable, to erase pages from memory. An example of a practical implementation of a lightning device of this kind is offered in US patent no. 5,799,168.

This document describes a flash memory controller that reports the number of flash chips present. Using the Read ID mode inherent in lightning chips (in which a read from any address returns one of several fixed codes that identify the type and manufacturer of the chip), the standard controller dynamically identifies the cluster it is managing issuing orders to read IDs to ascending addresses in order to identify the presence of chips in that place and, in this way, Automatically detect chip number and collation.

Flash drives have the advantage of being relatively inexpensive and requiring relatively little power compared to traditional magnetic storage disks. However, in a flash device it is not practical to re-record over a previously recorded area of ​​memory without erasing a preceding page from the area. This limitation of flash drives makes them incompatible with existing typical operating system programs, as data cannot be written to an area of ​​flash drive memory in which data has been previously recorded, unless it is first recorded. clear the content of the area.

US 5404485 describes a flash memory controller that provides a fully rewritable virtual address space, whereby the flash memory emulates random access memory in which the controller updates an address translation table.

These flash memory devices currently have a second limitation, which is that they must be statically connected to the host platform, or dynamically connected and disconnected using the PCMCIA (Personal Computer Memory Card International Association) interconnect. Both practical executions have drawbacks that include difficulty of use and high cost.

A more useful practical implementation would follow the USB standard, as described in version 1.1 of the USB specification.

The "Revision of the specification of class of mass storage by means of universal serial communication channel V 1.0", of October 22, 1998, suggests to use the USB for mass storage devices and to wrap the existing storage protocols for the mass storage devices with a USB package. One of the protocols considered in this document is "Reduced Block Commands (RBC)" which is typically used for lightning devices.

The USB standard offers the end user a smaller form factor and greater ease of use, while reducing the cost of implementation. This standard has been specified to be an industry standard promoted by companies such as Compaq Computer Corporation, Microsoft, IBM, and Intel, to serve as an extension of the personal computer architecture for Computer Telephony Integration (CTI ), consumer and productivity applications.

The criteria that were applied to define the architecture for the USB standard include the ease of expansion of peripherals in a PC (personal computer), the low cost, the support of transmission speeds of up to 12 Mb / second and the complete support for data. , voice, audio and compressed video, in real time. This standard also offers protocol flexibility for isochronous mixed-mode data transmissions and asynchronous messaging, integration into convenience device technology, and the provision of a standard interconnect for rapid integration into any given host product. Furthermore, the USB standard represents a unique model for patch and cabling connectors, such that all details of electrical functions, including terminations of communication channels, are isolated from the end user. Thanks to this standard, peripheral devices are automatically identified and support automatic function matching for a controller. In addition, the standard makes it possible for all peripheral devices to be dynamically connected and reconfigured.

ES 2 344 359 T3

A system built to the USB standard is described by three separate, defined areas: USB interconnect, USB devices, and USB host platform. USB interconnect is the way that USB devices connect to and communicate with the host platform. The components and associated functions include the communication channel topology, which is the connection model between USB devices and the host platform.

The physical USB interconnect has a multi-tier star topology. A hub is the center of each star. Each conductor segment is a point-to-point connection between the host platform and a hub or feature, or a hub connected to another hub or feature.

In terms of the skills stack, the USB tasks that run at each layer of the system include a data flow model and a planning program. A data flow model is the way data moves through the system over the USB between data producers and data consumers. A planning schedule determines access to the interconnect, which is shared. Such a scheduling program makes it possible to support isochronous data transmissions and eliminates arbitration overhead.

USB is itself a scrutinized communications channel. The host controller on the host platform initiates all data transmissions. All transactions over the communications channel involve the transmission of up to three packets. Each transaction is initiated when the host controller, on a scheduled basis, sends a USB packet that describes the type and address of the transaction, the address of the USB device, and the endpoint number. This packet is called a “token packet”. The USB device to which the packet is addressed selects itself by decoding the appropriate address fields. In a given transaction, data is transmitted from the host platform to a device or from a device to the host platform. The data transmission address is specified in the token packet. The source of the transaction then sends a data packet or indicates that the source lacks data to transmit. The destination generally responds with an acknowledgment packet indicating whether the transmission was successful.

The pattern of USB data transmission between a source and a destination on the host platform and an end point on a device is called a “path”. There are two types of pathways: flow and message. Stream data does not have a defined USB structure, while message data does. In addition, the paths have associations for data bandwidth, transmission service type, and endpoint characteristics, such as directionality and buffer sizes. Most paths begin their existence when a USB device is configured. A message path, the default control path, always exists after a device has been activated, in order to provide access to configuration, status, and control information for the device.

Transaction planning for the USB standard allows flow control for some flow paths. At the hardware level, this prevents situations where the buffers experience insufficient or excess data, by using an acknowledgment signal Nak to regulate the data rate. With NAK handshake, a transaction is attempted again when communication channel time is available. The flow control mechanism allows the construction of flexible schedules that accommodate the provision of concurrent services from a heterogeneous mix of flow paths. Thus, multiple flow paths can be served at different intervals, with packets of different sizes.

The USB standard, as described, has three main types of packets, including token packets, data packets, and acknowledgment packets. An example of each type of package is shown in Figures 13 belonging to the prior art. Figure 4, which is also in the prior art, shows an illustrative USB abstract device.

A token packet 10, as shown in prior art figure 1, has a PID (packet identification) field 12, which specifies one of three packet types: IN, OUT, or SETUP ( ESTABLISH). If PID field 12 specifies the IN packet type, the data transaction is defined from a function to the host platform. If PID field 12 specifies the OUT or SETUP packet type, the data transaction is defined from the host platform to a function.

An ADDR field 14 specifies the address, while an ENDP field 16 specifies the end point for token packet 10. For OUT and SETUP transactions, where PID field 12 specifies that token packet 10 is a packet of type OUT or a SETUP type packet, field 14 ADDR and field 16 ENDP uniquely identify the end point to receive the subsequent data packet, illustrated in FIG. 2, which follows token packet 10. For IN transactions, where PID field 12 specifies that token packet 10 is an IN type packet, ADDR field 14 and ENDP field 16 uniquely identify which endpoint transmits a data packet. A CRC5 field 18 contains the checksum, to determine that the token packet 10 has been received without corruption. Only the host platform can issue token packets 10, such that token packets 10 provide control over the transmission of subsequent data packets.

As shown in prior art Figure 2, a prior art USB data packet 20 also has a PID (packet identification) field 22 to identify the type of data packet. The data packet 20 also has a data field 24 to optionally contain data, and a CRC field 26 to contain the checksum, as previously described.

ES 2 344 359 T3

Prior art FIG. 3 shows a prior art USB handshake packet 28, having only one PID (packet identification) field 30. Acknowledgment packets 28 are used to report the status of a data transaction and can return values ​​indicating successful receipt of data, acceptance or rejection of orders, flow control, and stop conditions. Only transaction types that support flow control can return acknowledgment packets 28. Acknowledge packets 28 are always returned in the acknowledgment phase of a transaction and can be returned, instead of data packets 20, in the acknowledgment phase. data of a transaction.

These three different types of packages are exchanged during various phases of the transaction that includes a USB device. A schematic block diagram of the functional blocks in a typical USB device 32 is shown in Figure 4 for an abstract USB device according to the prior art. The USB device 32 typically includes a USB electrical interconnect 34, having a cable and a connector, which constitutes a physical interconnect for receiving and transmitting electrical signals that are compatible with the USB specification as previously described. The signals are then passed to a logic interface 36, which includes one or more buffers, the device address decoder to decode the source device address for the signals, and a field synchronizer SYNC to synchronize the signals. The information and structures required for managing the abstract USB device 32 as a USB device are stored in a USB class control and enumeration engine 38. A feature and device engine 40, also referred to as "the application," controls and manages the properties and specific features of the abstract USB device 32. In addition, the feature and device engine 40 also consumes and generates most of the data over the USB communication channel.

However, the USB specification does not define the relationship between different entities in the abstract USB device 32. Instead, the USB specification only describes the requirements for the packets, and for the electrical and physical connection between the abstract USB device 32 and the communication channel. Therefore, the connections and relationships illustrated in FIG. 4 belonging to the prior art are only an example of a practical implementation that satisfies the requirements of the USB specification. Thus, any specific device to meet the USB specification must have a specifically defined and described architecture.

Unfortunately, there is no such architecture for a flash memory device containing one or more flash memory modules, which makes it possible for the flash memory device to connect to a communication channel defined in accordance with the USB specification and therefore be part of a USB system on a host platform. For example, US Patent No. 5,799,168 does not teach or suggest such a practical implementation for the lightning device. As previously mentioned, such an architecture would be particularly useful for a number of reasons, including low cost, ease of use, and transparency to the end user.

Therefore, there is a need, and it would be useful to have an architecture to define and describe a flash memory device that is compatible with a USB system and follows the USB specification, such that the flash memory device could be incorporated into a communications channel. defined USB and could communicate with the host platform through this communication channel.

Brief description of the drawings

Fig. 1 is a schematic block diagram of a USB token packet structure according to the prior art;

fig. 2 is a schematic block diagram of a USB data packet structure according to the prior art;

fig. 3 is a schematic block diagram of a USB handshake data packet structure according to the prior art;

fig. 4 is a schematic block diagram of an illustrative USB device according to the prior art;

fig. 5 is a schematic block diagram of a system with lightning USB device functionality in accordance with the present invention;

fig. 6 is a schematic block diagram of the USB flash drive;

fig. 7 is a schematic block diagram of a flash identification request packet;

fig. 8 is a schematic block diagram of a flash identification status packet;

fig. 9 is a schematic block diagram of a flash record request packet;

fig. 10 is a schematic block diagram of a flash record status packet;

ES 2 344 359 T3 FIG. 11 is a schematic block diagram of a flash read request packet;

fig. 12 is a schematic block diagram of a flash read status packet;

fig. 13 is a schematic block diagram of a flash erase request packet; and fig. 14 is a schematic block diagram of a flash erase state packet.

Summary of the invention

The present invention relates to a flash memory device, containing one or more flash modules, in which flash memory is mapped to the address space of an ASIC or controller having a defined electrical interface USB and a defined logical interface USB. This controller / ASIC (hereinafter referred to as “controller”) supports USB functionality according to the USB standard, thus supporting enumeration through the USB communication channel, as well as data reception and transmission via USB to and from USB endpoints. . This controller also supports flash memory device control and functionality, as well as handling of command packets and data from the host controller. The host controller uses one of several possible protocols, either standard or proprietary, to signal the next command to be executed to the USB lightning controller. Thus, the entire device acts as a dynamically pluggable / detachable non-volatile storage device for the host platform.

In accordance with the present invention, there is provided a USB flash memory device for connecting a defined USB communication channel as defined in independent claim 1 and a data processing method as in independent claim 19.

In the following, the term "computer" includes, but is not limited to, personal computers (PCs) with an operating system such as DOS, Windows ™, Os / 2 ™ or Linux computers, Macintosh ™; computers that have JAVA^TM-OS as the operating system; and graphics workstations such as Sun Microsystems ™ and Silicon Graphics ™ computers and other computers with some version of the UNIX operating system such as AIX^TM or SOLARIS^TM by Sun Microsystems^TM . or any other known and available operating system, including operating systems such as Windows CE^TM for embedded systems, including cell phones, handheld computing devices and portable computing devices and any other computing device that can be connected to a network. In what follows, the term "Windows^TM"Includes Windows95^TM, Windows 3.x^TM, where x is an integer such as 1, Windows NT^TM, Windows98^TM, Windows CE^TM and any updated versions of these operating systems from, but not limited to, Microsoft Inc. (Seattle, Washington, USA).

Detailed description of the invention

The present invention relates to a flash memory device, containing one or more flash modules, in which flash memory is mapped to the address space of an ASIC or controller having a defined USB electrical interface and a USB interface. USB defined logic. This controller / ASIC (hereinafter referred to as “controller” supports USB functionality according to the USB standard, thus supporting enumeration on the USB communication channel as well as receiving and transmitting data via USB to and from USB endpoints. This controller also supports the functionality and control of the flash memory device, as well as the handling of command packets and data from the host controller. The host controller uses one of several possible protocols, either standard or proprietary, to signal the next command to be executed by the USB flash controller. Thus, the entire device acts as a non-volatile, dynamically pluggable / detachable storage device for the host platform.

While the invention is susceptible to various modifications and can be practiced using many alternative forms, one embodiment will be described in detail in the following pages and one embodiment illustrated by way of example. It should be understood that one of ordinary skill in the art will appreciate that the present invention could be practiced in various other ways. The intention is to cover all modifications and alternatives that fall within the spirit of the present invention.

The principles and operation of a USB flash device and system in accordance with the present invention may be better understood by referring to the drawings and the accompanying description, it being understood that these drawings are offered for illustrative purposes only and are not intended to be limiting.

Referring now to the drawings, Figure 5 is a schematic block diagram of the main components of a flash memory device and system in accordance with the present invention. A flash memory system 42 includes a host platform 44 as shown. The host platform 44 works with a USB flash device 46 as a non-volatile storage space.

Host platform 44 is connected to USB lightning device 46 in accordance with the present invention via USB cable 48. Host platform 44 connects to USB cable 48 through USB host connector 50, while USB lightning device 46 connects with the USB 48 cable via a

ES 2 344 359 T3 connector 52 for USB lightning device. The host platform 44 has a USB host controller 54 to control and manage all USB transmissions over the USB communication channel.

The USB lightning device 46 has a USB lightning device controller 56 to control the other components of the USB lightning device 46 and provide an interface for the USB lightning device 46 with the USB communications channel, the USB lightning device connector 52 and, minus a flash memory module 58. Flash memory module 58 is preferably an array of flash memory modules 58 in which data is stored.

Whenever the USB flash device 46 is connected to the host platform 44, a standard USB enumeration process takes place. In this process, the host platform 44 configures the USB flash device 46 and the communications mode with the USB flash device 46. While there are many different methods for configuring the USB flash device 46, for the sake of clarity only and not intended to be limited, the present invention is explained in greater detail below in relation to a method in which the host platform 44 it issues commands and requests to the USB flash device 46 through an endpoint. Host platform 44 requests status changes from USB flash device 46, through the other endpoint, and receives related packets if any such packet is expected to be received.

The host platform 44 requests services from the USB lightning device 46 by sending request packets to the USB host controller 54. The USB host controller 54 transmits packets over the USB cable 48. These requests are received by the USB lightning device controller 56 when the lightning device USB 46 is the request endpoint device. The USB flash device controller 56 then performs various operations such as reading, writing, or erasing data in relation to the flash memory module (s) 58, or supporting basic USB functionality such as device configuration and enumeration. The USB flash drive controller 56 controls the flash memory module (s) 58 using a control line 60 to control the power of the flash memory module (s) 58 and also through various other signals such as, for example , chip enable signals and read and write. The flash memory module (s) 58 are also connected to the USB flash device controller 56 via an address / data communication channel 62. The address / data communication channel 62 transmits commands to read, write or erase on the flash memory module (s) 58, as well as addresses and data for these commands as defined by the manufacturer of the module (s) 58. of flash memory.

In order for the USB flash device 46 to notify the host platform 44 of the result and status of different operations requested by the host platform 44, the USB flash device 46 transmits status packets using the "endpoint status". According to this procedure, the host platform 44 checks (scrutinizes) the status packets and the USB flash device 46 returns an empty packet, if no packets are present for new status messages, or alternatively returns the status packet itself.

A more detailed structure of the functional components of the USB lightning device 46 is shown in Figure 6. The USB lightning device 46 includes the physical and electrical interconnection defined by the USB standard, shown in this case as the USB lightning device connector 52 and a connector interconnect 62. USB lightning device connector 52 receives electrical signals from USB cable 48, which transmits electrical signals from the host controller (not shown). These signals are then passed through connector interface 64. Every millisecond, a USB frame is transmitted on the defined USB communication channel, such that packets could be sent to the USB flash device 46.

Connector interconnect 44 then receives these packets through a first interconnect component which is a physical and logical interconnect 66 in combination. A functional interconnect 68 is specifically designed to receive token packets as defined in the USB specification and as previously described with respect to Figure 1. These token packages are related only to particular functional aspects of the USB flash device 46 that are necessary for the USB standard and do not bear any relation to the particular application of the USB flash device 46 as a flash unit in accordance with the present invention. These token packets and their respective returned data packets enable USB host controller 54 (not shown) and host platform 44 (not shown) to identify USB flash device 46 and allocate resources for USB flash device 46 on the communication channel. USB communications. Thus, the functional interface 68 only supports the USB functionality necessary for the identification and registration of the USB flash device 46 on the USB communication channel.

The USB flash device 46 also has an application packet extractor 70 that extracts the application data and commands from the USB application packets, such that the application packet extractor 70 only supports application-related packets. Next, any requests made to USB flash device 46 by host platform 44 (not shown), in the form of read, write, identify and delete commands, are interpreted by an application command interpreter 72. For any commands that include data or addresses, such as read, write, and erase commands, an address resolution module 74 translates the address from the logical address space to the physical address space. The host platform 44 (not shown) refers to a linear address space of logical addresses, while the USB flash device 46 contains at least one, and preferably a plurality, of flash modules 58, each of which has a physical address space. Thus, a translation must be performed between the logical address space of

ES 2 344 359 T3 the host platform 44 (not shown) and the physical address space (s) of the USB flash device 46. There are many ways to implement such translation, which are suitable for the present invention. An example of a suitable practical implementation of an address translation method is described in connection with US Pat. 5,404,485, which teaches a method for managing a flash memory as a flash unit and which is suitable for operating with the present invention.

A data manager 76 manages the data-related aspects of any received orders and transports the data through functional interface 68, to and from the flash module (s) 58. Optionally, and preferably, the data manager 76 carries out any error detection and correction methods. The application command interpreter 72, data manager 76, and address resolution module 74 all operate with an underlying memory technology controller (MTD) 78 to write, read, or erase to a particular lightning module 58 and the desired address of that flash module 58.

Host platform 44 checks for status changes from USB flash device 46 and reads status packets from USB flash device 46 when a new status pack is available. Using these status packets, the USB flash device 46 can transmit to the host platform 44 the results of different commands issued by the host platform 44 in its requests (not shown). For example, the read command status packet contains one of the available status words such as "success", "error" or "invalid address", which allows the host platform 44 to determine the result of the read command. (not shown). Similarly, the delete state packet contains a status word that indicates that the delete process has been completed. A record status packet is used by the USB flash device 46 to notify the host platform 44 of the result of the record command, for example if the command was successful or ended in error and if the USB flash device 46 is ready to go. receive additional recording requests from host platform 44.

A memory technology unit or MTD 78 typically contains routines for reading, writing and erasing the flash memory device controlled by the controller that operates the MTD 78. In addition, MTD 78 optionally contains an identification routine to recognize the appropriate type of flash memory device for which MTD 78 was designed, so that the controller can determine which MTD should be activated when interacting with a particular cluster. of flash memory devices. In addition, an identification routine must be capable of detecting the size of the flash memory device pool, including the number of flash memory devices in the pool and various characteristics of the flash pool geometry, such as channel amplitude. communications and collation. This information further enables host platform 44 to determine the address space and size of the storage medium. US Patent No. 5,799,168 describes an example of such a BAT for a lightning device.

Using the architecture and protocol described above, the host platform 44 can optionally run any application that can be run with any I / O-mapped or memory-mapped flash memory device. For example, host platform 44 may provide a standard block device interconnect to each application, such as a "hard disk" drive with magnetic storage media, as described in previously cited US Pat. 5,404,485.

As an example of a preferred embodiment of the present invention, the operation of a host system connected to a USB flash device according to the present invention is described in relation to the flash device identification, programming, reading and erasing processes. For purposes of illustration only, and without wishing to be limited in any way, the illustrative USB Flash device has a grouping of two Flash memory modules, each of which is 64 Mb in size. The address translation table is listed below. contained in the lightning device, so that the host platform works with logical addresses. All return codes and commands between the flash device and the host platform are transmitted in USB data packets and over USB data paths. The exact structure of the packets, paths and timing are described in the USB specification.

The operation of the illustrative system and device in accordance with the present invention is as follows. When the USB flash device is connected to the host platform for the first time, the USB host controller assigns an address to the USB flash device on the USB communication channel and also allocates resources as described in the USB specification. The USB flash device actually asks the host platform to allocate these resources and must inform the host platform how many of these resources are needed. Thus, the USB Flash Drive can optionally support slower device speeds if the USB host platform has already allocated resources to other devices.

The USB controller also negotiates with the flash modules and determines the size and build type of these modules. The controller then builds an identification structure that contains this information, as well as the translation table and the logical address space.

Once the USB host controller identifies the USB flash device, the host platform frequently loads a USB client drive. The unit issues an identification request command to the USB host controller, causing the controller to transmit a packet 80 of identification data, shown in the figure

ES 2 344 359 T3

7. Identification packet 80 contains a PID field 22 and a checksum field 26, as previously described in connection with FIG. 2 of the prior art. Identification packet 80 also contains an "identify" operation code in an operation code field 82. The packet extractor of the USB flash device receives the identification data packet 80 and transmits the operation code of the "identify" command to the application command interpreter.

Then, in response to the "identify" command, the flash device sends an identification data packet 84, illustrated in FIG. 8. In addition to the fields shown in Figure 7, the identification data packet 84 also contains information about the size of the lightning device in a lightning device dimension field 86, as well as information about the size of the minimum erasure unit. to erase flash memory, in an erase unit size field 88.

All the packets described in this example are only data packets that are sent over the USB communication channel. Before each data packet is sent, a USB token packet is transmitted, which instructs the USB controller as to the identity of the device endpoint to which the data packet should be transmitted. Upon successful receipt of the packet, the USB controller issues a USB ACK packet as described in the USB specification.

Once the host platform device drives receive this status packet, the drives can start issuing read and write commands to the USB flash device with the application commands. When a record request is sent, a USB data packet with the operation code for the "record" command is transmitted to the USB flash device, and the buffer containing the data is transferred to the USB flash device. Illustrated in FIG. 9 is a data recording packet 90 that also includes the fields previously shown in FIG. 8, except that the data recording packet 90 also includes a recording field 92 with the functional code "record "; an ADDR field 94 with the logical address where it is to be recorded; a LEN field 96 with the length to be recorded; and a DATA field 98 containing the actual data to be recorded. The packet extractor extracts the functional code from the data recording packet 90 and transmits this code to the application command interpreter. The logical address is transmitted to the address resolution module, which translates this logical address into a physical address on one of the flash modules. The data manager calculates, optionally, error detection and correction mechanisms, if they are used by the USB flash device. Once all the flash memory modules are ready, a "write" command is sent to the flash module (s) containing the physical address that can optionally span more than one flash module for the MTD block. The MTD block then issues a "record" command over the address / data communications channel connecting the flash modules to the USB device controller. After the operation is completed and a status packet is returned to the MTD, the result of the operation is transmitted to the host controller and passed to the device unit of the host platform.

When the flash controller completes the recording process, the controller signals to the host platform that the status of the USB flash memory device has changed, sending a "record status" packet 100, as shown in FIG. 10. In place of the data field 98, the record status packet 100 contains a status field 102. The host platform reads the status packets from the flash memory device and, from the write status packet 100, the host platform retrieves information on the completion status of the write command from the read status field 102. In this example, the flash memory device repeats the DDR field 94 and the LEN field 96 in order for the host platform to have a reference to the specific command related to the status packet 100.

As shown in FIG. 11, a "read request" packet 104 contains the opcode for the "read" command in a read field 106 and the logical address of the desired location from which the flash controller should read in a ADDR field 108. Upon receiving this command, the lightning controller issues a read command for the MTD block, after the address resolution module has translated the address contained in the ADDR field 108 into a specific physical address in one of the lightning components.

When the lightning controller receives data from the lightning device, either after the read command is issued or if an error occurred, the lightning controller sends a signal to the host platform to indicate that the new status packet should be read . The host platform issues a read request and receives a "read status" packet 110 as shown in Figure 12. The read status packet 110 contains the address of the read data in the ADDR field 108, as well as the length of the read data in a LEN field 112 and the data itself in a data field 114. The read status packet 110 also contains the status word according to which the operation was completed, in a status field 116. The read operation can complete with many different status situations such as success, failure, detected error, invalid address, invalid length, and so on.

When the host platform has to erase an erasure unit from the flash device, the host platform issues a "erase request" packet 118, shown in Figure 13. This packet contains the operation code "erase" in a field 120 of erase and the logical address of the erase unit in an ADDR 122 field. Upon receiving such a request, the flash controller translates the logical address into a physical erase unit in one of the physical address spaces of the flash modules, and issues an erase command to the MTD block.

ES 2 344 359 T3

The erase process generally takes longer than a write or read process. When this erasure process is complete, the controller notifies the host platform that a new status packet is ready to be transmitted. The controller then transmits a "clear state" packet 124, as shown in FIG. 14. The delete status packet 124 contains the address of the deleted unit in an ADDR field 122, thus providing the host platform with a reference to the delete requests. The state according to which the operation was completed is provided in a state field 126.

It will be appreciated that the above descriptions are only intended to serve as examples and that many other embodiments are possible.