Memory device operable in read-only and re-writable modes of operation

Abstract

A one-time programmable (OTP) memory device and methods for use therewith are provided. These embodiments can be used to provide compatibility between a memory device that uses an OTP (or few-time programmable (FTP)) memory array and host devices that use a file system, such as the DOS FAT file system, that expects to be able to rewrite to a memory address in the memory device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 61/044,410, filed Apr. 11, 2008, and U.S. Provisional Application No. 61/057,672, filed May 30, 2008, both of which are hereby incorporated by reference.

BACKGROUND

Portable memory devices, such as memory cards, are often used with consumer electronic devices, such as mobile phones and personal computers (PCs), to store and/or transport data. In addition to a storage medium, many portable memory devices contain circuitry, such as a microprocessor or controller, that can transform logical addresses received from the host device to physical addresses used by the memory device, thereby allowing the circuitry on the memory device to control where data is stored in the storage medium.

Many memory devices use a rewritable memory, which allows a memory address to be erased and rewritten for system or user purposes. However, other memory devices use a one-time programmable (OTP) memory array. In an OTP memory array, once a memory cell at a memory address is changed to a programmed state, it cannot be changed back to its original, unprogrammed state. Because of this limitation on the number of times a memory address can be written, memory devices with OTP memory arrays may not be compatible with host devices that use the popular DOS FAT file system or other file systems that expect to be able to rewrite to a memory address. A similar problem occurs, to a lesser extent, with memory devices that use a few-time programmable (FTP) memory array, whose memory cells can be written more than once but not as many times as memory cells in a rewritable memory array.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a host device in communication with a memory device of an embodiment.

FIG. 2 is an illustration of a dual-mode behavior of a memory device of an embodiment.

FIGS. 3 and 4 are illustrations of how a controller of a memory device of an embodiment makes logical memory appear rewritable even though the underlying memory is one-time programmable.

FIG. 5 is an illustration of a relationship between logical memory and physical memory of an embodiment.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

By way of introduction, the following embodiments relate generally to providing compatibility between a memory device that uses a one-time programmable (OTP) (or few-time programmable (FTP)) memory array and host devices that use a file system, such as the DOS FAT file system, that expects to be able to rewrite to a memory address in the memory device. An OTP memory is a memory in which memory cells are fabricated in an initial, un-programmed digital state and can be switched to an alternative, programmed digital state at a time after fabrication. For example, the original, un-programmed digital state can be identified as the Logic 1 (or Logic 0) state, and the programmed digital state can be identified as the Logic 0 (or Logic 1) state. Because the memory cells are OTP, an original, un-programmed digital state of a storage location (e.g., the Logic 1 state) cannot be restored once switched to a programmed digital state (e.g., the Logic 0 state). In contrast, an FTP memory is a memory in which memory cells can be written to more than once but not as many times as a typical rewritable (or write-many) memory array.

Many techniques can be used to make a OTP memory device compatible with a rewritable file system of a host device. In one technique, the memory device is configured to behave exactly the same as a standard flash rewritable memory device until the memory is fully consumed, at which point the memory device would stop performing write operations. Until the memory is consumed, the memory device is essentially indistinguishable from a normal rewritable memory device. In this way, such a memory device would be backwards-compatible with existing host applications and devices. U.S. Patent Application Publication No. US 2006/0047920 and U.S. Pat. No. 6,895,490, which are both hereby incorporated by reference, provide further details on backwards-compatible memory devices. However, for certain hosts and certain host behaviors, there may be a danger of corner cases where the host might attempt to write data to the memory device, but the memory device would run out of memory and not be able to store the data (a typical example would be a digital camera attempting to store a picture on a memory card). In the worst case, the host device would not even realize the write had failed and would give no indication to the user that there was a problem.

To avoid this risk (and the accompanying negative end-user perception), the following embodiments provide a memory device that leverages the existing definition of a read-only memory (ROM) card type, provide read compatibility with existing host devices (such as existing SecureDigital (SD) host devices), and minimize the effort to modify host devices to write to an OTP memory device. In one presently preferred embodiment, the memory device takes the form of an SD memory card, based on OTP memory, that operates in accordance with a formal OTP card type specification set forth by the SecureDigital (SD) Association. Various features of these embodiments include, but are not limited to, the following:

A memory device that powers up in a read-only memory (ROM) mode to be compatible with existing specifications and readable in existing SD-compliant host devices.

A memory device that implements a new function (using a protocol defined in the SD specifications) to switch the memory device into a read/write (R/W) mode. When in R/W mode, the memory device generally behaves like a standard rewritable (e.g., flash) card, so minimal changes are needed for host devices to implement support for the OTP card.

Because, unlike a rewritable memory, an OTP memory is finite and can be fully consumed, in one embodiment, the memory card defines a new command (preferably compliant with the definition in the SD specifications) for the host device to track physical memory consumption.

Additional modifications for operations that program registers due to the limitations of OTP memory (as compared to rewritable memory) are also provided.

Turning now to the drawings, FIG. 1 is an illustration of a host device 10 in communication with a memory card 20 of an embodiment. As used herein, the phrase “in communication with” means in direct communication with or in indirect communication with through one or more components, which may or may not be shown or described herein. In this particular illustration, the host device 10 is in communication with the memory card 20 via mating ports. It should be noted that although a memory card 20 is being used for illustration in FIG. 1, a memory card 20 is just one example of a memory device that can be used with these embodiment. In general, a “memory device” can take any suitable form, such as, but not limited to, a memory card, a Universal Serial Bus (USB) device, and a hard drive. In one presently preferred embodiment, the memory device takes the form of a solid-state memory card, such as a SecureDigital (SD) memory card.

As shown in FIG. 1, in this embodiment, the memory card 20 comprises a controller 30 in communication with one or more memory devices 40. The memory device(s) 40 can comprise any suitable type of memory, such as, but not limited to, solid state, optical, and magnetic memory. In one embodiment, at least some of the memory device(s) 40 comprise OTP and/or FTP memory. In the event that multiple memory devices 40 are used, it should be understood that the various memory devices can each use the same or different memory technologies (e.g., (i) all OTP, (ii) OTP and FTP, or (iii) OTP, FTP, and rewritable). Preferably, the memory device 40 comprises a field-programmable solid-state memory array. The memory cells in the memory array can be organized in a two-dimensional or three-dimensional fashion. In one preferred embodiment, the memory array is a three-dimensional array, such as an array described in U.S. Pat. No. 6,034,882 to Johnson et al., which is hereby incorporated by reference.

The controller 30 is operative to perform various functions, some of which are described below. While a controller 30 is shown in FIG. 1, it should be understood that the memory card 20 can comprise any suitable circuitry 130. As used herein, “circuitry” can include one or more components and be a pure hardware implementation and/or a combined hardware/software (or firmware) implementation. Accordingly, “circuitry” can take the form of one or more of a controller, microprocessor, or processor that executes computer-readable program code (e.g., software or firmware stored in the memory device(s) 40, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, for example.

Also, a “host device” refers to any device that can be put in communication with a memory device and be used to store data in the memory device and/or read data from the memory device. Examples of host devices include, but are not limited to, consumer electronic devices such as mobile phones, digital media players, digital cameras, game devices, personal computers (e.g., desktop or portable (such as laptop or notebook) computers), email and/or text messaging devices, and personal digital assistants (PDAs). A host device can be a relatively mobile device (such as a mobile phone) or a relatively stationary device (such as a desktop personal computer).

In this embodiment, the OTP memory card 20 implements two modes of operation. In the first mode, the memory card 120 powers up in a configuration compatible with an existing ROM card definition already defined in the SD specifications (and, therefore, supported by compliant SD host devices). In the second mode, the memory card 20 is switched into a writable mode before accepting and performing writes. (A suitable ROM card configuration and behavior are described in the SD Part 1 Physical Layer Specifications v2.00, as well as in the Part 1 Physical Layer Specification version 2.00 Supplementary Notes version 1.00. The switch command protocol was defined in the SD specifications for the general situation of enabling expanded or additional features for an SD card (see section 4.3.10 of the SD Part 1 Physical Layer Specification, version 2.00.).) By powering up in a read-only mode that is compatible with an existing card definition, existing host devices can still read from the memory card 20 but cannot write to the memory card 20, providing read compatibility with existing host devices but avoiding the dangers that those non-enabled host devices will write to the memory card 20 and run into the problematic corner case discussed above.

Because, in this embodiment, host devices must issue a command to switch the memory card 20 into a writable mode, only host devices that have been enabled to work with the OTP memory card 20 and understand its unique features will be able to write to it. FIG. 2 illustrates the memory card's 20 dual-mode behavior. The left-hand illustration in FIG. 2 shows that (1) the memory card 20 powers up in a read-only mode so legacy host devices can only read from the card 20, (2) only enabled host devices know how to switch the card 20 into a read/write mode, and (3) in read/write mode, enabled host devices can both read and write to the card 20.

In its writable mode, the memory card 20 behaves similarly to a “normal” flash rewritable memory card, at least until the memory card's OTP memory 40 is fully consumed. So, for example, if the host device 10 overwrites a sector of data with different data (which is often done for rewritable memory cards for a variety of reasons), the memory card 20 accepts and performs the requested write operation. (Because the underlying memory device 40 is OTP in this embodiment, memory on the device 40 itself cannot be changed after being written, but the card 20 firmware can automatically write updated data to a new location in memory and “remap” the old location to the new location. This remapping functionality is similar to the remapping that occurs in firmware in existing flash memory devices (see, for example, U.S. Pat. No. 7,139,864, which is hereby incorporated by reference).) This “overwrite” behavior ensures that there are minimal changes that the host device 10 must make to support the OTP memory card 20. The host device 10 can use any file system (most use the industry-standard FAT file system) and can still perform all the operations that it does for rewritable memory cards, including file rename, change, and delete operations, for example.

With reference again to FIG. 1, the host device 10 interfaces to the memory card 20 using logical addresses, the controller 30 acts as the interface between the host device 10 and the physical memory device(s) 40 and performs logical-to-physical addressing. The interface between the controller 30 and the memory device(s) 40 uses physical addresses. This interface implementation is standard to existing flash memory devices (see, for example, U.S. Pat. No. 7,139,864, which is hereby incorporated by reference). FIGS. 3 and 4 demonstrate how the controller 30 makes the logical memory appear rewritable even though the underlying memory 40 is OTP. FIG. 3 shows that original data stored at a logical address is stored in a physical location within the memory device 30. FIG. 4 shows that when the host device 10 overwrites the data at the logical address, the new updated data is stored at a new physical address, and the controller 30 updates its logical-to-physical addressing to reference the updated data instead of the now super-ceded original data. Again, the process is similar to the existing flash memory device implementation noted above; however, a difference between this embodiment and the flash implementation is that the memory 40 in this implementation (here, OTP) is not erased and re-used.

In its writable mode, the memory card 20 implements a new command (Read_Mem_Remaining) for the host device 10 to track the amount of physical (OTP) memory remaining. (The command code was allocated and defined in the SD Part 1 Physical Layer Specification, version 2.00, section 4.3.12 Command System as part of the switch command protocol, but the data values and format was defined specifically for the OTP card application.) The following table lists the values returned by the Read_Mem_Remaining, in a presently preferred embodiment (of course, other implementations can be used). Values are preferably returned in most-significant-byte, most-significant-bit order.

Byte Position	Parameter	Description
511:508	Main Area	Amount of memory remaining in the
	Remaining	“main” area of the card. Reported in
		units of sectors (200 h bytes).
507:504	Reserve Area	Amount of memory remaining in the
	Remaining	“main” area of the card. Reported in
		units of sectors (200 h bytes).

By making the host device 10 responsible for tracking memory consumption, the memory card 20 definition avoids the problem with the original OTP card implementation, where the card tries to discern what the host device is doing and why. With this new definition, the memory card 20 is free to accept and perform all write operations, since only enabled host devices will be able to write to it, and they are responsible for tracking memory consumption and avoiding illegal operations.

In this embodiment, the first two values returned by the new command (“main” and “reserve”) report to the host device 10 the amount of physical space remaining on the card 20 (1) for general/unspecified uses (file data and file system operations) (the “main area”) and (2) that is reserved for file system operations only (no file data) (the “reserved area”). The main value was defined so that the host device 10 can use it the same way it currently uses the FAT tables: to both determine how many more files (or, more generally, how much more data) can be written to the card 20 and to decide when the card 20 is full and the host device 10 should stop writing data to the card 20. The reserve value was defined so that the host device 10 would always be able to perform the file-system related operations necessary to complete a file that had been in progress when the card 20 was completely consumed (as reported by the main area), in the same way as it does for the FAT file system structures. This minimizes the changes a host device 10 must make in order to support OTP cards in addition to rewritable cards.

FIG. 5 illustrates the relationship between logical memory (visible to the host device 10) and the physical memory 40 (not directly visible to the host device 10). The amount of unused logical memory is tracked by file system structures, typically a “File Allocation Tables” for the standard FAT file system. The controller 30 in the memory card 20 manages logical-to-physical addressing. Overwritten data, which is represented is this diagram by cross-hatches, is no longer referenced but still consumes physical memory. The controller 30 reports the amount of physical memory remaining using a new command, so the host device can determine the amount of space available. The amount of physical memory remaining may be smaller or larger than the amount of logical memory remaining.

In this embodiment, the behavior of “Program_CSD” and “Lock_Unlock” commands are also modified to reflect the fact that the card memory 40 is OTP and not rewritable. That is, these commands are preferably used only once to update/program the related registers. The Card Status Defaults (CSD) register reports the card's 20 operating conditions and supported commands and features. It also includes a small number of writable bits that are used to indicate the card's 20 write protect status and if the card 20 is original data or is a copy. These bits can only be set once, collectively; if any bits are changed by issuing the Program_CSD command, then the command can not be used again to further update the CSD register. The Lock_Unlock command is used to both set the card 20 password and to supply the password to later unlock the card 20. For the OTP card 20, the password can only be set once and, once set, can never be changed or cleared. If the password has been set, then this has implications on the future behavior of the card 20 as required by the SD specifications. Also, the OTP card 20 preferably does not support the “force erase” operation described in the SD specifications, where if the password is forgotten, the card 20 can be completely erased (clearing the password), because the OTP card 20 does not support the erase operation. Specifying that these two registers can be changed only once each achieves two purposes. First, it fixes the amount of space the card 20 must reserve in order to store the update register value, and, second, it allows the host device 10 to determine if the register has already been changed or not (if the register does not match its default value, it must have been modified, and since it has been modified, it may not be modified again). This would obviously not be true if the host device 10 could change the register values more than one time.

As noted above, the examples described herein are only some of the many implementations these embodiments can take. Also, while the use of OTP memory was used in these examples, it should be noted that the teachings described herein can also be applied to FTP memories. Further, although the memory card 20 in these embodiments took the form of an SD card, as mentioned above, any suitable type of memory device can be used, including, but not limited to, those in compliance with MultiMedia, Memory Stick, Compact Flash, Smart Media, xD, USB, or HS-MMC specifications.

Some of the following claims may state that a component is operative to perform a certain function or is configured for a certain task. It should be noted that these are not restrictive limitations. It should also be noted that the acts recited in the claims can be performed in any order—not necessarily in the order in which they are recited. Also, it is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention can take and not as a definition of the invention. It is only the following claims, including all equivalents, that are intended to define the scope of this invention. Finally, it should be noted that any aspect of any of the preferred embodiments described herein can be used alone or in combination with one another.

Claims

1-2. (canceled)

3. A memory device comprising:

a memory; and

a controller in communication with the memory, wherein the controller is operable in first and second modes of operation, wherein in the first mode of operation, the memory device operates in a read-only mode, and wherein in the second mode of operation, the memory device operates in a re-writable mode.

4. The memory device of claim 3, wherein the memory device powers up in the first mode of operation and switches to the second mode of operation in response to a command from a host in communication with the memory device.

5. The memory device of claim 4, wherein the command from the host is in compliance with a switch command protocol defined in section 4.3.10 of SecureDigital (SD) Part 1 Physical Layer Specification, version 2.00.

6. The memory device of claim 3, wherein the read-only mode is compliant with the ROM card type definition in SecureDigital (SD) Part 1 Physical Layer Specification version 2.00, Supplementary Notes, version 1.00.

7. The memory device of claim 6, wherein the memory device powers up in the first mode of operation, and wherein the memory device is readable in SecureDigital (SD) compliant hosts upon power up.

8. The memory device of claim 3, wherein the controller is operative to:

receive a command from a host in communication with the memory device to write data to a first logical address, wherein the first logical address is mapped in the memory device's logical-to-physical address map to a first physical address of the memory;

determine if the first physical address of the memory has already been written to;

if the first physical address of the memory has not already been written to, write the data in the first physical address of the memory; and

if the first physical address of the memory has already been written to: instead of writing the data to the first physical address of the memory, write the data to a second physical address of the memory, wherein the second physical address of the memory has not already been written to, and update the logical-to-physical address map so that the first logical address is mapped to the second physical address instead of the first physical address.

9. The memory device of claim 3, wherein the controller is operative to:

receive a command from a host in communication with the memory device to track consumption of the memory; and

send the host a response to the command.

10. The memory device of claim 9, wherein the response to the command comprises an amount of remaining physical space in a main memory area used both for file data and for file system operations and an amount of remaining physical space in a reserved memory area used only for file system operations.

11. The memory device of claim 9, wherein the response to the command is in compliance with a switch command protocol defined in section 4.3.10 of SecureDigital (SD) Part 1 Physical Layer Specification, version 2.00.

12. The memory device of claim 3, wherein the controller is further to perform one or both of the following commands only once: a command to program a card status defaults (CSD) register in the memory and a command to set a memory device password.

13. The memory device of claim 3, wherein the controller does not support a command to perform a force erase operation to erase the memory if a memory device password is forgotten.

14. The memory device of claim 3, wherein the memory device is a SecureDigital (SD) memory card.

15. The memory device of claim 3, wherein the memory comprises a one-time programmable (OTP) memory.

16. The memory device of claim 3, wherein the memory comprises a few-time programmable (OTP) memory.

17. The memory device of claim 3, wherein the memory comprises a re-writable memory.

18. A method for using a memory device, the method comprising:

performing the following in a controller of a memory device comprising a memory: operating the memory device in a read-only mode when the controller is in a first mode of operation; and operating the memory device in a re-writable mode when the controller is in a second mode of operation.

19. The method of claim 18 further comprising:

powering-up in the first mode of operation; and

switching to the second mode of operation in response to a command from a host in communication with the memory device.

20. The method of claim 19, wherein the command from the host is in compliance with a switch command protocol defined in section 4.3.10 of SecureDigital (SD) Part 1 Physical Layer Specification, version 2.00.

21. The method of claim 18, wherein the read-only mode is compliant with the ROM card type definition in SecureDigital (SD) Part 1 Physical Layer Specification version 2.00, Supplementary Notes, version 1.00.

22. The method of claim 21, wherein the memory device powers up in the first mode of operation, and wherein the memory device is readable in SecureDigital (SD) compliant hosts upon power up.

23. The method of claim 18 further comprising:

receiving a command from a host in communication with the memory device to write data to a first logical address, wherein the first logical address is mapped in the memory device's logical-to-physical address map to a first physical address of the memory;

determining if the first physical address of the memory has already been written to;

if the first physical address of the memory has not already been written to, writing the data in the first physical address of the memory; and

if the first physical address of the memory has already been written to: instead of writing the data to the first physical address of the memory, writing the data to a second physical address of the memory, wherein the second physical address of the memory has not already been written to, and updating the logical-to-physical address map so that the first logical address is mapped to the second physical address instead of the first physical address.

24. The method of claim 18 further comprising:

receiving a command from a host in communication with the memory device to track consumption of the memory; and

sending the host a response to the command.

25. The method of claim 24, wherein the response to the command comprises an amount of remaining physical space in a main memory area used both for file data and for file system operations and an amount of remaining physical space in a reserved memory area used only for file system operations.

26. The method of claim 24, wherein the response to the command is in compliance with a switch command protocol defined in section 4.3.10 of SecureDigital (SD) Part 1 Physical Layer Specification, version 2.00.

27. The method of claim 18 further comprising perform one or both of the following commands only once: a command to program a card status defaults (CSD) register in the memory and a command to set a memory device password.

28. The method of claim 18, wherein the controller does not support a command to perform a force erase operation to erase the memory if a memory device password is forgotten.

29. The method of claim 18, wherein the memory device is a SecureDigital (SD) memory card.

30. The method of claim 18, wherein the memory comprises a one-time programmable (OTP) memory.

31. The method of claim 18, wherein the memory comprises a few-time programmable (OTP) memory.

32. The method of claim 18, wherein the memory comprises a re-writable memory.