(57)【特許請求の範囲】
【請求項１】
フラッシュメモリと該フラッシュメモリに対するデータの読み書きの制御を実行するコントローラを有するフラッシュメモリデバイスにおけるフラッシュメモリの管理方法であって、
物理ブロック毎のデータ読み出し回数と消去回数を、工場出荷時に物理ブロック番号ごとに異なるデータ読み出し回数のダミーデータを予め記録してなるリフレッシュ管理テーブルに随時記憶、更新するステップと、
物理ブロックのデータ読み出し回数が予め決定してなる閾値に至ったとき該物理ブロックにリフレッシュフラグを設定するステップと、
該リフレッシュフラグの設定された物理ブロックのデータを空きブロック若しくは予備ブロックにコピーしてから元のデータを消去してブロック管理テーブルを更新するステップと、
リフレッシュ管理テーブル上の当該物理ブロックのデータ読み出し回数を“０”に変更するステップ、
を有することを特徴とするフラッシュメモリの管理方法。
【請求項２】
前記閾値は、ベンダー指定値を下回る値に設定されてなることを特徴とする請求項１
記載のメモリの管理方法。
【請求項３】
前記閾値が、各物理ブロックの前記データ消去回数の所定の範囲ごとに異なる値に設定されてなることを特徴とする請求項２記載のメモリの管理方法。
【請求項４】
データ読み出し回数がベンダー指定値に近い順にリフレッシュを実行することを特徴とする請求項２乃至請求項３いずれか１項記載のメモリの管理方法。
【請求項５】
前記リフレッシュを、タイマーイベントとして実行することを特徴とする請求項１乃
至請求項４いずれか１項記載のメモリの管理方法。
【請求項６】
フラッシュメモリデバイスにメディアアクセスするホストがメディアアクセスを実行していないタイミングでコントローラにコマンドを発行し、リフレッシュを実行することを特徴とする請求項１乃至請求項４いずれか１項記載のメモリの管理方法。
【請求項７】
リフレッシュを実行すべき物理ブロックが複数存在する場合、一定のタイムインター
バルで該物理ブロックをそれぞれリフレッシュすることを特徴とする請求項１乃至請求項６いずれか１項記載のメモリの管理方法。
【請求項８】
物理ブロックごとの読み出し回数を毎日記憶しておくとともに、システム電源をオンしたときに、当該物理ブロックごとの読み出し回数の最大値又は平均値を求めて、当日にフラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、フラッシュメモリデバイスを搭載してなるシステムの本稼動前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項７いずれか１項記載の記メモリの管理方法。
【請求項９】
物理ブロックごとの読み出し回数を毎日記憶しておくとともに、システム稼動終了後、当該物理ブロックごとの読み出し回数の最大値又は平均値を求めて、翌日にフラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、フラッシュメモリデバイスを搭載してなるシステムの電源をOFFする前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項７いずれか１項記載のメモリの管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メモリ、取り分けNAND型フラッシュメモリの管理方法に関する。
【背景技術】
【０００２】
EEPROM（電気的にデータの消去及び書き換えが可能な不揮発性メモリ）の一種としてフラッシュメモリが知られている。フラッシュメモリは、ワード線とビット線の交点に位置するセルに電荷を蓄積し、データの書き込み（プログラムともいう）を行うメモリである。電荷がセルに蓄積されている以上、電源をOFFにしてもデータは失われない。しかしフラッシュメモリにおいては、リードディスターブエラー（read disturb error）といって、所定物理ブロックの所定ページのデータが読み出されると、同一ブロック内の他のページのセルに記憶されているデータが変化してしまう現象が生じる場合がある。これは、データの読み出し対象となった選択セルからデータが読み出される際、非選択セル（データ読み出し対象となっていないページのセル）の浮遊ゲートに電荷が注入されてしまい、これにより非選択セルが弱くプログラムされたのと同じ状態になるためであり、読み出し回数が増えるに従い、より多くのメモリセルが影響を受ける。このためフラッシメモリでは、通常、読み出し回数制限値がベンダーによって指定されている。例えば、現行製品で、SLC（Single-Level-Cell）では、１０万回乃至１００万回、MLC（Multi-Level-Cell）では、１万回乃至１０万回である。一般に、データ書き換え回数が増大すると、読み出し回数はより制限される。
【０００３】
（従来技術の問題点）
このリードディスターブエラーに対処するため、該エラーが生じない特別な回路を予め用意したり、電荷の変化したセル単体を個別に探し出してこれを補正しエラーデータが読み出されないようにする方法などが提案されているが、回路や処理が複雑で高価となり、実用的ではない。
【０００４】
また、他の対処方法としては、物理ブロックごとにデータ読み出し回数をカウントし、ベンダー指定のデータ読み出し回数制限値に至ったときにそのブロックのリフレッシュを都度実行している。即ち、読み出し対象となった当該ブロックがデータ読み出し回数制限に至ったとき、データ読み出しの直前又は直後にリフレッシュを実行している。このため、複数の物理ブロックが一度にデータ読み出し制限に至ったとき、連続したリフレッシュ実行のために一定のデータ転送レートが保証できずユーザに不快感を与えたり、ホストに読み出されるデータが一時的に中断しプレイに支障が生じるといった問題が生じる。
【特許文献１】特開１０−２２８７８３
【特許文献２】特開２００２−１５０７８３
【特許文献３】特開２００４−３２６８６７
【特許文献４】特許第３６４１０６６号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、このような問題点に鑑みてなされたものであり、NAND型フラッシュメモリデバイスのリードディスターブエラーを有効に防止し得るメモリの管理方法を提供することにある。その他の目的は、明細書、図面、特に特許請求の範囲から自ずと明らかとなろう。
【課題を解決するための手段】
【０００６】
上記課題解決のため、本発明は、請求項記載の新規な特徴的構成を採用する。
【発明を実施するための最良の形態】
【０００７】
以下、本発明を実施するための最良の形態について図面を用いて説明するが、本発明は特許請求の範囲内において種々の形態を採ることができ、下記実施形態に限定されないことはいうまでもない。
【０００８】
（システム基本構成）
図１に示すように、本発明は、NAND型フラッシュメモリ２２（本明細書において、特に必要のない限り、単に“フラッシュメモリ”という）と該フラッシュメモリ２２に対するデータの書き込みや読み出しの実行、その他の制御を行うコントローラ２１を有するフラッシュメモリデバイス２（特許請求の範囲の「記憶装置」に相当）において実行される。本願では、フラッシュメモリデバイス２と、該デバイス２にデータの書き込みや読み出しのコマンドを発行するホスト１からなる構成をシステムという。コントローラ２１には、必要に応じ作業領域としてのRAM２３を接続する。RAM２３はコントローラ２１の内部に設けてもよい。システムは、例えばMPEG音楽プレーヤのように、所定の機器として一体に構成されていてもよいし、ホスト１がPC（パーソナルコンピュータ）で構成され、フラッシュメモリデバイス２がSSD（Solid State Drive）としてPCとUSBインターフェースやIDEインターフェースで接続される構成であってもよい。その他、遊技機等所定の機器に搭載される基板上に構成されてもよい。
【０００９】
フラッシュメモリ２２は、ユーザデータ領域、予備領域、管理領域を有する。ユーザデータ領域は、主記憶領域とも呼ばれる。ユーザデータ領域を構成する物理ブロックは、論理ブロックと対応する関係を有し、その関係は論理／物理ブロック管理テーブルで管理され、その対応関係が変わると、随時該テーブルで更新される。予備ブロック（予備領域を構成するブロック）は、ユーザデータ領域を構成する物理ブロックがｂａｄブロックとなったときに使用される代替ブロックである。また、フラッシュメモリ２２には空きブロックが少なくとも一つ確保される。この空きブロックは、通常、ユーザデータ領域の物理ブロックにデータを上書きするときに使用されるブロックである。この場合空きブロックは、予備ブロック同様、論理ブロックアドレスと関連付けされない。なお、詳細は後述するが、本願のリフレッシュは、この空きブロック若しくは予備ブロックのいずれかを使用して実行する。
【００１０】
図２は、フラッシュメモリ２２のメモリアレイを示している。図示するように、ユーザデータ領域は物理ブロック番号“０”から“４０４１”で構成され、物理ブロック番号“４０４２”が空きブロック、物理ブロック番号“４０４３”から“４０９１”までが予備ブロックで構成されている。その他、物理ブロック番号“４０９２”から“４０９５”までの管理領域が存在する。コントローラ１１は、空きブロックの物理ブロック番号及び予備ブロックの物理ブロック番号を把握するため、それぞれ不図示の空きブロック管理テーブル、予備ブロック管理テーブルで管理する。論理／物理ブロック管理テーブル、空きブロック管理テーブル、予備ブロック管理テーブルを総称して、ブロック管理テーブルというものとする。
【００１１】
図３はリフレッシュ管理テーブルの内容例を表している。リフレッシュ管理テーブルは、システム稼動中RAM２３において、物理ブロックごとのデータ読み出し回数や消去回数を記憶するものである。システム稼動中はその内容が適宜更新される。システムの電源が遮断されるとき、その内容は管理領域に保存される。システム稼動の度にこれが繰り返される。
【００１２】
フラッシュメモリデバイス２がホスト１からデータ読み出しコマンドを受けると、コントローラ２１は、ホスト１から指定されたアドレスを論理ブロックアドレスとして、その論理ブロックアドレスに対応する物理ブロックアドレスを論理／物理ブロック管理テーブルから割り出してデータを読み出す。そしてその都度、リフレッシュ管理テーブルに、当該物理ブロックに対するデータ読み出し回数を記録する（図３参照）。また、物理ブロックのデータを消去するごとに消去回数をインクリメントして記録する。尚、消去はそのブロック内のデータの書き換えを含む概念である。
【００１３】
物理ブロックのデータ読み出し回数制限値（図４のベンダー指定値）は、一般に過去の消去回数に依存する。即ち、過去にデータ消去された回数が多いほど、読み出し回数は制限される。このデータ読み出し回数制限値は、例えば図４に示すように、物理ブロックの消去回数が０回から９９９回までは１,０００,０００回（図４のフェーズＡ）、消去回数が１,０００回から９,９９９回までは３００,０００回（図４のフェーズＢ）、消去回数が１００００回から９９,９９９回までは１００,０００回（図４のフェーズＣ）と設定される。
【００１４】
従来、そのブロックのデータ読み出し回数が制限値に至ったとときに、読み出しを実行する直前又は直後に、その都度リフレッシュを実行していたが、read時間が増大するという問題があった。そこで本発明では、リフレッシュ管理テーブルを用い、後述する方法により、対象となるブロックを時分割に一括してリフレッシュし、read時間の増大を防止するものである。
【００１５】
まず、リフレッシュを実行する基準（コントローラ閾値）をベンダー指定値より小さい値に設定することにより、データ読み出し回数がベンダー指定値に至る前に有効にリフレッシュを実行できるようにした。図４のフェーズＡ，Ｂ，Ｃのベンダー指定値とコントローラ閾値の関係を参照されたい。データ読み出し回数が、コントローラ閾値に至ると、コントローラ２１（正確にはコントローラ２１のCPU（図示せず））は、リフレッシュ管理テーブルの当該物理ブロックにリフレッシュフラグを設定する（図３の“１”）。
【００１６】
システムの電源が遮断される際は、リフレッシュ管理テーブルの内容を管理領域に不揮発的に記録し、次回システム稼動時に再度RAM２３に展開し、過去の記録を利用する。システム稼動中に何らかの理由により電源が遮断される可能性があるので、所定時間間隔ごとに（例えば１０分おき）、リフレッシュ管理テーブルの内容を、管理領域に記録してもよい。
【００１７】
以下、本発明のリフレッシュ方法の実施形態例を説明する。
（第1実施例：オートリフレッシュ）
オートリフレッシュは、デバイス２に電源投入直後、ホスト１よりコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンド（デバイス提供者で定義するユニークコマンド。以下、単にオートリフレッシュコマンドという。）を発行しておき、所定時刻及び／又は所定時間間隔にリフレッシュを実行させる方法である。デバイス２に定常的に電源が投入されているようなシステムの場合は、所定時刻ごと（秒単位で設定可能）にリフレッシュを実行してもよい。またはコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンドで実行すると同様なプログラム（ファームウエア）を予めインストールしておいてもよい。これらオートリフレッシュは、フラッシュメモリデバイス２が有するタイマー（図示せず）を利用して自動的にリフレッシュを実行する方法であるため、本願では以下、タイマーイベントという。オートリフレッシュの場合、特許請求の範囲のステップｄ）、ｅ）、ｆ）がタイマーイベントで実行される。
【００１８】
Ａ.リフレッシュフラグの設定されている物理ブロックが一つだけ存在する場合
オートリフレッシュコマンドまたはファームウエアにより、タイマーイベントが、ホスト１がメディアアクセスをしていないときに発生した場合は、コントローラ２１はリフレッシュ管理テーブルをサーチし、リフレッシュフラグが設定されている物理ブロックが一つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックのリフレッシュを直ちに実行する。メディアアクセスとは、ホストがコマンドを発行することにより、フラッシュメモリ２２からデータの読み出しや、データの書き込みを行うことをいう。
【００１９】
タイマーイベントが、ホスト１がメディアアクセスしているときに発生した場合は、一の物理ブロックに対するメディアアクセスの処理を完了し次のメディアアクセスの処理開始前に割り込んでリフレッシュを実行する。
【００２０】
Ｂ.リフレッシュフラグの設定されている物理ブロックが二つ以上存在する場合
タイマーイベントが、ホスト１がメディアアクセスを実行していないときに発生した場合であって、リフレッシュ管理テーブルでリフレッシュフラグが設定されている物理ブロックが二つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックを一つずつ、即ち、ブロック単位でリフレッシュする。まずデータ消去回数が、図４のフェーズＡ，Ｂ，Ｃのいずれに該当するかを判定し、データ読み出し回数がそれぞれの閾値（コントローラ閾値）を超えた値が大きいもの順にリフレッシュを実行する。又は、データ読み出し回数がベンダー指定値に近いもの順にリフレッシュを実行する。図４では、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差がすべて同じであるため、上記２例において実質的に同一の結果となるが、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差を異なる値に設定した場合は、前者の実行方法を採った場合と後者の実行方法を採った場合とではリフレッシュの順番が異なる。このような方法を採ることにより、リードディスターブエラーを生起する可能性の高い順番で物理ブロックがリフレッシュされるため、リードディスターブエラーの発生をより確実に防止することができる。
【００２１】
Ｃ.タイマーイベントが、ホスト１がメディアアクセスしているときに発生した場合、若しくはホスト１のメディアアクセス中にタイマーイベントが発生した場合であって、リフレッシュフラグの設定されている物理ブロックが複数存在することが確認された場合。
この場合は、物理ブロック単位で、時分割にリフレッシュを実行する。即ち１物理ブロック当たりのタイマーイベントの処理は、その開始から終了までせいぜい１００ｍｓ（ミリ秒）程度であるから、リフレッシュ間隔（一の物理ブロックのリフレッシュ開始から次の物理ブロックのリフレッシュ開始まで）を、例えば１秒以上に設定する。そしてコントローラ２１は、まず一の物理ブロックに対するメディアアクセスの処理の完了後、次のブロックのメディアアクセスの処理開始前に割り込んで１物理ブロックのリフレッシュを実行する。その後1秒経過してから同様なタイミングで次の物理ブロックのリフレッシュを実行する。
【００２２】
このようにすれば、リフレッシュ対象ブロックが複数存在する場合でも、ホスト１にデータを転送している最中にデータが途切れてユーザに不快感を与えたり、プレイに支障を生じさせることがない。特に、フラッシュメモリ２２に記憶されているデータが音楽や動画などのコンテンツであって、多数の物理ブロックが一度にコントローラ閾値に達するような事態が生じても、物理ブロックごと時分割にリフレッシュを実行することにより、一定のデータ転送レートを担保することができ、ユーザに支障を来たすことがない。
【００２３】
以下、図を用いて、リフレッシュフラグの設定された物理ブロックに対するリフレッシュのやり方について説明する。
【００２４】
図３に示す通り、リフレッシュフラグの設定されている物理ブロックが、物理ブロック番号“２”、“６”及び“９９９９”の三つあるとする。データ消去回数は、物理ブロック番号“２”も物理ブロック番号“６”もどちらも０回で、フェーズＡに該当する。データ読み出し回数は、物理ブロック番号“２”は990,100回、物理ブロック番号“６”は990、515回であり、コントローラ閾値990,000に対して、物理ブロック番号“６”が、より閾値を超えているため、リフレッシュは物理ブロック番号“６”が、物理ブロック番号“２”に優先する。また物理ブロック番号“９９９９”のデータ消去回数は1050回であるためフェーズＢに該当し、コントローラ閾値290,000に対して読み出し回数が290,050回であり、コントローラ閾値を越える回数は、物理ブロック番号“２”より少ないから、リフレッシュは物理ブロック番号“２”が優先する。以上より、物理ブロック番号“６”、“２”、“９９９９”の順にリフレッシュを実行することになる。
【００２５】
物理ブロック番号“６”のリフレッシュに当たっては、まず空きブロック（物理ブロック番号“４０４２”）を新たなデータ書き込み用のブロックとして選定する。次にリフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつフラッシュメモリ２２内のバッファにすべてのデータを読み出し、続いてバッファから前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）する。そして元のブロックである物理ブロック番号“６”のデータを一括消去する（図５参照）。１ブロック分のデータすべてを読み出してから新たなデータ書き込み用ブロックへ書き込むのではなく、バッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよい。この場合、バッファの容量は１ページ分で足りる。  
【００２６】
そして、元の物理ブロックである物理ブロック番号“６”に対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４２”）に新たに対応させて、論理/物理ブロック管理テーブルを更新するとともに、物理ブロック番号“６”を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。また、リフレッシュ管理テーブル上で、消去した元のブロックである物理ブロック番号“６”のデータ読み出し回数をゼロに変更し、データ消去回数を1つインクリメントする。以上で物理ブロック番号“６”に対するリフレッシュが完了する。物理ブロック番号“６”のリフレッシュが終了したら、以降、物理ブロック番号“２”、”９９９９”についても、上記例に倣ってリフレッシュを実行する。なお新たなデータ書き込み用のブロックは、予備ブロックの一つ(例えば、物理ブロック番号“４０４３”)から選定してもよい。この場合は、元の物理ブロックである物理ブロック番号に対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４３”）に新たに対応させて、論理／物理ブロック管理テーブルを更新するとともに、元の物理ブロック番号を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。
【００２７】
尚、必ずしもホスト１への高速なデータ転送が要求されない場合は、リフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつエラー訂正しながらRAM２３（リフレッシュ管理テーブルを記録する領域意外の領域を利用）にすべてのデータを読み出して格納し、続いてRAM２３から前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）してもよい。こうすれば、ブロックの潜在的なエラーをすべて訂正するので、データの信頼性が高まる。この場合もバッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよいことは言うまでもない。
【００２８】
従来リフレッシュは、データの読み出し中にイレギュラーに必要となり、ホストへのデータのread時間が増大していたが、本発明では、リフレッシュ管理テーブルを用いて、所定のタイミングで一括して行うので、斯かる不都合は生じない。また従来のリフレッシュのやり方は、１）その物理ブロックのデータをフラッシュメモリ２２内のバッファに待避し、次に２）当該ブロックのデータを消去し、その後３）待避しておいたデータを元のブロックに再書き込みしている。この場合、当該ブロックのデータを消去した後であってかつバッファに待避しておいたデータを元のブロックに再書き込み完了する前に何らかの原因で電源が遮断された場合、本来のデータが消失してしまう危険性がある。この点、上記実施形態例によれば、新たなデータ書き込み用ブロックにデータが完全にコピーされるまで、元のブロックのデータは消去されないから、リフレッシュ中のどの段階で電源が遮断されても本来のデータが失われることがない。尚本発明においても、上記１）乃至３）のやり方でリフレッシュしてもよいことは言うまでもない。その場合は元のブロックを再利用するので、ブロック管理テーブルのいずれも変更しなくてよい。
【００２９】
（第２実施例:ホストからのコマンド発行によるリフレッシュ）
上述のオートリフレッシュの他、メディアアクセスを実行しないときに、ホスト１がコントローラ２１に以下のようなコマンドを発行してリフレッシュを実行してもよい。
１．GET REFRESH PENDING STATUS コマンド
本コマンドは、コントローラ２１に対し、リフレッシュ管理テーブルをサーチさせて、
リフレッシュフラグが設定されている物理ブロックの総数をホスト１に通知させるものである。
２．EXECUTE
REFRESH コマンド  
本コマンドは、コントローラ２１にリフレッシュを実行させるものである。リフレッ
シュが終了するとコマンドが終了する。リフレッシュを実行する物理ブロック数を指定できる。
３．SAVE
REFRESH TABLE コマンド
本コマンドは、コントローラ２１に、RAM２３上のリフレッシュ管理テーブルの内容
を、管理領域に保存させるものである。リフレッシュ管理テーブルの保存が終了するとコマンドが終了する。
【００３０】
ホスト１のドライバには、GET REFRESH PENDING STATUS コマンドを発行して、リフレッシュの必要なブロックの有無及びその数を把握し、リフレッシュの必要なブロックがあれば、ホスト１がメディアアクセスしていないときにコントローラ２１にEXECUTE REFRESHコマンドを発行するようプログラムしておく。
【００３１】
このようにすれば、ホスト１は必要に応じて適宜コントローラ２１にリフレッシュを実行させることができる。即ち、コントローラ２１は、必要なときにのみ、効果的にリフレッシュを実行することができる。またSAVE REFRESH TABLE コマンドにより、必要に応じ、コントローラ２１にRAM２３上のリフレッシュ管理テーブルの内容をフラッシュメモリのリフレッシュ管理テーブルに不揮発的に保存させることができる。
【００３２】
以上のように、本発明は上記第１実施例、第２実施例のいずれのリフレッシュ方法を採用しても、リフレッシュを実行すべき物理ブロックが複数存在する場合、一定のタイムインターバルを以って複数の物理ブロックを時分割でリフレッシュするため、音楽や動画などのコンテンツの読み出しが途中で途切れ、ユーザに不快感を与えたり、プレイに支障を生じることがない。また、メディアアクセスする必要のないタイミングに上記ベンダーコマンドを発行するようホスト１のドライバにプログラムしておくことにより、コントローラ２１の動作効率をより向上させることができる。
【００３３】
また上記第２実施例（ホストからのコマンド発行によるリフレッシュ）において、コントローラ２１がリフレッシュの実行中にさらにホスト１からメディアアクセスコマンドが発行された場合であって、その時点でリフレッシュを完了していない物理ブロックが複数存在する場合は、メディアアクセスコマンドを優先して、前述した方法（段落００２１参照）で、ブロック単位で時分割にリフレッシュを実行すればよい。
【００３４】
（ｂｉｔエラーの対応及びｂａｄブロックの処理）
フラッシュメモリデバイスは、データ書き込みの際、ユーザデータに対してエラーチェックコード（ECC）を付加して書き込んでいる。データ読み出し時にはデコーダがこのエラーチェックコードを基に、読み出したデータにエラー（本願ではこれを「ｂｉｔエラー」という）がないかをチェックし、ｂｉｔエラー数がコントローラの能力値（例えば８ｂｉｔ）以内であれば、コントローラ２１内のエラー訂正回路（図示せず）がｂｉｔエラーを訂正し、正しいデータをホスト１に送出する。ｂｉｔエラーは、データの消去、リードディリスターブ、経年変化（データリテンション）、セルの物理的欠陥（たとえば絶縁膜の劣化、破壊）などに起因して生じる。ｂｉｔエラー数がコントローラ能力値を超えると、その欠陥セルを含むブロックは、もはやエラー訂正ができず、使用に耐えないｂａｄブロックとなる。
【００３５】
そこで本発明では、安全性を担保するため、コントローラ２１の能力値と同じかそれより小さい所定値（例えば７ｂｉｔ）を予め閾値（「ｂａｄブロック閾値」という）として設定しておき、ｂｉｔエラーがｂａｄブロック閾値に至ったセルを含むブロックをｂａｄブロックと看做し、お蔵入りとするものである（本願では「ｂａｄブロック処理」という）。
【００３６】
以下、ｂａｄブロック処理を簡単に説明する。まず、読み出したデータのｂｉｔエラー数がｂａｄブロック閾値未満であったときは、通常通り、ｂｉｔエラーを訂正してデータをホスト１に送出する。ｂｉｔエラーがｂａｄブロック閾値以上かつコントローラの能力値以下であったときも、通常通りｂｉｔエラーを訂正してデータをホスト１に送出する。そして、予備ブロック（ここでは物理ブロック番号“４０４４”）を新たなデータ書き込み用ブロックに割り当てる。次にｂａｄブロックと看做された物理ブロックの全データを１ページずつエラー訂正しながらRAM２３に一旦格納し、前記予備ブロックに書き込む。尚ｂａｄブロックと看做された物理ブロックの全データをフラッシュメモリ内２２のバッファに読み出して、エラー訂正することなく予備ブロックに書き込んでもよいが、エラー訂正して書き込む方がデータの信頼性が高まる。データの書き込み処理が完了したら、元の物理ブロックの論理ブロック番号と予備ブロックの物理ブロック番号“４０４４”を新たに対応させて、論理／物理ブロック管理テーブルを更新する。このとき元のブロックの物理ブロック番号がブロック管理テーブルから削除されるので、元の物理ブロックは以降使用されることはない。また、元ブロックは以降使用しないので、該ブロックに記憶されているデータは消去しなくてよい。
【００３７】
尚、万一ｂｉｔエラー数がコントローラ能力値を超えた場合は、エラー訂正ができないため、コントローラ２１はホスト１にエラーを返すことになるが、ｂａｄブロックと看做すための前記ｂａｄブロック閾値を、アプリケーションや使用環境に応じて適切な値に設定することにより、斯かる事態の発生を防ぐことができる。
【００３８】
以下、コントローラ２１がホスト１からコマンドを発行された場合の処理（リフレッシュコマンドに基づきリフレッシュを行う場合の例）を、図７乃至図９のフローチャートを用いて説明する。はじめに図７を用いて説明する。コントローラ２１は常時ホスト１からコマンドが発行されたかを確認する（SP１）。コマンドが発行された場合、その発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドか確認し（SP２）、ｙｅｓの場合は、当該コマンドを実行し（SP３）、リフレッシュ管理テーブルの当該コマンドが実行された物理ブロックの“消去回数”を１つインクリメントする（SP４）。初期値は０である。発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドでない場合は、引き続きデータの読み出しコマンドであるか確認し（SP５）、ｙｅｓの場合は※１（図８）へ進む。即ち、コマンドに従ってデータの読み出しを実行し（SP６）、データを読み出したページを含む物理ブロックの“読み出し回数”を一つインクリメントする。そして、そのブロックに係る読み出し回数がコントローラ閾値以上であるか確認し（SP８）、ｙｅｓであれば、リフレッシュ管理テーブルにリフレッシュフラグを設定する（SP９）。そして読み出したデータにｂｉｔエラーがないか確認し（SP１０）、ない場合はデータをそのままホストに送出する（SP１１）。ｂｉｔエラーがあった場合は，ｂａｄブロック閾値未満であるか確認し（SP１２）、ｙｅｓであればエラー訂正した上で（SP１３）、データをホストに送出する。ｂｉｔエラーがｂａｄブロック閾値以上であった場合はコントローラ能力値以下であるかを確認し（SP１４）、ｙｅｓであればエラー訂正して（SP１５）からホスト１に送出する（SP１１）。そしてエラーのあったブロックのｂａｄブロック処理を行う（SP１６）。仮にｂｉｔエラーがコントローラ能力値を超えていた場合はホストにエラーを返し（SP１７）、※３（図８参照）に進む。
【００３９】
SP５でnoであった場合は、※２へ進む（図９参照）。即ち、ホストから発行されたコマンドがリフレッシュコマンドであるか確認し（SP１８）、noであれば当該処理を実行して（SP１９）、※３に進む。ｙｅｓであればリフレッシュ管理テーブルをサーチし（SP２０）、リフレッシュフラグが設定されているかを確認する（SP２１）。そしてｙｅｓであれば、リフレッシュを実行する（SP２２）。そして、論理/物理ブロック管理テーブルを更新し（SP２３）、※３へと進む。
【００４０】
以上のように、上記実施形態例では、リードディスターブエラー発生を未然に防止するので、従来にはないシステムパフォーマンスを提供することができる。
【００４１】
尚、RAM２３は、コントローラ２１に外付けする場合、Random Access Memoryの他、DRAM、SDRAM（synchronous DRAM）でもよい。
【００４２】
また、図６に示ように、リフレッシュ管理テーブルは、工場出荷時に物理ブロックごとに異なるデータ読み出し回数（ダミーデータ）を記録しておいてもよい。このようにすれば、専らシーケンシャルリード（sequential read）されるアプリケーションの場合、リフレッシュをさらに分散して実行することができる。
【００４３】
また、本システムが弾球遊戯機に搭載される場合、一日のプレイ中に何度もコンテンツデータが読み出される。コンテンツは例えば、図柄である。このコンテンツデータは複数の物理ブロックに跨ってファイルとして管理されている場合もある（これをコンテンツファイルという）。この場合、一日における当該図柄の読み出し回数を記憶しておくとともに、システム電源をオンしたときに、一日における当該図柄の読み出し回数の最大値や毎日の平均値を求め、当日にリフレッシュフラグが設定され得る状況であるかを予想し、設定される可能性がある場合は、システム本稼動前にリフレッシュを前倒しで実行してもよい(フィードフォワード制御)。或いは、システム稼動終了後に翌日にリフレッシュフラグが設定されるかを予想し、設定される可能性がある場合、電源OFF前にリフレッシュを実行してもよい。このようにすれば、プレイ途中のリフレッシュを極力少なくすることができ、システムパフォーマンスを一層向上させることができる。パチンコ遊技機やスロットマシンのように、一日中稼動する遊技機の場合は特に有効である。
【００４４】
以上説明したように、本発明は、リフレッシュをデータ読み出し回数制限値（ベンダー閾値）に至る前に実行するとともに、且つ、リフレッシュ管理テーブルを使用して集中して行うので、リードディステーブエラーを有効且つ効率的に防止することができる。ホストからの継続したデータ読み出し要求がなされた場合でも一定のタイムインターバルで時分割にリフレッシュを実行するので、データ転送レートを保証でき、ユーザに不快感を与えたり、ホストに転送されるデータが一時的に中断しプレイに支障が生じることを防止することができる。ホストがメディアアクセスしないときにコマンドを発行してリフレッシュを実行する場合は、データ転送レートをより一層保証することができる。
【図面の簡単な説明】
【００４５】
【図１】本発明の実施形態を実行するシステムの基本構成例である。
【図２】フラッシュメモリの領域例である。
【図３】リフレッシュ管理テーブルの内容例である。
【図４】データ消去回数範囲（フェーズ）ごとの、データ読み出し回数のベンダー指定値及びコントローラ閾値の関係例である。
【図５】リフレッシュの実行方法例である。
【図６】工場出荷時（初期状態）のリフレッシュ管理テーブル例である。
【図７】コントローラが実行する処理のフローチャート例である。
【図８】コントローラが実行する処理のフローチャート例（続き）である。
【図９】コントローラが実行する処理のフローチャート例（続き）である。
【符号の説明】
【００４６】
１  ホスト
２  フラッシュメモリデバイス
２１  コントローラ
２２  NAND型フラッシュメモリ
２３  RAM
【図１】
0004377950.tif 000002
【図２】
0004377950.tif 000003
【図３】
0004377950.tif 000004
【図４】
0004377950.tif 000005
【図５】
0004377950.tif 000006
【図６】
0004377950.tif 000007
【図７】
0004377950.tif 000008
【図８】
0004377950.tif 000009
【図９】
0004377950.tif 000010