JPH09198884A - Management method of flash memory - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve higher reliability of a flash memory by detecting the saturation of an alternative area as quickly as possible. SOLUTION: Card management information read out of a flash memory card 11 is reloaded at each block alternative processing and based on the results, it is examined whether alternatively applicable spare block is left or not. When the absence of the alternatively applicable spare block is detected, a procedure for extending the use of the flash card 11 is started immediately. This enables early detection of the saturation of the alternative area before the deficiency of the flash memory card 11 itself occurs because of disability of alternative application thereby enabling enhancing of the reliability of the flash memory sufficiently.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a flash memory management method, and more particularly to a management method for a flash memory device having a flash EEPROM having spare blocks for replacing defective blocks.

[0002]

2. Description of the Related Art Conventionally, a disk device such as a hard disk device or a floppy disk device has been usually used as an external storage device of a data processing device such as a personal computer or a workstation.

Recently, a flash memory card having a built-in flash EEPROM has come to be used as an external storage device replacing these disk devices, and a personal computer equipped with a card mounting slot as a standard device or an external device. Peripheral devices such as memory card readers / writers attached and used are also being developed.

The flash memory card is highly portable and can handle a file having a larger capacity than a floppy disk. Therefore, it is particularly effective as an external storage device such as a notebook type portable computer, PDA, electronic still camera and the like.

[0005]

However, the flash memory card has an inherent problem that the number of times of rewriting is limited, and although it is continuously improved by adopting a new memory technology, it is used as an external storage device. In terms of use, the reliability of data storage is not perfect. Therefore, in the flash memory card, it is necessary to manage not only data read / write but also data reliability by software.

Usually, in a flash memory card, a spare block is prepared and reliability is improved by substituting a spare block for a defective block in which a read / write error has occurred. However, conventionally, it is not possible to detect whether or not an unused spare block remains until a stage at which a defective block actually occurs and replacement processing thereof is started. For this reason, if a defective block occurs after all spare blocks have been used, the immutability cannot be detected for the first time at that point, thereby disabling card access at all. Therefore, the user is notified of the card failure when the card access is prohibited, and at this time, the data backup operation cannot be performed.

The present invention has been made in view of the above circumstances, and provides a flash memory management method capable of quickly detecting the saturation of the alternative area and sufficiently improving the reliability of the flash memory. The purpose is to do.

[0008]

SUMMARY OF THE INVENTION The present invention relates to a method of managing a flash memory device having a flash EEPROM in which a spare block for replacing a defective block is prepared, the defective block of the flash EEPROM and its replacement. The card management information indicating the relationship with the used spare block is read from the flash memory device, the card management information is rewritten every time a defective block is replaced by a spare block, and a spare block that can be replaced is created based on the result of the rewriting. Performing a procedure for extending the life of the flash memory device before detecting a remaining spare block and detecting that the spare block that can be replaced is lost Is characterized by.

In this flash memory management method, the card management information read from the flash memory device is rewritten every time the block replacement process is performed, and it is checked based on the result whether or not there is a spare block that can be replaced. If it is detected that the alternative spare block is exhausted, at that time, the procedure for extending the life of the flash memory device is started. Therefore, it becomes possible to quickly detect the saturation of the alternative area before a failure of the flash memory device due to the inability to replace occurs, and it is possible to sufficiently improve the reliability of the flash memory.

As a procedure for extending the life of the flash memory device, in addition to notifying the user, the access form is limited to read-only, the alternative process is prohibited, and the access right to a new defective block is eliminated instead. ,
It is preferable to perform processing such as allocating blocks other than the spare blocks as spare blocks to increase the number of spare blocks. As a result, the life of the flash memory device can be extended.

[0011]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 shows a configuration of a flash memory card 11 controlled by a flash memory management method according to an embodiment of the present invention, and a hardware and software configuration of a portable personal computer that controls access to the card 11.

The flash memory card 11 is JEIDA
/ PCMCIA-compliant PC card having physical and electrical specifications, and like other PC cards 12, a PC card host adapter 13 of a personal computer
It is detachably attached to the card slot provided by.

The flash memory card 11 is recognized and accessed by being loaded into the system memory of the personal computer and executed. The flash memory card driver 14, the card service 15, and the socket service 1
6, and the memory technology triber 17 and the like.

The flash memory card driver 14 is
It is a device driver program corresponding to the flash memory card 11, and is used as a client driver defined by JEIDA / PCMCIA. The flash memory card driver 14 includes an operating system 18 and application programs 19
From the command for the flash memory card 11 (page write command, page read command,
(Block erase command, etc.) to access control the flash memory card 11.

Further, the flash memory card driver 1
In order to improve the reliability of the flash memory card 11, 4 is a function of managing an error history generated by accessing the flash memory card 11, a function of replacing a defective block, and a function of extending the life of the card when the replacement area is exceeded. have.

Card service 15, socket service 1
6 and a memory technology driver 17 are a driver program group defined by JEIDA / PCMCIA, respectively, and are used for resource management of PC card, PC
It is used for card recognition.

The flash memory card 11 is a PC card used as a secondary storage device of a personal computer and has an attribute memory 111 and a common memory 112 built therein.

The attribute memory 111 is an EEPR.
It is a non-volatile memory composed of an OM or the like, and card attribute information is stored therein. The card attribute information includes information such as the type of memory of the common memory 112, the memory size, and the access speed, and information on the purpose of the flash memory card 11 (whether it is used as a disk or a memory).

Further, this flash memory card 11
, The NA used for the common memory 112
A value indicating the erase limit number of the ND type flash EEPROM is also stored in the attribute memory 111 as one of the card attribute information.

The common memory 12 is a memory device for storing user data supplied from a personal computer, and includes a plurality of NAND flash E.
It is composed of an EPROM.

In the NAND flash EEPROM, the minimum amount of data to be handled when writing or erasing is defined, erasing is executed in block units, and data writing and reading are executed in page units.

In this embodiment, the NAND flash EEPROM is, for example, a 16 Mbit NAND.
Suppose a type flash EEPROM is used. This 16 Mbit NAND flash EEPR
As shown in FIG. 2, the OM includes a memory cell array 21 and a data register 22. The memory cell array 21 has a memory configuration of 8K rows × 264 columns × 8 bits, and is divided into 512 blocks. Data erasing can be performed in units of this block. Each block is composed of 16 pages (rows), and each page has a data storage area of 256 bytes and a redundant area of 8 bytes.

Data writing and reading is 256 + 8
Through the byte data register 22, page units (2
56 + 8 bytes). Further, it is possible to read / write only the redundant area (8 bytes) in the designated page.

The data storage space of the common memory 112 of FIG. 1 includes a user data storage area including a large number of blocks,
It is divided into a spare block area including some spare blocks for replacing defective blocks and a card management information area including blocks for storing card management information.

The card management information includes a bad block management table for managing physical block numbers (physical block addresses) of defective blocks in which data writing and erasing cannot be normally executed, and a physical block number for each spare block. Includes a spare block management table for managing the physical block number (physical block address) of the defective block to be replaced.

By rewriting the contents of these defective block management table and spare block management table, the defective block can be replaced by a spare block. That is, the block in which an error has occurred is treated as a bad block by registering its physical block number in the bad block management table. If the block to be accessed is a defective block, the spare block management table is referred to and the spare block of the replacement destination is recognized. As a result, the spare block is accessed instead of the defective block. The flash memory card driver 14 reads the card management information from the card 11 when the flash memory card 11 is inserted, and creates a card management flag. The card management flag is used to detect the excess of the alternative area promptly and to realize a card life extension function at that time.

In the common memory 112, the 8-byte redundant area of each page is used to store management data such as page status information. This management data is managed by the above-mentioned flash memory card driver 14 in order to improve the reliability of the flash memory card 11.

The page status information is composed of a plurality of flags for identifying the error content generated in the access to the corresponding page. The flash memory card driver 14 can recognize the error occurrence history or the like in page units by referring to the flags in each redundant area.

Hereinafter, referring to FIG. 3, the common memory 11 will be described.
The storage formats of the user data and the management data on the computer 2 will be specifically described. 1 page data area is 2
Since it is 56 bytes, when the flash memory card 11 is used as a floppy disk or a hard disk, user data for one sector is stored in two consecutive pages as shown in the figure.

8 of the first page (page 0) of each block
The following management data is stored in the byte redundant area. LRC for page data (2 bytes) Erase counter (4 bytes) LRC for erase counter (1 byte) Page status information (1 byte) LRC for page data uses the horizontal redundancy check (LRC) method to page 0 Is an error correction code obtained by calculating the user data (upper 256 bytes of sector 0) stored in the 256-byte data area.

This page data LRC is created at the time of data write and is referred to at the time of data read. When passing the data to the upper software (OS, application program), the flash memory card driver 14 uses the page data LRC to check the validity of the data.

The erase counter indicates the erase count (data rewrite count) of the corresponding block, and is written only in the first page of each block. The data length of the erase counter is 4 bytes, and the maximum is 4G (giga).
You can write the number of times. The reason why such a large data length is ensured is that it is considered that the limit number of erasures will increase due to the progress of the flash memory device technology in the future.

The value of the erase counter is incremented by +1 every time the corresponding block is erased. When the value of the erase counter exceeds the erase limit number of times stored in the attribute memory 111, the flash memory card driver 14 executes a process for replacing the block with a spare block.

The value of the erase limit number stored in the attribute memory 111 is set in order to secure a margin.
It is set to a value smaller than the actual erase limit number of the flash EEPROM itself.

The erase counter LRC is the upper 4
Byte erase counter to horizontal redundancy check (LRC)
It is the error correction code calculated by. The erase counter is important data that affects the data management of the entire block, and the erase counter LRC is used to ensure the reliability of the erase counter.

The page status information indicates the status of the corresponding page, and the status of the corresponding page is represented by eight flags by giving meaning to each of the 8 bits in the 1 byte.

In each of the redundant areas of pages 1 to 16, only the page data LRC and the page status information are stored, and the erase counter and the erase counter LRC are not stored.

Next, details of the page status information will be described. The page status information can have eight flags, but in this embodiment, the following five flags are defined.

Program flag (b7) b7 = 0 (programmed) = 1 (unprogrammed: erased) Erase count over flag (b6) b6 = 0 (erase count exceeds threshold) Verify error flag (b2) b2 = 0 (Read verify error) Program error flag (b1) b1 = 0 (Program error) Erase error flag (b0) b0 = 0 (Erase error) In normal status (including factory shipment), page status information One byte is represented by FFh (8 bits are all 1). Hereinafter, each flag will be described.

The program flag (b7) is used to determine whether or not block erase needs to be executed when writing data to the corresponding page, and the block including the corresponding page is erased. State (program flag = 1) in which the writing to the corresponding page has not been executed yet and a state in which the writing to the corresponding page has already been executed (program flag =)
0) is indicated.

Immediately after the erase-only command is issued,
In the initial state, the program flag is "1". In this case, there is no need to erase again when writing.
The erase count over flag (b6) indicates that the erase count of the block including the corresponding page is the attribute memory 1
11 is a flag indicating whether or not the value of the erase limit number recorded in 11 is exceeded.

That is, the flash memory card device driver 14 increments the value of the corresponding erase counter by +1 every time block erase is executed,
It is checked whether or not the value of the incremented erase counter exceeds the erase limit number of times in the attribute memory 111. If it exceeds, the erase count over flag of "0" is set in the redundant area of all pages included in the corresponding block or the redundant area of the first page of the block. Further, in this case, the block is treated as a defective block even if it has not deteriorated at that time, and the replacement process with the spare block is performed. The flash memory card device driver 14
By referring to the erase count over flag of each defective block, it is possible to identify whether the block actually causes an error or the block treated as defective by the erase count excess.

The verify error flag (b2) is a flag indicating whether or not an error has occurred in the read verify operation executed at the time of page reading for the corresponding page.

That is, the flash memory card device driver 14 reads the data from the specified page, and then verifies the validity of the read data by using the corresponding page data LRC. If an error is detected in the read data, the verify error flag is set to "0". In this case, the page read is retried, but when an error occurs again in the retry processing, the block including the page is treated as a defective block and replaced with the spare block. The defective block replaced by the verify error will not be used thereafter.

The program error flag (b1) is a flag indicating whether or not an error has occurred in the program verify operation executed for verifying the correctness of the write data after executing the page write (program) for the corresponding page. Is.

That is, the flash memory card device driver 14 writes the write data to the designated page, then once reads the data from the page, and compares it with the write data. If they do not match, the program error flag is set to "0". in this case,
The page write is retried, but when an error occurs again in the retry processing, the block including the page is treated as a bad block and replaced with the spare block. In this alternative process, the contents of the defective block are read and copied to the spare block, and then write data is written to the spare block. The bad blocks replaced due to the program error will be
Never used.

The erase error flag (b0) is a flag indicating whether the erase operation for the block including the corresponding page has been normally executed. That is, the flash memory card device driver 14 checks whether or not the erase process is normally executed after executing the erase process for the designated block. If the erase fails, the redundant area of all pages included in the block, or the redundant area of the first page of the block,
The erase error flag of "0" is set. In this case, the block erase process is retried, but when an error occurs again in the retry process, the block is treated as a defective block and replaced with the spare block. The defective block replaced by the erase error is not used thereafter.

FIG. 4 shows the structure of the card management flag created and managed by the flash memory card driver 14. The card management flag is realized by using an 8-bit flag, and the internal state of the card is expressed by these 8 bits. The meaning of each bit of the card management flag is as follows.

"Bit 0 card detection flag" It becomes valid (bit is 1) when it is detected that a card has been inserted, and until the next insertion / removal event occurs in the system,
This flag is maintained. In the process of confirming the existence of the card inside the software, while this flag is valid, the processing can be performed without directly responding to the hardware.

This flag is used for card removal events,
The reset will not occur unless it detects that the card has changed during the execution of another process. "Bit 1 card certification status flag" The flag is valid when all the settings to make the card accessible are completed. By referring to this flag, it becomes possible to determine whether the card at that time should be set. If this flag is disabled, it will be possible to refer to other flags as well to determine what the software should do.

"Bit 2 management information read flag in card" In addition to data dynamically held in software,
When there is management information indicating the status of each card in the data area of the card, this is a flag indicating that the management information has been read into the memory area of the system. When this flag is valid, it is not necessary to read the information inside the card every time, and it becomes possible to operate by referring to the management information on the memory. This flag is used to improve the processing time of the software process. Further, even when the content of the management information is updated, it is possible to use the memory instead of directly reading the information from the inside of the card by referring to this flag and bit 00.

"Valid 3 Valid / Invalid Flag of Bad Block Management Table" In a memory card equipped with a flash EEPROM, a bad block occurs due to deterioration of a semiconductor during use of the card. This is a flag for determining whether the bad block management table to be managed is valid for the card which is being accessed when the table for managing the bad block exists in operation.
This makes it possible to immediately return an error when an access request is made to an address registered as a bad block.

"Bit 4 Status flag of entire card" When this flag is valid, it is possible to determine that there is no problem with the card at this time. If this flag is disabled, it will be possible to immediately return an error for any external access to the card. This flag is valid when all initialization processes immediately after card insertion are completed without any problems.

"Bit 5 alternative block excess flag" This flag indicates that all the blocks provided inside the card as an area for replacement when a defective block occurs are used. It is possible to take a card life extension measure such as putting the card into a read-only state before a card in which this flag is valid becomes a defective card after repeated forcible writing and erasing. This makes it possible to control so as not to cause data loss in a large range.

"Bit 6 Reserved area is set to 0""Bit 7 Card management information update request flag" When the content of the management information of the card read in the memory is updated and it becomes necessary to write to the data area in the card Flag is enabled. If it detects that this flag was valid, it proceeds to the process of updating the management information. Unless this flag is valid, there is no problem in managing the card even if the management information read into the memory is erased or overwritten by inserting or removing the card.

With such 8-bit (1 byte) data, various states in the card can be written. In the present embodiment, description will be made on the assumption that this flag is provided inside the flash memory card driver 14.

FIG. 5 shows the data format of the card management information. Although this card information may originally exist in any area of the data area, the card 11 is used in this embodiment.
It is described in the final erase block of. 1) Check bit string (offset 0h) The check bit string indicates the validity of the card management information, and is a fixed value of 16 bytes.

The card management information is stored in the last block of the card. However, if the last block is a defective block, it is stored in the block immediately before that. In this case, 00h is written in the place of the check bit string in the card management information.

If the check bit string is not read correctly, the card management information is recognized as invalid, and new card management information is created in the previous block. 2) Card version information (offset 10h) The version information is 2 bytes and indicates the specification version of the card.

Byte 0: Card major version The current card major version is 01h. Byte 1: Card minor version The current card minor version is 00h. 3) Total block number (offset 12h) Indicates the total block number of the card. This information must match the total number of blocks calculated from the memory capacity described in the attribute memory. The total number of blocks is 512 per 2 Mbytes of memory capacity of the card.

Byte0: total number of blocks (LSB) Byte1: total number of blocks Byte2: total number of blocks Byte3: total number of blocks (MSB) The total number of blocks in the data area can be obtained by the following formula.

Total number of blocks in data area = total number of blocks−
(Total number of spare blocks + total number of card management information blocks) 4) Block size (offset 16h) Indicates the number of bytes per block. This value is a fixed value of 4096.

Byte 0: Card block size (LSB) 00H Byte 1: Card block size (MSB) 10H 5) Page size (offset 18h) Indicates the number of bytes per page. This value is a fixed value of 256.

Byte 0: Card page size (LSB) 00H Byte 1: Card page size (MSB) 01H 6) Bad block table format (offset 1Eh) This shows the format of the bad block table in the card management information.

Byte 0: Bit 7-2 Reserved 00h Bit 1-0 Bad block table entry size 00 Reserved 01 Reserved 10 Each entry size of bad block table is 2 bytes 11 Reserved Byte 1: Reserved 00h 7) Bad block table offset (offset 2)
0h) Indicates the position of the bad block table. It is represented by the offset from the beginning of the card management information block.

Byte 0: bad block table offset (LSB) Byte 1: bad block table offset (MS)
B) 8) Number of bad block table entries (offset 2
2h) Indicates the number of entries in the bad block table. The maximum number of bad block table entries that the card device driver can support is 512.

Byte0: Number of bad block table entries (LSB) Byte1: Number of bad block table entries (MS
B) 9) Number of Registered Bad Blocks (Offset 24h) Indicates the number of bad blocks registered in the bad block table.

Byte 0: Number of registered bad block entries (LSB) Byte 1: Number of registered bad block entries (MSB) It is possible that a bad block entry was registered at the time of shipment. 10) Spare block table format (offset 2C
h) shows the format of the spare block table of the card.

Byte 0: Bit 7-2 Reserved 00h Bit1-0 Spare block table entry size 00 Reserved 01 Reserved 10 Each entry size of the spare block table is 2 bytes 11 Reserved Byte 1: Reserved 00h Spare block table format is a fixed value of 0002h is there. 11) Spare block table offset (offset 2Eh) The position of the spare block table is indicated by the offset from the beginning of the card management information block.

Byte 0: Spare block table offset (LSB) Byte 1: Spare block table offset (MS)
B) 12) Spare block table entry number (offset 30h) Indicates the number of entries that can be stored in the spare block table. If there is no alternative area, it is set to 0, and the maximum number of entries is 512. The spare block table entry is determined by the ratio (1 to 5%) to the total capacity of the card. There must be enough spare blocks to match the number of entries.

When the block in which the card management information is stored becomes defective, it is necessary to move the card management information to the end of the alternative area and reduce the total number of spare block table entries by one.

Since the alternative area is not secured at the time of shipping, the total number of spare block table entries is 0. Byte 0: number of spare block table entries (LS
B) Byte 1: number of spare block table entries (MS
B) 13) Number of used spare blocks (offset 32h) Indicates the number of spare blocks in use. The numbers described here also include defective blocks in the spare block area. Since the spare block area is not secured at the time of shipment, this numerical value becomes 0.

Byte 0: number of used spare blocks (LSB) Byte 1: number of used spare blocks (MSB) 14) number of card management information storage blocks (offset 3
8h) Indicates the number of physical blocks used as card management information. The maximum number of blocks that can store card management information is 50.

Byte0: Number of blocks for storing card management information Example: 0 ... Invalid (0 cannot be described here) 1 ... Card management information is stored in one physical block.

2 ... Card management information is stored in two physical blocks. : Byte1: Reservation 00h One card management information can span a plurality of physical blocks. For example, the bad block table and the spare table can be stored in different physical blocks. The numerical value registered here is related to the physical block size.
For cards, this number is always 1. 15) File format character string (offset 3E
h) Indicates identification information for using the card in a specific file format. This is represented by an 8-byte character string and indicates the card format. The following strings have already been defined.

“” Indicates that the blank card is not formatted with the specified file format.
(Factory default) "DOS FAT" Indicates that the format is the DOS FAT format. 16) Application / device information character string (offset 46h) Indicates identification information for use in a specific application or device. This is a 16-byte character string, and it does not matter if it is 16 characters or less.
However, the following strings are already defined.

"" (16 blanks) No specific application / device specified (factory default) 17) Bad block table (offset 400h) This is a table for registering a bad block. The physical block number of the bad block is stored. The physical block number is a value in which the head block of the card is 0. As bad block entries, 512 entries are prepared, and a block number is described in each entry with 2 bytes.

The area of the unused bad block entry is FF
FFh. This means that nothing is written in the entry. If a numerical value other than FFFFh is described, it means that it has been used. There must be no unused area in the used entry area. The unused area must always follow the used area. Since the bad block number is described in the table when a problem occurs, the numbers in the bad block entry are in no particular order. The number of blocks described needs to be described in the registration defective block number area.

Entry 0: Byte 0: Bad block # 0 (LSB) Byte 1: Bad block # 0 (MSB) Entry 1: Byte 0: Bad block # 1 (LSB) Byte 1: Bad block # 1 (MSB): Entry 511: : Bad block # 511 (LSB) Byte1: Bad block # 511 (MSB) Comment: FFFFh = empty 18) Spare block table (offset 800
h) A table showing that a defective block generated in the data area is replaced with a spare block. The spare block table is used from the beginning, and the physical block number in which the defect has occurred is registered in the table.

The bad block table is composed of 512 entries at the maximum, and the bad block number is stored in each entry. The first entry of the spare block is set to 0, and the defective block number replaced by the corresponding spare block table entry is stored.

The content of the unused bad block table entry is FFFFh. And this means that nothing is described in the entry. When the spare block is a defective block, the content of the corresponding spare block table entry is FFFEh. And this block cannot be used as a spare block. 0000h-F
A value up to FFDh indicates that it is effectively used as a spare block.

Entry 0: Byte 0: Bad block # 0 (LSB) Byte 1: Bad block # 0 (MSB) Entry 1: Byte 0: Bad block # 1 (LSB) Byte 1: Bad block # 1 (MSB): Entry 0: 511 : Bad block # 511 (LSB) Byte 1: Bad block # 511 (MSB) Comment: FFFFh = empty 19) Checksum (offset FFFh) The 2-byte checksum is calculated by the following calculation method.

The contents from the beginning of the management information area to immediately before the checksum are added in 16-bit length. Store the lower 16-bit two's complement of the result.

That is, if the result of adding 16 bits from the beginning to the end of the card management information block is 00h, it is a normal checksum. 20) Reserved (00h) Reserved area for future use, which is an area initialized to 00h. 21) Reserved (FFh) Reserved area for future use, which is an area initialized to FFh.

Next, the page read, page write, and block erase processing executed by the flash memory card device driver 14 will be described with reference to the flowcharts of FIGS.

First, referring to the flowchart of FIG.
A procedure of page read processing executed when a read command is issued from the OS 18 or the application program 19 will be described.

OS 18 and application program 1
Upon receiving the read request command from the flash memory card device 9, the flash memory card device driver 14 issues a page page command to start the read access to the page specified by the read request command. Read 8-byte management data at the same time (step S10)
1).

After that, the flash memory card device driver 14 calculates the LRC according to the 256-byte user data included in the read page data (step S102), and calculates the calculated LRC and the read page data. LRC for included page data
It is determined whether or not the page read has succeeded according to the presence or absence of (step S103).

If the calculated LRC matches the page data LRC included in the read page data, it is confirmed that the page read is normally executed,
The 256-byte user data included in the read page data is passed to the OS 18 and the application program 19 as valid data.

On the other hand, if they do not match, it is recognized that the page read has failed, the verify error flag is set to "0", and then the page read is retried (step S105). When a read processing error occurs again in this retry, the flash memory card device driver 14 performs block replacement processing (step S1).
06).

In this block substitution processing, the spare block management table of the card management information read from the card 11 and stored in the memory is rewritten, and the physical block number of the block in which the error has occurred corresponds to the predetermined spare block. Be registered with. Thereafter, the flash memory card device driver 14 registers the physical block number of the block in which the error has occurred in the defective block table and sets it as the defective block (step S1).
07). Further, here, the number of used spare blocks is +1.
Is checked to see if this causes a substitution block excess. Details of the processing in the case of excess of the alternative block will be described later with reference to FIG. 11.

By the processes of steps S106 and S107, the block number designating the defective block is converted into the block number of the spare block, and the spare block is accessed instead of the defective block.

Either step S106 or S107 may be executed first. Next, referring to the flowchart of FIG. 7, the OS 18 and the application program 1
A procedure of page write processing executed when a write command is issued from 9 will be described.

OS 18 and application program 1
Upon receiving the write request command from the flash memory card 9, the flash memory card device driver 14 first issues a dedicated command for reading only the redundant area to the flash EEPROM.
Is issued to read the 8-byte management data from the write-access target page (step S201). Then, the flash memory card device driver 14
By referring to the program flag included in the read management data, it is checked whether or not the corresponding page has been erased (step S202).

If the corresponding page has not been erased (program flag = “1”), the flash memory card device driver 14 performs the following processing prior to executing the page write processing in step S205 and thereafter.

That is, the flash memory card device driver 14 first executes the erase process for the block including the page to be written (step S20).
3) After that, the value of the erase counter included in the management data read in step S201 is incremented by +1 (step S204).

When the programmable state is achieved in this way, the flash memory card device driver 14
From 256 bytes of write data to page data LRC
Are calculated and page write data including 256 bytes of write data and 8 bytes of management data is generated (step S205).

Next, the flash memory card device driver 14 issues a page write command to execute write access of page write data (step S2).
06) Then, the written data is immediately read from the flash EEPROM, and the write verify is performed to compare it with the page write data (step S).
207).

If the read data and the page write data do not match and it is determined that the page write has failed, the flash memory card device driver 14 sets the program error flag to "0" and then retries the page write process. Yes (step S209). When a page write processing error occurs again in this retry, the flash memory card device driver 14 performs block substitution processing (step S215).

In this block replacement processing, first, the storage content of the block in which the error has occurred is copied to the spare block that replaces it, and then the write data is written to the spare block. After that, the spare block table of the card management information is rewritten, and the physical block number of the block in which the error has occurred is registered in the spare block entry that replaces it. Thereafter, the flash memory card device driver 14 registers the physical block number of the block in which the error has occurred in the bad block management table and sets it as the bad block (step S21).
6). In addition, here, the number of used spare blocks is incremented by 1, and it is checked whether or not a substitute block excess occurs.

By the processes of these steps S215 and S216, the spare block will be accessed in place of the defective block thereafter. Step S10
Either S6 or S107 may be executed first.

When the read data and the page write data match and it is determined that the page write is successful (including successful retry), the flash memory card device driver 14 determines whether the erase counter counted up in step S204 Value is attribute memory 11
It is checked whether or not the erase limit number of 1 has been exceeded (step S
210). If the erase limit number of times is exceeded, the flash memory card device driver 14 performs block substitution processing (step S211).

In this block replacement processing, first, after the storage contents of the block that has exceeded the erase limit number of times are copied to the spare block that replaces it, the value of the erase counter of the first page of the spare block is set to the initial value (= 0. ) Is set again. Then, the spare block table is rewritten, and the physical block number of the block that has exceeded the erase limit number is registered in the entry of the spare block that replaces it. Then, the number of used spare blocks is incremented by 1,
It is checked whether a substitution block excess occurs.

After that, the flash memory card device driver 14 registers the physical block number of the block in which an error has occurred in the bad block management table to make it the bad block (step S212), and then puts "" on the first page of the bad block. An erase count over flag of 0 "is set (step S213).

By the processes of these steps S212 and S213, the spare block will be accessed in place of the defective block thereafter. In addition, step S21
By the process of 3, it is confirmed that the cause of the bad block (the alternative cause) is that the erase count is exceeded.
You can know.

Either step S211 or S213 may be executed first. In addition, steps S210 to S
The process of 213 does not need to be executed when it is detected in step S202 that the program flag = 1. This is because if the program flag = 1, the erase counter is not counted up.

Next, referring to the flow chart of FIG.
A procedure of block erase processing executed when an erase command is issued from the OS 18 or the application program 19 will be described.

OS 18 and application program 1
When the erase command is received from the flash memory 9, the flash memory card device driver 14 first issues a dedicated command for reading only the redundant area to the flash EEPROM to read the 8-byte management data from the first page of the block erase target ( Step S301).
Then, the flash memory card device driver 14
Refers to the program flag included in the read management data to check whether or not the corresponding page is in the programmed state (step S302).

If the relevant page is programmed (program flag = “0”), the flash memory card device driver 14 issues a block erase command to execute the erase process for the block to be erased (step After that, the value of the erase counter included in the management data read in step S301 is incremented by +1 (step S304).

Next, the flash memory card device driver 14 determines whether the block erase has been normally executed, for example, by checking whether the stored data of the erased block is the initial value (each bit = "1"). It is detected (step S305).

When it is determined that the block erase has failed, the flash memory card device driver 14
“0” in the redundant area of the first page of the erase target block
After the erase flag is set, the block erase process is retried (step S306). If a block erase processing error occurs again in this retry,
The flash memory card device driver 14 performs block substitution processing (step S312).

In this block replacement processing, first, the spare block table is rewritten, and the physical block number of the block in which the error has occurred is registered in the entry of the spare block that replaces it. Thereafter, the flash memory card device driver 14 registers the physical block number of the block in which the error has occurred in the bad block management table and sets it as the bad block (step S31).
3). In addition, here, the number of used spare blocks is incremented by 1, and it is checked whether or not a substitute block excess occurs.

By the processes of these steps S312 and S313, the spare block will be accessed in place of the defective block thereafter. Note that step S31
Either S2 or S313 may be executed first.

If it is determined that the block erase is successful (including successful retry), the flash memory card device driver 14 determines that the erase counter value counted up in step S304 indicates the erase limit number of the attribute memory 111. It is checked whether or not it has been exceeded (step S307). If the erase count is exceeded, the flash memory card device driver 14
Performs block substitution processing (step S308).

In this block replacement processing, the physical block number of the block that has exceeded the erase limit number is registered in the entry of the spare block that replaces it. After that, the flash memory card device driver 14 registers the physical block number of the block in which the error has occurred in the defective block table and sets it as the defective block (step S3).
09), and then an erase count over flag of "0" is set to the first page of the defective block (step S).
310). Also, here, the number of used spare blocks is +
1 and it is checked whether a substitute block excess occurs.

By the processing of these steps S308 and S309, the spare block will be accessed in place of the defective block thereafter. Step S31
By the processing of 0, it is confirmed that the cause of the bad block (the alternative cause) is that the erase count is exceeded.
You can know. Note that steps S308 and S309
May be executed first.

On the other hand, if it is detected in step S307 that the erase limit number has not been exceeded, the flash memory card device driver 14 adds the value of the erase counter counted up in step S304 to the first page of the erased block. Is written, and the program flag of each page is reset to "1" to finish (step S311).

Next, referring to the flow chart of FIG.
A card management flag generation process performed at the time of card initialization will be described. When the flash memory card device driver 14 detects the card insertion by the notification from the card service 15, the flash memory card device driver 14 reads the CIS from the attribute memory of the card to determine whether the card is the flash memory card 11 or not.
If it is 1, the card detection flag b0 is set to 1 (step S401). After this, perform the card initialization routine,
When all the initialization is completed normally, the flash memory card device driver 14 determines that the card state setting flag b
1 is set to 1 (step S402). Next, the flash memory card device driver 14 reads the card management information from the flash memory card 11 into the main memory of the computer, and sets the management information read flag b2 to 1 when the card management information ends normally (step S40).
3).

After that, the flash memory card device driver 14 accesses an arbitrary bad block described in the bad block table of the read card management information, reads the page status flag, and checks whether it is really bad or not. Verify the validity of bad blocks.
If the page status flag has an error flag, it is determined that the content of the bad block table is correct, and the bad block management table valid / invalid flag b3 is set to 1 (step S404). Next, the flash memory card device driver 14 checks whether the total number of spare blocks designated by the number of spare block table entries in the card management information is larger than the number of used spare blocks designated by the number of used spare blocks. , If the number of spare blocks is larger than the number of used spare blocks, the alternative block excess flag b
5 is 0, and if it is less than or equal to the number of used spare blocks, the alternative block excess flag b5 is set to 1 (step S40).
5).

When all of the above processes have been completed normally and there is no error or excess of alternative blocks, the flash memory card device driver 14 sets the status flag b4 of the entire card to 1 (step S406).

Next, with reference to the flow chart of FIG. 10, a card management flag generation process performed at the time of updating the card management information will be described. The flash memory card device driver 14 sets the card management information update flag b7 to 1 when updating the card management information due to occurrence of a defective block or the like.

Next, using the flowchart of FIG. 11,
A card management procedure using the card management flag will be described. After the card 11 is inserted into the system and the signal that the card 11 is physically inserted is detected, the flash memory card device driver 14 loads the card management information into the memory area of the system (step S601). Next, the flash memory card device driver 14 reads the attribute information CIS of the card 11 and starts the initialization of the card (step S602). Then, after securing the necessary resources, flags that can be managed as card management flags are set. When all the initialization is completed, the card management flag is checked to determine whether the normal process can be executed (steps S603 and S60).
4).

When the execution of the normal process is started (step S605), necessary information is sent to the card management flag or
Alternatively, the card management information mapped in the memory may be referred to and checked, and if the state of the card 11 is changed, the flag and the card management information may be rewritten as necessary. This flag and card management information are held until updated or the card 11 is removed. When it is necessary to update the card management information due to the access process of the normal process (step S606), it is checked whether the alternative area excess flag of the card management flag is set according to the update result. .

Then, when the flag required for executing the normal process is not set, the following processing is performed. When 1 is set in bit 5 (step S60
7) Since the alternative area provided inside the card 11 is saturated, the access mode is switched to extend the life of the card 11 (step S611). And
By notifying the user of the saturation of the alternative area,
The operation of transferring the data in the card 11 to another medium is executed. Then, if the card 11 is removed (step S612), the process ends.

It is also possible to switch the access mode as follows and continue using the card. 1) Access mode 1 When the alternative area is saturated during use, the access mode of the card 11 is limited to read only in order to prevent the card from becoming a defective card. In this case, thereafter, erasing or writing to the card 11 is prohibited. This is because if writing and erasing are allowed without holding the state of the card 11, a normal block becomes a defective card due to lack of a replacement area when the block becomes defective.

After that, it becomes possible to provide two access modes that the card 11 can select. 2) Access Mode 2 One is a mode in which the state of the card 11 is kept as it is, and the card capacity is reduced while the access is not permitted to the defective block after the replacement area saturation.

2) Access Mode 3 The other is a mode in which the card can be used again by increasing the ratio of the alternative area to the total capacity when the card 11 is reformatted after the alternative area is saturated.

The difference between these two modes is that the user who is using the card 11 permits the decrease in the available capacity of the card 11 while knowing the available capacity, or the more the card is used, the more unconscious it becomes. The difference is that the card capacity will decrease. Which access mode the card 11 is in
The operation of the software is managed in the card management information or the card management flag described above is set to 1
Various methods such as 6-bit management with flags are possible. The management method will be described with reference to a specific example. In the card management information, it is possible to use the area already reserved as a 1 to 2 byte expression and set as follows. (Expressed in 1 byte) 00h ... Normal access mode 01h ... Alternative area expansion mode 02h ... Bad sector (block) mode FFh ... Read-only mode If the flag is expanded, the above 1-byte notation is converted to a bitmap. It can be realized just by doing. When using the flag, it is useless to use all 8 bytes for expressing the access mode, so the contents of the card management information are changed.

Bit 7 Bit 6 0 0 ... Normal access mode 0 1 ... Alternate area expansion mode 1 0 ... Bad sector (block) mode 1 1 ... Read-only mode When the access mode is managed by the card management information, the card is The mode remains valid unless the management information is rewritten. Conversely, when switching the mode within the management flag, the mode is valid only until the card is inserted and removed.

In the case of a flash memory card, efforts have been made to extend the life of the flash memory card by various methods. However, if the function of this embodiment is realized, the loss of data near the life of the flash memory card and the life of the PC card will be prevented. Can be extended.

Further, in FIG. 11, the processing for other bits is as follows. If the bit 0 is not 1 (step S608) and this flag is not enabled immediately after insertion, it is not a PC card to be managed by the flash memory card driver 14 or is removed immediately after insertion. It is determined that the process is stopped and the process is interrupted.

If the bit 1 is not 1 (step S609), all the conditions for the card 11 to operate may not be met, and the initialization process of the card 11 needs to be executed again. is there. If bits 2 and 3 are not set to 1 at the same time (step S610), it is possible that the card management information could not be read normally, or that the card management information could be read but the necessary information could not be read properly. is there. It is necessary to perform the reading process again or restart from the initialization of the card.

If the bit 4 is set to 1, the card is determined to be defective at the initialization stage, and any subsequent access is invalid. As described above, in this embodiment, the card management information read from the flash memory card 11 is rewritten every time the block replacement processing is performed, and it is checked whether or not there is a spare block that can be replaced based on the result. To be If it is detected that the spare blocks that can be replaced have run out, the procedure for extending the life of the flash memory card 11 is started at that point. Therefore, it becomes possible to quickly detect the saturation of the replacement area before the failure of the flash memory card 11 itself caused by the inability to replace, and it is possible to sufficiently improve the reliability of the flash memory.

In addition, the number of spare blocks is limited by restricting the access form to read-only, prohibiting the alternative process and excluding the access right to a new defective block, allocating blocks other than spare blocks as spare blocks. The life of the flash memory card 11 can be extended by performing processing such as increasing

[0135]

As described above, according to the present invention, the saturation of the alternative area can be detected quickly,
It is possible to sufficiently improve the reliability of the flash memory.

[Brief description of drawings]

FIG. 1 is a block diagram showing a hardware and software configuration of a personal computer using a flash memory card management method according to an embodiment of the present invention.

FIG. 2 is a diagram showing a circuit configuration of a flash EEPROM provided in the flash memory card used in the embodiment.

FIG. 3 is a view for explaining a data structure of management data stored in the flash memory card used in the same embodiment.

FIG. 4 is a view showing a data structure of a card management flag used in the same embodiment.

FIG. 5 is a view showing a data structure of card management information used in the embodiment.

FIG. 6 is an exemplary flowchart illustrating a procedure of read access processing according to the first embodiment.

FIG. 7 is an exemplary flowchart illustrating a procedure of write access processing according to the first embodiment.

FIG. 8 is an exemplary flowchart illustrating a procedure of block erase processing according to the first embodiment.

FIG. 9 is an exemplary flowchart showing a procedure of a card management flag generation process performed at card initialization in the embodiment.

FIG. 10 is an exemplary flowchart showing a procedure of a card management flag generation process performed when updating card management information in the embodiment.

FIG. 11 is an exemplary flowchart illustrating a card management procedure using a card management flag according to the first embodiment.

[Explanation of symbols]

11 ... Flash memory card, 12 ... Other PC card, 13 ... PC card host adapter, 14 ... Flash memory card driver, 15 ... Card service, 16
... socket service, 17 ... memory technology driver, 18 ... OS, 10 ... application program.

Claims (4)

[Claims] 1. A management method of a flash memory device having a flash EEPROM in which a spare block for replacing a defective block is prepared, the relationship between a defective block of the flash EEPROM and a spare block used for the replacement. Is read from the flash memory device, the card management information is rewritten every time a defective block is replaced by a spare block, and it is detected based on the result of the rewriting whether or not a spare block that can be replaced remains. A flash memory management method, wherein when it is detected that a spare block that can be replaced is exhausted, a procedure for extending the life of the flash memory device is performed before the failure of the flash memory device is caused by the inability to replace. . 2. A management method of a flash memory device having a flash EEPROM in which a spare block for replacing a defective block is prepared, wherein a relationship between a defective block of the flash EEPROM and a spare block used for its replacement is provided. Is read from the flash memory device, the card management information is rewritten every time a defective block is replaced by a spare block, and it is detected based on the result of the rewriting whether or not a spare block that can be replaced remains. A flash memory management method, wherein when it is detected that there is no substitute spare block, the access mode to the flash memory device is limited to read only. 3. A management method of a flash memory device having a flash EEPROM in which a spare block for replacing a defective block is prepared, the relationship between a defective block of the flash EEPROM and a spare block used for the replacement. Is read from the flash memory device, the card management information is rewritten every time a defective block is replaced by a spare block, and it is detected based on the result of the rewriting whether or not a spare block that can be replaced remains. A flash memory management method characterized in that, when it detects that there is no spare block that can be replaced, block replacement is prohibited, and instead, access right to a defective block that occurs subsequently is excluded. 4. A method of managing a flash memory device having a flash EEPROM in which a spare block for replacing a defective block is prepared, the relationship between a defective block of the flash EEPROM and a spare block used for the replacement. Is read from the flash memory device, the card management information is rewritten every time a defective block is replaced by a spare block, and it is detected based on the result of the rewriting whether or not a spare block that can be replaced remains. A flash memory management method, wherein when it is detected that there are no spare blocks that can be replaced, a block other than the spare block of the flash memory device is assigned as a spare block to increase the number of spare blocks.