以下、図面を参照して本発明の一実施形態を説明する。図1は本発明の一実施形態に係るメモリカードの全体構成を示すブロック図である。
図1のメモリカードは、例えばパーソナルコンピュータ、電子カメラ、ゲーム機を始めとする各種電子機器に装着して使用されるもので、ホストインタフェース11と、コントローラ12と、ROM13と、RAM14と、書き換え可能な不揮発性メモリ、例えばフラッシュメモリ15とを備えている。
ホストインタフェース11は、上記メモリカードが装着される電子機器本体(以下、ホストデバイスと称する)とのインタフェースをなす。コントローラ12は、カード全体の制御を司るもので、マイクロプロセッサ(MPU)121と、レジスタ(REG)122とを有している。上記マイクロプロセッサ121は、ホストインタフェース11を介して受信されるコマンドをROM13に格納されている制御プログラム(ファームウェア)に従って解釈して実行する。
ROM13は、読み出し専用の不揮発性メモリである。ROM13は、上記制御プログラム、及び管理用の固定データ等を予め格納するのに用いられる。RAM14は、揮発性メモリであり、コントローラ12の作業用領域141の他、ブロック使用管理テーブル142、エラー管理テーブル143、書き込みデータバッファ144等が設けられる。上記ブロック使用管理テーブル142は、図2に示すようにフラッシュメモリ15の各ブロックに対し、それぞれ未使用状態と使用又は不良ブロック状態を記憶してブロックの使用状態を管理する。上記ブロック使用管理テーブル142は、図3(a)に示すようにフラッシュメモリ15の各ブロックが未使用の場合には、各ブロックに対して“1”が書き込まれている。そして、ブロック単位でデータの書き込みが行なわれると、図3(b)に示すように“1”が“0”に書き換えられ、そのブロックが使用状態であることが示される。また、不良ブロックに対しても“0”が書き込まれ、その後の使用が禁止される。
また、上記エラー管理テーブル143は、マルチプルライト処理の場合に使用されるもので、データ書き込みの際にエラーが発生すると、不良データとして登録される。
フラッシュメモリ15の各ブロックは、一定サイズの複数のセクタから構成される。また、フラッシュメモリ15の領域は、システム管理情報等が保存される管理領域151と、画像データ、音楽データ等のデジタルコンテンツを保存するデータ領域152からなっている。管理領域151には、データ領域152に保存されているディジタルコンテンツを使用するのに必要な、コンテンツ復号キー、コピー制御情報、移動制御情報等の重要な情報が保存されている。
次に上記メモリカードに対するデータ書き込み処理について説明する。最初に、シングルライト処理について、図4に示すフローチャートを参照して説明する。コントローラ12は、ホストデバイスからの指令に従ってシングルライト処理を行なう場合、まず、書き込みアドレスを計算する(ステップA1)。すなわち、ブロック使用管理テーブル142に書き込まれているブロック使用管理データを参照して書き込み可能な領域を見つける。この場合、不良ブロックは使用済みとして管理されているので、再度利用することはない。
そして、上記書き込みアドレスに対してデータの書き込みを行なう(ステップA2)。この場合、ホストデバイスから送られてくるデータをRAM14の書き込みデータバッファ144にブロック単位で保持し、上記書き込みアドレスに対して書き込みを行なう。その後、ライトステータス、つまり、データ書き込みの処理ステータスが正常か否かを判別する(ステップA3)。
上記ステップA3で、異常ステータスが見つかっても不良ブロックをブロック使用管理テーブル142に直ちに登録することはしない。すなわち、上記ステップA3で、ライトステータスが異常であると判定された場合には、先行状態が異常であるとし(ステップA4)、リトライを継続するか終了するかをリトライ回数から判別する(ステップA5)。このステップA5では、予め設定されたリトライ回数に達したか否かによってリトライを継続するか終了するかを判別し、リトライ回数が設定値に達していなければ、ステップA1に戻り、異なるブロックを見つけてデータの再書き込みを行なう。上記ステップA5で、リトライ回数が設定値に達したと判定された場合には、ステップA6に進んでエラー終了とし、シングルライト処理を終了する。
また、上記ステップA3でライトステータスが正常であると判定された場合には、上記のデータ書き込みがリトライ処理であるか否かを判別し(ステップA7)、リトライ処理であった場合には、先行状態、つまり、前回の書き込みが正常か否かを判別する(ステップA8)。書き込み異常の場合には、不良データと判断し、前回のライト時に利用したアドレスを不良ブロックとし(ステップA9)、ステップA10で先行状態を正常にした後、ブロック使用管理テーブル142を更新する(ステップA11)。例えば図3(a)に示すようにブロック使用管理テーブル142が全て未使用状態となっているとき、最初のデータ書き込みがエラーとなってリトライ処理を行ない、その結果、データを正しく書けた場合には、図3(b)に示すように、そのブロックに対する管理データを“0”に書き換えて使用状態とすると共に、その1つ前に書き込みを行なったブロックを不良ブロックとして“0”に書き換える。
また、上記のようにリトライ処理によってデータの書き込みが正常に行なわれた場合において、図3(c)に示すように1つ前のブロックが既に使用状態となっており、その前のブロックが前回書き込みを行なったブロックであった場合には、図3(d)に示すように正常に書き込みができた今回のブロックに“0”を書き込むと共に、前回書き込みを行なった2つ前のブロックを不良ブロックとして“0”を書き込む。
また、上記ステップA7でリトライ処理ではないと判定された場合、あるいはステップA8で先行状態が正常であると判定された場合には、ステップA10で先行状態を正常にした後、ブロック使用管理テーブル142を更新する(ステップA11)。この場合には、データの書き込みが正常に行なわれたブロックに対して“0”を書き込んで使用状態とする。
その後、正常終了(ステップA12)としてシングルライト処理を終了する。
上記のようにシングルライトにおいては、データ書き込みを行なった際にエラーが発生してもブロック使用管理テーブル142に不良ブロックの登録は行なわず、その後、リトライ処理によって正常に処理を終了した場合に、前回の書き込み時に利用したアドレスを不良ブロックとしてブロック使用管理テーブル142を更新するようにしているので、メモリ自身の要因によってエラーが発生した場合のみブロック使用管理テーブル142が更新される。従って、システム的な要因によるエラーの場合には、ブロック使用管理テーブル142が更新されることはなく、リトライを繰り返して実施した場合においても、再書き込み実施試行分の不良ブロック判定を回避することが可能であり、不揮発性メモリの寿命が短くなることを確実に防止することができる。
次に、マルチプルライトによるデータ書き込み処理について図5に示すフローチャートを参照して説明する。
ホストデバイスからマルチプルライトによる書き込みが指示されると、コントローラ12は、まず、ブロック使用管理テーブル142に書き込まれている管理データを利用して、フラッシュメモリ15の書き込み可能な空きブロックを選択し(ステップB1)、この空きブロックに対してデータの書き込みを行なう(ステップB2)。この場合、ホストデバイスから送られてくるデータがRAM14の書き込みデータバッファ144に順次書き込まれ、このデータが上記空きブロックに書き込まれる。その後、ライトステータス、つまり、データ書き込みの処理ステータスが正常か否かを判別する(ステップB3)。
上記ステップB3で、ライトステータスが異常であると判定された場合には、先行状態が異常であるとし、エラーデータをRAM14のエラー管理テーブル143に登録する(ステップB4)。書き込みエラーが発生した場合、コントローラ12からホストインタフェース11を介してホストデバイスに書き込みエラーの発生を示すデータが送られる。これによりホストデバイスから再書き込み要求が指示される(ステップB5)。
コントローラ12は、再書き込み要求により、エラー管理テーブル143を参照して他の空きブロックの選択動作を行ない(ステップB6)、その空きブロックに対してリトライ処理を行なう(ステップB7)。すなわち、ホストデバイスから送られてくるデータを書き込みデータバッファ144に順次保持し、上空きブロックへの書き込みを行なう。
そして、上記リトライ処理に対してデータの書き込みが正常に行なわれたか否かを判別し(ステップB8)、書き込み異常が発生した場合にはステップB5に戻り、上記した処理を繰り返して実行する。
また、上記ステップB8で正常に書き込み処理を終了したと判定された場合には、上記エラー管理テーブル143に登録されているエラー管理データをクリアすると共にブロック使用管理テーブル142を更新し(ステップB9)、正常終了(ステップB10)としてマルチプルライト処理を終了する。
マルチプルライト時にエラーが発生した場合、RAM14の書き込みデータバッファ144には書き込みデータの一部しか保持されていない。このため書き込みデータバッファ144の保持データに基づくリトライを実施することができず、上記シングルライトの場合のようにリトライによって正常に書き込みができたという行為によって1つ前に書き込みを行なったブロックを不良ブロックであると判断することはできない。また、ホストデバイスからの書き込み再要求によって再度不良ブロック化できない事態が考えられる。
このため本発明によるマルチプルライト処理においては、上記したように書き込みエラーを発生したブロックについてエラー管理テーブル143に登録し、ブロック使用管理テーブル142とは別管理にする。その後、ホストデバイスからの再書き込み要求により、上記エラー管理テーブル143に登録されたエラー管理データに基づいて空きブロックを選択することでリトライ動作を可能としている。そして、リトライ動作が正しく実施されたことで上記エラー管理テーブル143に登録されているエラー管理データをクリアする。
上記マルチプルライトの場合には、エラーが発生した場合、そのエラーがメモリ自身の要因であるか、システム的な要因に起因するものか判断できないので、ブロック使用管理テーブル142の更新は行なわない。このようにエラーが発生したと判断されたブロックをそのまま未使用領域として残しておいても、その後、図5で説明したシングルライト処理において、そのエラーがメモリ自身の要因であるか、システム的な要因に起因するものかを判断できるので問題はない。上記したようにマルチプルライト処理の場合には、エラーが発生してもブロック使用管理テーブル142が更新されることはなく、不揮発性メモリの寿命が短くなることを確実に防止することができる。
なお、上記実施形態では、不揮発性メモリを備えたメモリカードに実施した場合について説明したが、その他、例えばコンピュータが内蔵する不揮発性メモリに対しても、上記実施形態と同様にして実施し得るものである。
以上詳記したように本発明によれば、シングルライト処理により不揮発性メモリへデータ書き込みを行なった際にエラーが発生しても不良ブロックを直ちにブロック使用管理テーブルに登録することはせず、その後、リトライ処理によって正常に書き込みができた場合に、前回の書き込み時に利用したアドレスを不良ブロックとしてブロック使用管理テーブルを更新するようにしているので、メモリ自身の要因によってエラーが発生した場合のみブロック使用管理テーブルが更新される。従って、システム的な要因によるエラーの場合には、ブロック使用管理テーブルが更新されることはなく、不揮発性メモリの寿命が短くなることを確実に防止することができる。また、マルチプルライト処理においては、書き込みエラーが発生した場合に、エラーデータをエラー管理テーブルに登録し、ホストデバイスからの再書き込み要求により上記エラー管理テーブルに登録されたエラー管理データに基づいて空きブロックを選択してリトライ処理を行ない、リトライ動作が正しく実施されたことでエラー管理テーブルをクリアするようにしたので、システム的な要因によるエラーによってブロック使用管理テーブルが更新されることはなく、不揮発性メモリを効率的に使用して長寿命化を図ることができる。
なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
11…ホストインタフェース、12…コントローラ、121…マイクロプロセッサ(MPU)、122…レジスタ(REG)、13…ROM、14…RAM、141…作業用領域、142…ブロック使用管理テーブル、143…エラー管理テーブル、144…書き込みデータバッファ、15…フラッシュメモリ、151…管理領域