説明

情報処理装置、情報処理方法および情報処理プログラム

【課題】システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリのデータ保持特性を高めることを可能とする。
【解決手段】データが記録されるフラッシュメモリと、前記フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、前記システム処理部および前記リフレッシュ処理部のいずれか一方を優先的に動作させる優先度制御部と、を備える情報処理装置を提供する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
【背景技術】
【0002】
近年、電子的操作によりデータを書き込んだり消去したりすることが可能な不揮発性のメモリの1つであるフラッシュメモリが、各種情報処理装置などにおいて広く利用されている。
【0003】
しかしながら、フラッシュメモリは、長時間放置されることなどにより、フローティングゲートからの注入電子のリークが生じてしまい、データ保持特性が低下してしまうという問題がある。
【0004】
また、データの書き込みおよび消去を繰り返し行うことにより、フローティングゲートへの電子の注入および引抜が継続的に繰り返される。これにより、フローティングゲートと基板との間の絶縁酸化膜が徐々に劣化し、フローティングゲートに注入された電子が計時的にリークしてしまうおそれがある。この結果、フラッシュメモリのデータ保持特性や、フラッシュメモリ内のデータの信頼性が低下するという問題がある。
【0005】
上記問題に対応するために、例えば、特許文献1および2には、システムの初期化処理を行う際に、フラッシュメモリに書き込まれているすべてのデータを読み出し、ECC回路によりエラー訂正されたデータをフラッシュメモリに再度書き込む技術が開示されている。
【0006】
しかしながら、上記特許文献1および2に記載の技術は、システム運用中における異常検出や修復について考慮されていないため、システム運用中においては、フラッシュメモリの異常を検出してリフレッシュすることができない。
【0007】
ここで、システムの運用中においても、システム運用に影響を及ぼすことなく、フラッシュメモリの異常を検出し、検出された異常を修復可能な技術が特許文献3に開示されている。特許文献3には、運用系のフラッシュメモリおよび待機系のフラッシュメモリで二重構成されたフラッシュメモリが開示されている。このフラッシュメモリは、システム運用中であっても、待機系のフラッシュメモリの異常チェックを一定周期で行うことができる。したがって、待機系のフラッシュメモリの異常を検知した場合、正常な運用系のフラッシュメモリのプログラム情報を上書きすることにより修復(リフレッシュ)することができる。
【0008】
【特許文献1】特開平8−019796号公報
【特許文献2】特開平9−204367号公報
【特許文献3】特開2000−194605号公報
【発明の開示】
【発明が解決しようとする課題】
【0009】
しかしながら、特許文献3に記載のフラッシュメモリは、システム運用中の異常検出や修復を実現するために二重構成のフラッシュメモリを備える必要があり、製造コスト、製品価格などが上昇してしまうという問題があった。しかしながら、システム運用中に異常検出を行わなければ、システム運用中のデータ保持特性やデータの信頼性が低下するおそれがあるという問題があった。
【0010】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリのデータ保持特性を高めることが可能な、新規かつ改良された情報処理装置、情報処理方法および情報処理プログラムを提供することにある。
【課題を解決するための手段】
【0011】
上記課題を解決するために、本発明のある観点によれば、データが記録されるフラッシュメモリと、前記フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、前記システム処理部および前記リフレッシュ処理部のいずれか一方を優先的に動作させる優先度制御部と、を備える情報処理装置が提供される。
【0012】
係る構成により、情報処理装置が備えるシステム処理部は、フラッシュメモリに記録されたデータの読み出し、およびフラッシュメモリへのデータの書き込みを行うことができる。また情報処理装置が備えるリフレッシュ処理部は、フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、フラッシュメモリに再書き込みするリフレッシュ処理を実行することができる。さらに、情報処理装置が備える優先度制御部は、システム処理部およびリフレッシュ処理部のいずれか一方を優先的に動作させることができる。
【0013】
また、前記フラッシュメモリは、データが記録される複数のブロックから構成されてもよい。この場合、前記リフレッシュ処理部は、前記フラッシュメモリを構成する複数のブロックのうち、1ブロック毎に順次前記リフレッシュ処理を実行することもできる。
【0014】
また、前記優先度制御部は、前記システム処理部による処理を前記リフレッシュ処理部による処理より優先的に動作させ、前記リフレッシュ処理部が前記フラッシュメモリにデータを再書き込みしている間のみ、前記リフレッシュ処理部による処理を前記システム処理部による処理より優先的に動作させることもできる。
【0015】
また、前記リフレッシュ処理部は、あらかじめ設定された期間であるリフレッシュ期間内に、前記フラッシュメモリを構成するすべてのブロックに対して前記リフレッシュ処理を実行することもできる。
【0016】
また、前記リフレッシュ処理部は、前記フラッシュメモリを構成するすべてのブロックに対して前記リフレッシュ処理を実行した場合、前記リフレッシュ期間毎に再度前記リフレッシュ処理を実行することもできる。
【0017】
また、前記リフレッシュ処理部は、前記リフレッシュ期間と、前記フラッシュメモリを構成するブロックの総数と、既に前記リフレッシュ処理が行われたブロックの数と、に基づいて、前記リフレッシュ処理が行われていない残りのブロックに対して前記リフレッシュ処理を実行する周期である1ブロックリフレッシュ周期時間を算出し、前記1ブロックリフレッシュ周期時間毎に前記残りのブロックに対して前記リフレッシュ処理を実行することもできる。
【0018】
また、前記リフレッシュ処理部は、前記フラッシュメモリを構成する複数のブロックのうち、1のブロックに対して前記リフレッシュ処理を実行する毎に、前記1ブロックリフレッシュ周期時間を算出することもできる。
【0019】
また、前記リフレッシュ処理部は、前記フラッシュメモリに記録されている所定の情報を読み出し、前記読み出した情報に基づいて前記フラッシュメモリに対して前記リフレッシュ処理が必要か否かを判断し、前記リフレッシュ処理が必要と判断した場合にのみ前記リフレッシュ処理を実行することもできる。
【0020】
また、前記情報処理装置は、所定のデータの読み出しおよび/または書き込みを行うリーダライタ装置であってもよい。
【0021】
また、上記課題を解決するために、本発明の別の観点によれば、フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、のいずれを優先的に動作させるか判断する優先度判断ステップと、前記優先度判断ステップにより前記システム制御部を優先的に動作させると判断された場合に行われる、前記システム制御部が前記フラッシュメモリに記録されたデータの読み出し、または前記フラッシュメモリへのデータの書き込みを行うシステム処理ステップと、前記優先度判断ステップにより前記リフレッシュ処理部を優先的に動作させると判断された場合に行われる、前記リフレッシュ処理部が前記リフレッシュ処理を実行するリフレッシュ処理ステップと、を含む情報処理方法が提供される。
また、上記課題を解決するために、本発明の別の観点によれば、フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、のいずれを優先的に動作させるか判断する優先度判断処理と、前記優先度判断処理により前記システム制御部を優先的に動作させると判断された場合に実行される、前記システム制御部が前記フラッシュメモリに記録されたデータの読み出し、または前記フラッシュメモリへのデータの書き込みを行うシステム処理と、前記優先度判断ステップにより前記リフレッシュ処理部を優先的に動作させると判断された場合に行われる、前記リフレッシュ処理部が実行する前記リフレッシュ処理と、をコンピュータに実行させる情報処理方法が提供される。
【発明の効果】
【0022】
以上説明したように本発明によれば、システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリのデータ保持特性を高めることが可能である。
【発明を実施するための最良の形態】
【0023】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。また、説明は以下の順序で行うものとする。
1.本発明の実施形態の概要
2.実施形態の1つに係る情報処理装置100の機能構成
3.各種処理フロー
3−1.リフレッシュ処理の全体処理フロー
3−2.リフレッシュ処理部108による1ブロックリフレッシュ処理フロー
3−3.システム処理部106によるデータ書き込み処理フロー
3−4.優先度制御部110による優先度決定処理フロー
4.まとめ
【0024】
本発明の実施形態の1つに係る情報処理装置100の詳細を説明するにあたり、まず本実施形態の概要について従来技術と比較して説明する。
【0025】
上述したように、電子的操作によりデータを書き込んだり消去したりすることが可能なフラッシュメモリは、長時間放置されることなどにより、フローティングゲートからの注入電子のリークが生じてしまい、データ保持特性が低下してしまうという問題があった。また、データの書き込みおよび消去を繰り返し行うことにより、フローティングゲートへの電子の注入および引抜が継続的に繰り返される。これにより、フローティングゲートと基板との間の絶縁酸化膜が徐々に劣化し、フローティングゲートに注入された電子が計時的にリークしてしまうおそれがある。この結果、フラッシュメモリのデータ保持特性や、フラッシュメモリ内のデータの信頼性が低下するという問題があった。
【0026】
このような問題に対応するために、従来のフラッシュメモリでは、データ読み出し時に、データの信頼性の低下の有無を調べ、データの信頼性が低下している場合には、再書込みを行う、いわゆるリフレッシュ処理が行われる場合がある。このようなリフレッシュ処理に関する技術は、例えば、上記の特許文献1、2に開示されている。
【0027】
特許文献1には、プログラムベリファイモードとイレーズベリファイモードという2つの異なるモードで同一のアドレスからデータを読み出し、両データが一致しない場合、メモリセルのデータを書き換える技術が開示されている。
【0028】
また、特許文献2には、ECC(Error Check and Corrct、Error Correcting Code)回路とフラッシュメモリとを備えるフラッシュディスクカードが開示されている。このフラッシュディスクカードは、初期化処理を行う際に、初期化処理の一環として、フラッシュメモリに書き込まれているすべてのデータを読み出す。その後、ECC回路が、読み出されたデータに対してエラー検出を行い、訂正したデータをフラッシュメモリに書き込む。これにより、当該フラッシュディスクカードは、データ保持特性を低下させることを防止することができる。
【0029】
しかしながら、上記特許文献1および2に記載の技術は、システム運用中における異常検出や修復について考慮されていない。したがって、システム運用中においては、フラッシュメモリの異常を検出してリフレッシュすることができないという問題があった。また、例えば、1ヶ月といった比較的短い期間内に複数ビットのデータの信頼性が低下するような場合においては、上述したECC回路による初期化時のリフレッシュ処理では対策が不十分である。したがって、初期化時だけでなく、システムの運用中においても、適宜リフレッシュ処理を行うことが望ましい。
【0030】
ここで、システムの運用中においても、システム運用に影響を及ぼすことなく、フラッシュメモリの異常を検出し、検出された異常を修復可能な技術が上記特許文献3に開示されている。特許文献3には、運用系のフラッシュメモリおよび待機系のフラッシュメモリで二重構成されたフラッシュメモリが開示されている。このフラッシュメモリは、システム運用中であっても、待機系のフラッシュメモリの異常チェックを一定周期で行うことができる。したがって、待機系のフラッシュメモリの異常を検知した場合、正常な運用系のフラッシュメモリのプログラム情報を上書きすることにより修復(リフレッシュ)することができる。
【0031】
しかしながら、特許文献3に記載のフラッシュメモリは、システム運用中の異常検出や修復を実現するために二重構成のフラッシュメモリを備える必要があり、製造コスト、製品価格などが上昇してしまうという問題があった。
【0032】
本発明の実施形態の1つに係る情報処理装置100は、このような問題点を解決するものであり、システム運用中であっても、システムの運用に影響を及ぼすことなく、効率よくデータ保持特性や、フラッシュメモリ内のデータの信頼性を高めることを可能とする。
【0033】
具体的には、本実施形態に係る情報処理装置100は、フラッシュメモリに記録されたデータの読み出し、およびデータの書き込みを行うシステム処理部に加えて、リフレッシュ処理部および優先度制御部を備えることを特徴としている。リフレッシュ処理部は、システム運用中において、定期的にフラッシュメモリに記録されているデータを読み出してエラー検知をして、エラーが発見されたデータに対してはエラー訂正処理を実行する。リフレッシュ処理部は、その後、エラー訂正処理されたデータを含めて、読み出したデータを再度フラッシュメモリに書き込む。これにより、システム運用中においても、フラッシュメモリに記録されたデータの保持特性を高めることができる。
【0034】
さらに、優先度制御部は、システム処理部およびリフレッシュ処理部のいずれによる処理を優先的に実行させるかを制御することができる。例えば、優先度制御部は、通常はリフレッシュ処理部よりもシステム制御部を優先的に実行させることができる。これにより、システム処理が実行されている場合には、リフレッシュ処理を待機させることができ、リフレッシュ処理によりシステム運用に悪影響を与えることを防止することができる。また、優先度制御部は、例えば、リフレッシュ処理部がフラッシュメモリにデータの再書込みを行っている場合には、システム処理部よりもリフレッシュ処理部を優先的に動作させることもできる。これにより、エラー訂正後のデータなどをフラッシュメモリに再書き込みしている最中には、システム処理を待機させることができ、データの不整合等を確実に防止することもできる。
【0035】
このように、本実施形態に係る情報処理装置100は、システム運用中であっても、システム処理部およびリフレッシュ処理部による処理のいずれか一方を優先的に動作させることができる。これにより、本実施形態に係る情報処理装置100は、システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリのデータ保持特性を高めることが可能である。
【0036】
以下、このような特徴を有する本発明の実施形態の1つに係る情報処理装置100の詳細について説明する。
【0037】
(2.情報処理装置100の機能構成)
まず、本発明の実施形態の1つに係る情報処理装置100の機能構成について説明する。図1は、本実施形態に係る情報処理装置100の機能構成を示すブロック図である。なお、情報処理装置100は、例えば、ICチップなどに記録された各種データを非接触で読み取り可能なリーダライタ装置などが想定されるが、フラッシュメモリを搭載した情報処理装置であれば、例えば、パーソナルコンピュータや携帯電話などであってもよい。
【0038】
図1に示すように、情報処理装置100は主に、装置処理部(中央処理装置:CPU(Central Processing Unit))102と、装置記憶部104と、を含んで構成される。装置処理部102は、プログラム制御により動作し、情報処理装置100が備える各種処理を実行する。また、図1に示すように、装置処理部102は主に、システム処理部106と、リフレッシュ処理部108と、優先度制御部110と、を含んで構成される。また、装置記憶部104は、情報処理装置100の各種データや初期設定値などを記憶する記憶部として機能する。図1に示すように、装置記憶部104は主に、ROM112と、RAM114と、フラッシュメモリ116と、を含んで構成される。なお、情報処理装置100を構成するこれらの各機能部は、バスにより接続されている。以下このように構成される情報処理装置100の各機能部について詳細に説明する。
【0039】
(装置記憶部104)
ROM(Read Only Memory)112は、装置処理部102が使用するプログラム、演算パラメータ、初期設定値などを記憶する。本実施形態においては、ROM112には、フラッシュメモリ116のリフレッシュの必要性を判断するための「リフレッシュ判断テーブル」があらかじめ記録されている。また、ROM112には、フラッシュメモリ116の全ブロックに対してリフレッシュ処理を実行する期間である「リフレッシュ期間」もあらかじめ記録されている。
【0040】
ここで、「リフレッシュ判断テーブル」とは、所定のフラッシュメモリがリフレッシュ処理を必要とする品種のフラッシュメモリであるか否かに関する情報が、製造メーカや型番などの情報と対応付けられて記録されているデータベースである。フラッシュメモリ116がリフレッシュ処理を必要としない高信頼性の品種である場合には、リフレッシュ処理部108によるリフレッシュ処理は必要ない。したがって、詳細は後述するが、リフレッシュ処理部108は、ROM112に記録されている「リフレッシュ判断テーブル」に基づいて、情報処理装置100に備えられるフラッシュメモリ116に対してリフレッシュ処理が必要か否かを判断することができる。
【0041】
また、詳細は後述するが、リフレッシュ処理部108は、ROM112に記録されている「リフレッシュ期間」に基づいて、1ブロック毎のリフレッシュ処理の周期時間などを算出することもできる。
【0042】
なお、「リフレッシュ期間」や「リフレッシュ判断テーブル」などの情報は、例えば、情報処理装置100の運営者などが任意に設定・更新することができるものであり、特定の期間やデータベースに限定されるものではない。また、本実施形態において、ROM112に記録されるデータはこれらに限定されるものではなく、後述する各種処理に必要な設定値、パラメータ、プログラムなども記録されていることは言うまでもない。
【0043】
RAM(Random Access Memory)114は、装置処理部102による各種処理の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一次的に記憶する。本実施形態においては、RAM114には、例えば、システム処理部106の実行状態を表す「変更検知フラグ」や、リフレッシュ処理部108がリフレッシュ処理を実行しているブロックの番号を表す「ブロック番号」などが記録されている。また、RAM114には、リフレッシュ処理部108の優先度を表す「リフレッシュ処理優先度」も記録されている。
【0044】
詳細は後述するが、システム処理部106やリフレッシュ処理部108は、各種処理に応じてRAM114に記録されている「変更検知フラグ」の値を更新することができる。例えば、システム処理部106は、フラッシュメモリのデータの書き換えなどの処理を実行する際には、「変更検知フラグ」の値を、システム処理部106が処理を実行している最中であることを意味する「1」に更新することができる。
【0045】
また、詳細は後述するが、リフレッシュ処理部108は、フラッシュメモリ116を構成する複数のブロックごとに順次リフレッシュ処理を実行する。したがって、リフレッシュ処理部108は、リフレッシュ処理を実行しているブロックの番号に応じて、「現在ブロック番号」を適宜更新することができる。
【0046】
また、リフレッシュ処理部108は、リフレッシュ処理の進行状況に応じてRAM114に記録されている「リフレッシュ処理優先度」を適宜更新することができる。「リフレッシュ処理優先度」は通常は「低」に設定されてシステム処理部106による処理が優先されるが、リフレッシュ処理部108は、データをフラッシュメモリ116に再書き込みする際には、「リフレッシュ処理優先度」を「高」に設定することができる。なお、リフレッシュ処理部108による「リフレッシュ処理優先度」の更新処理の流れについては、後述する処理フローにおいて説明する。また、本明細書においては、説明の便宜上「リフレッシュ処理優先度」が「高」、「低」と記して説明するが、実際には、「リフレッシュ処理優先度」は、例えば、「0」、「1」などのフラグ情報として管理されることができるものである。
【0047】
なお、本実施形態において、RAM114に記録されるデータはこれらに限定されるものではなく、後述する各種処理に必要な設定値、パラメータ、プログラムなども一時的に記録されていることは言うまでもない。
【0048】
フラッシュメモリ116は、電子的操作によりデータを書き込んだり消去したりすることが可能な不揮発性の記憶素子であり、例えば、NAND型フラッシュメモリである。フラッシュメモリ116は、アクセスの単位として複数のブロックおよびページで構成される。フラッシュメモリ116へのデータの書き込みや読み込みは、複数ビット単位のページで行われ、消去は複数のページにより構成されるブロック単位で行われる。本実施形態においては、リフレッシュ処理部108は、フラッシュメモリ116を構成するブロック単位でリフレッシュ処理を行う。なお、1ページ当たりのデータ容量や、1ブロック当たりのページ数などは、任意に変更することができるものであり、特定の容量に限定されるものではない。
【0049】
装置記憶部104を構成するROM112、RAM114およびフラッシュメモリ116は、CPUバスなどから構成されるホストバスにより相互に接続されるとともに、装置処理部102とも接続されている。したがって、装置処理部102を構成するシステム処理部106、リフレッシュ処理部108、優先度制御部110は、装置記憶部104に記録されている各種情報、プログラムなどを利用したり、データの読み書き、消去などの処理を実行したりすることができる。
【0050】
(システム処理部106)
システム処理部106は、システム運用におけるフラッシュメモリ116のデータの読み書きに関する処理を実行する。システム処理部106は、例えば、利用者により操作部(図示せず)などが操作されると、当該操作に応じてフラッシュメモリ116のデータの読み書きを実行することができる。また、例えば、本実施形態に係る情報処理装置100がリーダライタ装置である場合には、非接触ICチップが搭載された携帯電話などが情報処理装置100にかざされた場合に、システム処理部106は、フラッシュメモリ116のデータの読み書きを実行することもできる。
【0051】
また、詳細は後述するが、本実施形態においては、システム運用中においては原則として、システム処理部106による処理はリフレッシュ処理部108による処理と比較して優先度が高く設定されている。したがって、システム運用中においては原則として、リフレッシュ処理よりもシステム処理部106によるフラッシュメモリ116のデータの読み書きが優先的に行われることとなる。なお、システム運用中におけるシステム処理部106によるフラッシュメモリ116のデータの読み書きの処理の流れについては、後述する処理フローにおいて説明する。
【0052】
(リフレッシュ処理部108)
リフレッシュ処理部108は、フラッシュメモリ116のデータ保持期間中に、フラッシュメモリ116に記録されているデータに対してエラー補正を行った後に、再度データをフラッシュメモリ116に書き込むことによりリフレッシュ処理を実行する。リフレッシュ処理部108によるリフレッシュ処理は次のような手順で行われる。
【0053】
まず、リフレッシュ処理部108は、フラッシュメモリ116を構成する複数のブロックのうち、1のブロックに記録されているデータを一時的にRAM114へ退避させる。次に、リフレッシュ処理部108は、ECC(Error Check and Corrct、Error Correcting Code)回路などを利用することにより、RAM114へ退避させたデータのビットエラーを検出・補正する。その後、リフレッシュ処理部108は、RAM114へ退避させたデータを補正されたデータを含めて再度フラッシュメモリ116へ書き込む。
【0054】
このような一連のリフレッシュ処理をブロック単位で順次行うことにより、フラッシュメモリ116を構成するすべてのブロックに対してリフレッシュ処理を行うことができ、フラッシュメモリ116のデータ保持特性を高めることができる。このようにリフレッシュ処理部108は、フラッシュメモリ116を構成するブロック毎にリフレッシュ処理を順次行っていくが、以下の説明においては、ブロック単位毎に行われるリフレッシュ処理を「1ブロックリフレッシュ処理」と記して説明する。
【0055】
また、詳細は後述するが、本実施形態においては、システム運用中においては原則として、リフレッシュ処理部108による処理はシステム処理部106による処理と比較して優先度が低く設定されている。したがって、システム処理部106がフラッシュメモリ116のデータの読み書きを行っている際には、原則としてリフレッシュ処理部108によるリフレッシュ処理は実行されない。これは、システム処理部106によるデータの読み書きとリフレッシュ処理部108によるデータの再書き込みとが同時に行われることによるデータの不整合等を防止するためである。また、リフレッシュ処理部108がリフレッシュ処理において、フラッシュメモリ116へデータの再書き込みを行っている場合には、例外的に、リフレッシュ処理部108による処理がシステム処理部106による処理と比較して優先度が高く設定される。この結果、同様に、システム処理部106によるデータの読み書きとリフレッシュ処理部108によるデータの再書き込みとが同時に行われることによるデータの不整合等を防止することができる。したがって、本実施形態においては、リフレッシュ処理部108は、システム運用中においても、システム処理部106による処理に影響を及ぼすことなくリフレッシュ処理を実行することができる。なお、システム運用中におけるリフレッシュ処理部108によるリフレッシュ処理の流れについては、後述する処理フローにおいて説明する。
【0056】
(優先度制御部110)
優先度制御部110は、システム処理部106による処理、およびリフレッシュ処理部108による処理のいずれを優先的に実行させるかを制御する。上述したように、システム処理部106によるフラッシュメモリ116のデータの読み書きと、リフレッシュ処理部108によるフラッシュメモリ116へのデータの再書き込みとが同時に行われた場合、フラッシュメモリ116のデータに不整合が発生してしまうおそれがある。したがって、本実施形態においては、優先度制御部110が、システム処理部106およびリフレッシュ処理部108のいずれか一方のみを優先的に動作させることにより、いずれか一方の処理部のみが各種処理を実行することができる。なお、システム運用中における優先度制御部110による優先度制御の流れについては、後述する処理フローにおいて説明する。
【0057】
以上、本実施形態に係る情報処理装置100の機能構成について説明した。上述したように、本実施形態に係る情報処理装置100は、フラッシュメモリ116のデータの読み書きを行うシステム処理部106に加えて、システム運用中においても定期的にリフレッシュ処理を行うリフレッシュ処理部108を備えている。これにより、システム運用中においても定期的にフラッシュメモリ116のリフレッシュ処理を行うことができ、データの保持特性を高めることができる。また、本実施形態に係る情報処理装置100は、システム処理部106による処理、およびリフレッシュ処理部108による処理のいずれか一方を優先的に実行させる優先度制御部110を備えている。これにより、システム運用中にシステム処理部106による処理とリフレッシュ処理部108によるリフレッシュ処理が同時に行われることによるデータの不整合の発生を防止することができる。すなわち、本実施形態に係る情報処理装置100は、システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリ116のデータ保持特性を高めることが可能である。
【0058】
また、図1に示した情報処理装置100の機能構成は、本実施形態の特徴であるリフレッシュ処理を実行する機能構成について中心に示したものであり、本発明はこれらに限定されるものではない。例えば、操作入力部、表示制御部、音声出力部、通信制御部などの通常の情報処理装置に備えられる各種機能を追加的に備えることも当然に可能である。
【0059】
(3.各種処理フロー)
次に、上記のように構成される本実施形態に係る情報処理装置100において、システム運用中に行われる各種処理の流れの詳細について、図2〜図6を参照にして説明する。なお、以下に示すフロー図は、本実施形態に係る情報処理装置100における各種処理の流れの一例を示すものであり、各種処理の流れは、必ずしもこれらに限定されるものではない。すなわち、各フロー図に記述されたステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的に又は個別的に実行される処理をも含む。また時系列的に処理されるステップでも、場合によっては適宜順序を変更することが可能であることは言うまでもない。
【0060】
(3−1.リフレッシュ処理の全体処理フロー)
まず、上記のように構成される情報処理装置100において行われるリフレッシュ処理の全体の処理の流れについて説明する。図2は、本実施形態に係る情報処理装置100において行われるリフレッシュ処理の全体の処理の流れの一例を示すフロー図である。なお、図2に示す処理フローは、情報処理装置100の電源が投入された後に定期的に実行される処理である。
【0061】
図2に示すように、最初にステップ200において、リフレッシュ処理部108が起動する。上述したように、リフレッシュ処理は、情報処理装置100の電源が投入されている間、定期的に実行される。したがって、情報処理装置100の電源が投入されると、ステップ200の処理が実行されることとなる。
【0062】
次に、ステップ202において、リフレッシュ処理部108は、フラッシュメモリ116の種類を識別する。リフレッシュ処理部108は、例えば、フラッシュメモリ116に記録されているフラッシュメモリ116の製造メーカ、型番などの情報を読み出す。
【0063】
その後、ステップ204において、リフレッシュ処理部108は、読み出した製造メーカや型番などの情報と、ROM112に記録されている「リフレッシュ判断テーブル」と、に基づいて、フラッシュメモリ116に対してリフレッシュ処理が必要か否かを判断する。上述したように、ROM112に記録されている「リフレッシュ判断テーブル」には、所定のフラッシュメモリがリフレッシュ処理を必要とする品種のフラッシュメモリであるか否かに関する情報が、製造メーカや型番などの情報と対応付けられて記録されている。したがって、リフレッシュ処理部108は、読み出した製造メーカなどの情報と「リフレッシュ判断テーブル」とを照らし合わせることにより、情報処理装置100が備えるフラッシュメモリ116に対してリフレッシュ処理が必要か否かを判断することができる。
【0064】
ステップ204により、フラッシュメモリ116に対してリフレッシュ処理が不要であると判断された場合、リフレッシュ処理は終了し、その後フラッシュメモリ116に対してリフレッシュ処理が行われることはない。一方、ステップ204により、フラッシュメモリ116に対してリフレッシュ処理が必要であると判断された場合、以下の処理ステップによりリフレッシュ処理が定期的に行われる。
【0065】
まず、リフレッシュ処理部108は、ステップ206において、リフレッシュ処理を実行するために必要なリフレッシュ設定値を取得する。ここで、リフレッシュ設定値とは、フラッシュメモリ116の全ブロックのリフレッシュ処理を完成させる期間である「リフレッシュ期間」と、フラッシュメモリ116を構成する複数のブロックの総数である「全ブロック数」を意味する。リフレッシュ処理部108は、ROM112に記録されている「リフレッシュ期間」を読み出し、フラッシュメモリ116の「全ブロック数」をフラッシュメモリ116から読み出すことにより、リフレッシュ設定値を取得することができる。なお、以下の処理フローにおいては、「リフレッシュ期間」が「2週間」で、「全ブロック数」が「1000」である場合を例に説明する。
【0066】
次に、リフレッシュ処理部108は、ステップ208において、「現在ブロック数」が「0」であるか否かを判断する。上述したように、リフレッシュ処理は、フラッシュメモリ116を構成する複数のブロックのそれぞれに対して順次行われる1ブロックリフレッシュ処理により構成される。ここで、「現在ブロック数」が「0」であることは、リフレッシュ処理を構成する複数の1ブロックリフレッシュ処理のうち、最初の1ブロックリフレッシュ処理であることを意味する。
【0067】
ステップ208により、「現在ブロック数」が「0」であると判断された場合、リフレッシュ処理部108は、ステップ210において、リフレッシュ開始判定処理を実行する。図3は、リフレッシュ処理部108が実行するリフレッシュ開始判定処理の流れを示すフロー図である。
【0068】
図3に示すように、リフレッシュ処理部108は、まずステップ300において、「リフレッシュ開始日時」がRAM114に記録されているか否かを判断する。詳細は後述するが、リフレッシュ処理部108は、最初のブロックに対して1ブロックリフレッシュ処理を行う際、すなわち、「現在ブロック数」が「0」の状態で1ブロックリフレッシュ処理を行う際に、「リフレッシュ開始日時」をRAM114に記録する。したがって、情報処理装置100の電源が投入されて一度でもリフレッシュ処理が実行された場合、「リフレッシュ開始日時」がRAM114に記録されていることとなる。
【0069】
ステップ300により、「リフレッシュ開始日時」がRAM114に記録されていると判断された場合、リフレッシュ処理部108は、ステップ302において、「リフレッシュ開始日時」をRAM114から読み出す。また、リフレッシュ処理部108は、ステップ304において、「現在時刻」を、例えば情報処理装置100に備えられるタイマなどから読み出す。
【0070】
その後、ステップ306において、リフレッシュ処理部108は、ステップ304により読み出した「現在時刻」が、ステップ302により読み出した「リフレッシュ開始日時」から「リフレッシュ期間」である2週間を経過しているか否かを判断する。上述したように、リフレッシュ処理部108は、「リフレッシュ期間」毎にフラッシュメモリ116に対してリフレッシュ処理を開始するからである。
【0071】
したがって、ステップ306により、「現在時刻」が「リフレッシュ開始日時」から2週間経過していると判断された場合、リフレッシュ処理部108は、ステップ308において、リフレッシュ処理の開始を決定する。また、上述したステップ300により、「リフレッシュ開始日時」がRAM114に記録されていないと判断された場合も同様に、リフレッシュ処理部108は、ステップ308において、リフレッシュ処理の開始を決定する。
【0072】
一方、ステップ306により、「現在時刻」が「リフレッシュ開始日時」から2週間経過していないと判断された場合、リフレッシュ処理部108は、ステップ304に戻る。すなわち、リフレッシュ処理部108は、ステップ304およびステップ306において、継続的に「現在時刻」が「リフレッシュ開始日時」から2週間を経過しているか否かを判断する。
【0073】
このような処理により、リフレッシュ処理部108は、前回リフレッシュ処理が開始された日時から「リフレッシュ期間」が経過されるまでは新しいリフレッシュ処理の開始を決定しないことができる。これにより、リフレッシュ処理部108は、あらかじめ設定された「リフレッシュ期間」毎に定期的にリフレッシュ処理を開始することができる。
【0074】
再度図2を参照すると、ステップ210のリフレッシュ開始判定処理によりリフレッシュ処理の開始が決定された場合、ステップ214以降の処理が実行される。また、ステップ208により、「現在ブロック番号」が「0」でないと判断された場合は、既にリフレッシュ処理が開始されていることを意味するため、同様にステップ214以降の処理が継続して行われる。例えば、リフレッシュ処理が開始された後に、何らかの原因で情報処理装置100の電源が切られ、再度電源投入された場合などには、「0」以外の「現在ブロック番号」が保持されていることもある。このような場合には、情報処理装置100の電源投入後に、再度リフレッシュ開始判定処理を行うことなく、ステップ214以降の処理を継続して実行することができる。
【0075】
ステップ214において、リフレッシュ処理部108は、「現在ブロック番号」が「全ブロック数」である「1000」より小さいか否かを判断する。ステップ214により「現在ブロック番号」が「1000」より小さいと判断された場合、リフレッシュ処理部108は、リフレッシュ処理がまだ終了していないと判断し、ステップ216において、当該ブロックに対して1ブロックリフレッシュ処理を実行する。なお、ステップ216における1ブロックリフレッシュ処理の流れの詳細については後述する。
【0076】
このとき、リフレッシュ処理部108は、ステップ218において、「現在ブロック番号」が「0」であるか否かを判断する。ステップ218により、「現在ブロック番号」が「0」であると判断された場合、リフレッシュ処理部108は、ステップ220において、現在日時をタイマなどから読み出して、「リフレッシュ開始日時」としてRAM114に記録する。このようにして記録された「リフレッシュ開始日時」は、次のリフレッシュ処理を実行する際に、上述したステップ210のリフレッシュ開始判定処理において利用されることとなる。なお、当該フローにおいては、リフレッシュ処理部108は、「リフレッシュ開始日時」をRAM114に記録するが、本発明はこれに限定されるものではない。例えば、リフレッシュ処理部108は、「リフレッシュ開始日時」を、RAM114以外の他の不揮発性の記憶領域などに記録しておくことも当然に可能である。
【0077】
次に、リフレッシュ処理部108は、ステップ222において、「現在ブロック番号」の値を1つ加算して更新する。上述したように、フラッシュメモリ116は、複数のブロックから構成されており、リフレッシュ処理部108は、このような複数のブロックに記録されているデータに対して順次1ブロックリフレッシュ処理を実行する。したがって、リフレッシュ処理部108は、1ブロックリフレッシュ処理を実行するたびに、「現在ブロック番号」をインクリメントする。
【0078】
その後、リフレッシュ処理部108は、ステップ224において、1ブロックリフレッシュ処理を実行する周期時間を算出し、ステップ226において、当該算出した周期時間を経過したか否かを判断する。リフレッシュ処理部108は、以下の式に基づいて、「1ブロックリフレッシュ周期時間」を算出することができる。
【0079】
残り時間=(リフレッシュ開始日時+リフレッシュ期間)−現在日時 ・・(1)
残りブロック数=全ブロック数−現在ブロック数 ・・(2)
1ブロックリフレッシュ周期時間=残り時間/残りブロック数 ・・(3)
【0080】
上記式(1)により、リフレッシュ処理を終了するまでに残された時間を算出することができる。ここで、式(1)の「リフレッシュ開始日時」は上述したステップ220により記録された値であり、「リフレッシュ期間」はステップ206によりROM112から読み出された値(2週間)であり、「現在日時」はタイマなどから読み出された現在の日時である。
【0081】
また、上記式(2)により、リフレッシュ処理が終了していないブロック数を算出することができる。ここで、式(2)の「全ブロック数」は上述したステップ206によりフラッシュメモリ116から読み出された値(1000)であり、「現在ブロック数」はステップ222により更新された値である。
【0082】
さらに、上記式(3)により、リフレッシュ処理部108は、「1ブロックリフレッシュ周期期間」を算出することができる。したがって、リフレッシュ処理部108は、リフレッシュ処理が終了していない残りのブロックに対して、式(3)により算出した「1ブロックリフレッシュ周期期時間」毎に、1ブロックリフレッシュ処理を実行すればよい。これにより、リフレッシュ処理部108は、あらかじめ設定された「リフレッシュ期間(2週間)」ですべてのブロックに対して1ブロックリフレッシュ処理を実行することができる。
【0083】
このように、リフレッシュ処理部108は、1ブロックリフレッシュ処理を実行するたびに「1ブロックリフレッシュ周期時間」を算出し、当該算出した「1ブロックリフレッシュ周期時間」毎に1ブロックリフレッシュ処理を実行する。これにより、例えば、情報処理装置100の電源が切られた場合や、システム処理部106による所定の処理が頻繁に行われた場合などにおいても、適切な「1ブロックリフレッシュ周期時間」を算出することができる。したがって、リフレッシュ処理部108は、適宜変更される「1ブロックリフレッシュ周期時間」に基づいて1ブロックリフレッシュ処理を実行することにより、あらかじめ設定された「リフレッシュ期間(2週間)」でリフレッシュ処理を実行することができる。
【0084】
なお、上記式(1)〜(3)は、本実施形態を説明する上での一例であり、本発明は必ずしもこれらに限定されるわけではない。例えば、リフレッシュ処理部108は、上記式(3)の代わりに、下記式(4)により「1ブロックリフレッシュ周期時間」を算出してもよい。
【0085】
1ブロックリフレッシュ周期時間=(残り時間/2)/残りブロック数 ・・(4)
【0086】
例えば、情報処理装置100が店舗などに設置される場合には、夜間に電源が切られることも想定される。このような場合を想定し、リフレッシュ処理部108は、残り時間に余裕を持たせて、残り時間の半分以内にリフレッシュ処理が終了するように「1ブロックリフレッシュ周期時間」を算出することもできる。このように、「1ブロックリフレッシュ周期時間」の算出に用いられる式は、例えば、情報処理装置100の運営者などが任意に設定することができるものであり、特定の式に限定されるものではない。またこのような「1ブロックリフレッシュ周期時間」を算出する式は、例えば、ROM112などにあらかじめ設定しておくことや、情報処理装置100の運営者などにより任意に変更することも当然に可能である。
【0087】
次に、ステップ226により、上記のようにして算出した「1ブロックリフレッシュ周期時間」が経過したと判断された場合、再度ステップ214へ戻り、新しいブロックに対して1ブロックリフレッシュ処理が行われる。また、例えば、情報処理装置100の電源が長時間切られて、既に「リフレッシュ期間(2週間)」が経過している場合には、「1ブロックリフレッシュ周期時間」を「0」として、連続して残りのブロックに対する1ブロックリフレッシュ処理を実行してもよい。
【0088】
このようにして、ステップ214〜ステップ226の処理を繰り返すことにより、リフレッシュ処理部108は、フラッシュメモリ116を構成するすべてのブロックに対して順次1ブロックリフレッシュ処理を実行することができる。
【0089】
ここで、リフレッシュ処理部108がすべてのブロックに対して1ブロックリフレッシュ処理を実行した場合、すなわちリフレッシュ処理が終了した場合、ステップ214において「現在ブロック番号」が「1000」を超えていると判断されることとなる。この場合、リフレッシュ処理部108は、ステップ228において、「現在ブロック番号」を「0」に更新する。また、リフレッシュ処理部108は、ステップ230において、リフレッシュ処理を行った回数を表す「リフレッシュ実行回数」をインクリメントする。なお、リフレッシュ処理部108は、「リフレッシュ実行回数」をフラッシュメモリ116に記録することができるが、例えば、フラッシュメモリ116以外の不揮発性の記憶領域に記録してもよい。
【0090】
このようにしてリフレッシュ処理部108によるリフレッシュ処理が終了すると、再度ステップ208に戻り、「リフレッシュ期間」に応じて新しいリフレッシュ処理が開始されることとなる。
【0091】
以上の処理ステップにより、リフレッシュ処理部108は、情報処理装置100のシステム運用中において、定期的にリフレッシュ処理を実行することができる。また、リフレッシュ処理部108は、「1ブロックリフレッシュ周期時間」を適宜算出することにより、あらかじめ設定された「リフレッシュ期間」内にすべてのブロックに対して1ブロックリフレッシュ処理を実行することができる。
【0092】
(3−2.システム処理部106によるデータ書き込み処理フロー)
次に、システム運用中においてシステム処理部106により行われるフラッシュメモリ116のデータの読み書きの処理の流れについて説明する。図4は、本実施形態に係る情報処理装置100において、システム処理部106が行うフラッシュメモリ116のデータの書き換え処理の流れの一例を示すフロー図である。なお、システム処理部106は、例えば、利用者が操作部などを操作した場合や、非接触ICチップが搭載された携帯電話などが情報処理装置100にかざされた場合などに、図4に示すデータの書き込み処理を実行することができる。
【0093】
システム処理部106は、まずステップ400において、データ書き換えの対象となるフラッシュメモリ116のブロック番号と、リフレッシュ処理部108が1ブロックリフレッシュ処理を実行している「現在ブロック番号」と、が一致するか否かを判断する。上述したように、システム処理部106によるデータ書き込み処理と、リフレッシュ処理部108による1ブロックリフレッシュ処理とが、同一のブロックに対して同時に行われた場合、データの不整合が発生してしまうおそれがある。したがって、システム処理部106は、これからデータの書き換えを行うブロックが、現在リフレッシュ処理部108により1ブロックリフレッシュ処理が実行されているか否かを判断するためにステップ400の処理を行う。
【0094】
ステップ400により、ブロック番号が一致すると判断された場合、システム処理部106は、ステップ402において、RAM114に記録されている「変更検知フラグ」の値を「1」に更新する。上述したように、「変更検知フラグ」は、1ブロックリフレッシュ処理の対象となっているブロックが、システム処理部106によってデータ更新されていることを表すフラグである。本実施形態においては、「変更検知フラグ」が「0」の場合は、システム処理部106によってデータが更新されていないことを意味し、「1」の場合は、システム処理部106によってデータが更新されていることを意味する。この「変更検知フラグ」の値を参照することにより、リフレッシュ処理部108は、対象となるブロックのデータがシステム処理部106により更新中であるか否かを判断することができる。
【0095】
その後、システム処理部106は、ステップ404において、対象となるブロックに記録されているデータを書き換えて更新する。なお、ステップ400により、ブロック番号が一致しないと判断された場合は、システム処理部106が処理するブロックは、リフレッシュ処理部108により1ブロックリフレッシュ処理が実行されているブロックとは異なることを意味する。したがって、この場合、システム処理部106は、「変更検知フラグ」を「1」に更新することなく、ステップ404において、対象となるブロックに記録されているデータを書き換えて更新する。
【0096】
以上の処理フローにより、システム処理部106は、フラッシュメモリ116のデータの読み書きを任意に実行することができる。また、システム処理部106は、フラッシュメモリ116のデータの読み書きを実行する際に、対象となるブロック番号に応じて「変更検知フラグ」の値を更新することができる。
【0097】
(3−3.1ブロックリフレッシュ処理フロー)
次に、リフレッシュ処理部108により行われる1ブロックリフレッシュ処理、すなわち、図2において示したフロー図のステップ216による処理の流れについて説明する。図5は、本実施形態に係る情報処理装置100において、リフレッシュ処理部108が行う1ブロックリフレッシュ処理の流れを示すフロー図である。
【0098】
図5に示すように、リフレッシュ処理部108は、ステップ500において、RAM114に記録されている「変更検知フラグ」の値を「0」に更新する。また、リフレッシュ処理部108は、ECC補正処理によりエラー訂正を実行した回数を表す「リトライ回数」を「0」に更新する。詳細は後述する処理において説明するが、リフレッシュ処理部108は、例えば、ECC補正処理によりエラー訂正を行う際に、訂正限界を超えるエラーが検出された場合、エラー訂正を所定回数リトライすることができる。したがって、リフレッシュ処理部108は、「リトライ回数」の値を「0」に初期化して、例えば、RAM114などの記憶領域に記録しておくことができる。
【0099】
その後、リフレッシュ処理部108は、ステップ504において、1ブロックリフレッシュ処理の対象となるブロックに記録されているデータを読み出して、RAM114へ退避させる。ここでリフレッシュ処理部108は、データの読み出し中または読み出し後において、「変更検知フラグ」の値が「1」に更新されていないかを定期的に確認する(ステップ506)。上述したように、システム処理部106は、データの書き換えの対象となるブロックが、1ブロックリフレッシュ処理の対象となるブロックと同一である場合には、上述したステップ402において、「変更検知フラグ」の値を「1」に更新する。
【0100】
したがって、ステップ506により、「変更検知フラグ」の値が「1」に更新されたと判断された場合、リフレッシュ処理部108は、1ブロックリフレッシュ処理を中断し、ステップ528において「ランダム時間」が経過するまで処理を行わない。「ランダム時間」とは、システム処理部106によるデータの更新処理と、1ブロックリフレッシュ処理とが同一ブロックに対して同時に行われることにより発生するデータの不整合を防止するために、例えば、ROM112などに記録されている所定の時間である。リフレッシュ処理部108は、1ブロックリフレッシュ処理中に「変更検知フラグ」の値が「1」に更新された場合には、「ランダム時間」が経過するのを待ってから、再度1ブロックリフレッシュ処理を開始する。これにより、システム処理部106によるデータの更新処理と、1ブロックリフレッシュ処理とが同一ブロックに対して同時に行われることにより発生するデータの不整合を確実に防止することができる。
【0101】
なお、「ランダム時間」は、例えば、情報処理装置100の運営者などが任意に設定することができるものであり、特定の時間に限定されるものではない。また、「ランダム時間」は、例えば、ROM112などにあらかじめ設定しておくことや、情報処理装置100の運営者などにより任意に変更することも当然に可能である。
【0102】
一方、ブロックのデータをRAM114へ退避させた後に「変更検知フラグ」が「0」の状態である場合には、リフレッシュ処理部108は、ステップ508において、補正処理を実行する。具体的には、リフレッシュ処理部108は、RAM114へ退避させたデータに対してECC補正処理によるエラー検知・エラー補正を実行する。なお、リフレッシュ処理部108によるECC補正処理は、データのエラー検知および補正を行うことができるものであれば、特定の処理方法に限定されるものではない。
【0103】
ここで、リフレッシュ処理部108は、ECC補正処理によるエラー検知および補正の実行中において、「変更検知フラグ」の値が「1」に更新されていないかを定期的に確認する(ステップ510)。「変更検知フラグ」の値が「1」に更新されたと判断され場合、リフレッシュ処理部108は、上記処理と同様に、1ブロックリフレッシュ処理を中断し、ステップ528により「ランダム時間」が経過した後に、再度1ブロックリフレッシュ処理を再開する。これにより、システム処理部106によるデータの更新処理と、1ブロックリフレッシュ処理とが同一ブロックに対して同時に行われることにより発生するデータの不整合を確実に防止することができる。
【0104】
また、リフレッシュ処理部108は、ステップ512において、ECC補正処理によるエラー補正の結果を確認し、訂正限界を超えるエラーが検出されたか否かを判断する。上述したように、本実施形態においては、リフレッシュ処理部108は、ECC補正処理において訂正限界を超えるエラーが検出された場合は、所定回数ECC補正処理をリトライすることができる。したがって、ステップ512により、訂正限界を超えるエラーが検出されたと判断された場合、リフレッシュ処理部108は、ステップ530において、RAM114などに記録されている「リトライ回数」の値を1つ増加させる。
【0105】
その後、リフレッシュ処理部108は、ステップ532において、ステップ530により更新された「リトライ回数」が「リトライ制限回数」を超えているか否かを判断する。ここで、「リトライ制限回数」は、例えば、情報処理装置100の運営者などが任意に設定することができるものであり、特定の回数に限定されるものではない。また、「リトライ制限回数」は、例えば、ROM112などにあらかじめ設定しておくことや、情報処理装置100の運営者などにより任意に変更することも当然に可能である。
【0106】
ステップ532により、「リトライ回数」が「リトライ制限回数」を超えていないと判断された場合、リフレッシュ処理部108は、ステップ504に戻り、再度同一ブロックのデータに対してECC補正処理を実行する。これにより、例えば、バスにノイズが入っていた場合や、周辺温度の影響により一時的に訂正限界を超えるエラーが発生していた場合などは、リトライすることによりエラー補正を適切に行うことができる場合もある。
【0107】
一方、ステップ512により、訂正限界を超えるエラーが検出されなかった場合や、ステップ532により、「リトライ回数」が「リトライ制限回数」を超えていると判断された場合には、以下の処理によりデータの再書き込みが実行される。
【0108】
まず、ステップ514において、リフレッシュ処理部108は、「リフレッシュ処理優先度」を「高」に設定する。上述したように、リフレッシュ処理部108によりデータがフラッシュメモリ116に再書き込みされている間は、システム処理部106によるフラッシュメモリ116のデータの書き換え処理が実行されないようにする必要がある。したがって、リフレッシュ処理部108は、通常「低」に設定されている「リフレッシュ処理優先度」を「高」に更新する。このようにリフレッシュ処理部108により更新される「リフレッシュ処理優先度」は、優先度制御部110による優先度決定処理に利用されることとなる。なお、優先度制御部110による優先度決定処理の流れについては、後述する処理フローにおいて説明する。
【0109】
次に、リフレッシュ処理部108は、データの再書込みを行う直前に、ステップ516において、「変更検知フラグ」の値が「1」に更新されていないかを最終確認する。ここで、「変更検知フラグ」の値が「1」に更新されていると判断された場合、リフレッシュ処理部108は、ステップ518において、「リフレッシュ処理優先度」を「低」に戻し、ステップ528による「ランダム時間」の経過を待って、再度1ブロックリフレッシュ処理を実行する。
【0110】
一方、ステップ516により「変更検知フラグ」の値が「1」に更新されていないと判断された場合、リフレッシュ処理部108は、ステップ520において、RAM114に退避させているデータを、フラッシュメモリ116の同一ブロックに再書き込みする。この際、上述したステップ514により「リフレッシュ処理優先度」が「高」に設定されているため、優先度制御部110によりシステム処理部106の動作が制限される。したがって、リフレッシュ処理部108がデータの再書き込みを行っている最中は、システム処理部106による処理を制限することができ、データの不整合等の問題が発生することを防止することができる。
【0111】
データの再書き込みが終了すると、リフレッシュ処理部108は、ステップ524において、「リフレッシュ処理優先度」を「低」に戻す。これにより、システム処理部106は、フラッシュメモリ116のデータの読み書きなどの処理を実行することができるようになる。
【0112】
その後、リフレッシュ処理部108は、ステップ526において、1ブロックリフレッシュ処理の結果をログデータとして、例えば、フラッシュメモリ116などの記憶領域に記録する。記録されるログデータとしては、例えば、ビットエラーの発生回数、ブロックの読み出し/書き出しエラーの発生回数、ブロックの消去回数などが想定されるが特定のデータに限定されるものではない。情報処理装置100の運営者などは、このようにして記録されたログデータを閲覧したりすることにより、システムの信頼性などの分析に利用することができる。
【0113】
以上の処理フローにより、リフレッシュ処理部108は、フラッシュメモリ116を構成する複数のブロックのうちの1のブロックに対する1ブロックリフレッシュ処理を行うことができる。また、リフレッシュ処理部108は、「変更検知フラグ」の値が「1」である場合、すなわち、システム処理部106が同一ブロックのデータの書き換えを行っている場合には、1ブロックリフレッシュ処理を一時的に中断することができる。これにより、データの不整合等の問題が発生することを確実に防止することができる。また、リフレッシュ処理部108は、データの再書込みを行う際には、「リフレッシュ処理優先度」を通常の「低」から「高」に設定することができる。これにより、リフレッシュ処理部108がデータの再書込みを行っている場合にのみ、システム処理部106の動作が優先度制御部110により制限されるため、データの不整合等の問題が発生することを確実に防止することができる。
【0114】
(3−4.優先度制御部110による優先度決定処理フロー)
次に、優先度制御部110が、システム処理部106およびリフレッシュ処理部108のいずれか一方の動作を制限し、いずれか一方を優先的に動作させる処理の流れについて説明する。図6は、優先度制御部110が、システム処理部106およびリフレッシュ処理部108のいずれか一方の動作を制限し、いずれか一方を優先的に動作させる優先度決定処理フローの流れの一例を示すフロー図である。
【0115】
上述したように、優先度制御部110は、データの不整合が発生することを防止するために、リフレッシュ処理部108またはシステム処理部106のいずれか一方のみを動作せるように制御する。具体的には、優先度制御部110は、「リフレッシュ処理優先度」およびシステム処理部106の状態に基づいて、いずれの処理部を動作させるかを判断する。ここで、システム処理部106の状態は、例えば、利用者による指示や、携帯電話などがかざされることを待機する状態の「待機状態」と、実際にデータの書き換え処理の指示を受け付けて「待機状態」が解除された「実行状態」とに分類することができる。したがって、優先度制御部110は、ステップ600において、「リフレッシュ処理優先度」が更新された、または、システム処理部106の状態が更新されたと判断した場合に優先度決定処理を実行する。
【0116】
その後、優先度制御部110は、ステップ602において、「リフレッシュ処理優先度」が「低」に設定されているか否かを判断する。上述したように、通常「リフレッシュ処理優先度」は「低」に設定されており、リフレッシュ処理部108がデータの再書き込みを行う場合にのみ「高」に設定される。したがって、「リフレッシュ処理優先度」が「高」に設定されている場合は、優先度制御部110は、ステップ606において、リフレッシュ処理部を動作させることができる。これにより、リフレッシュ処理部108は、データの再書込みを行うことができる。また、「リフレッシュ処理優先度」が「高」に設定されている場合においては、優先度制御部110は、システム処理部106の動作を制限することができる。この結果、データの不整合が発生するという問題を回避することができる。
【0117】
また、ステップ602により、通常通り「リフレッシュ処理優先度」が「低」に設定されていると判断された場合、優先度制御部110は、ステップ604において、システム処理部106が「待機状態」であるか否かを判断する。システム処理部106が「待機状態」である場合、すなわち、システム処理部106がデータの書き換え等の指示を受けていない状態である場合には、優先度制御部110は、ステップ606において、リフレッシュ処理部108を動作させる。これによりリフレッシュ処理部108は、システム処理部106が「待機状態」の場合には、継続して上述したリフレッシュ処理を実行することができる。
【0118】
一方、ステップ604により、「実行状態」、すなわち、システム処理部106がデータの書き換え等の処理を実行している状態であると判断された場合、優先度制御部110は、ステップ608において、システム処理部106を継続的に動作させる。これによりシステム処理部106は、リフレッシュ処理部108が継続的にリフレッシュ処理を行っている場合においても、フラッシュメモリ116のデータの書き換え等の処理を優先して実行することができる。また、システム処理部106が処理を実行している場合には、優先度制御部110は、リフレッシュ処理部108の動作を制限することができる。この結果、データの不整合が発生するという問題を回避することができる。
【0119】
その後、システム処理部106による処理が終了し、再度システム処理部の状態が「待機状態」へ戻ると、ステップ600〜ステップ606により、優先度制御部110は、再度リフレッシュ処理部108を動作させることができる。
【0120】
以上の処理フローにより、優先度制御部110は、「リフレッシュ処理優先度」が「高」に設定されている場合を除いて、システム処理部106を優先的に動作させることができる。また、優先度制御部110は、「リフレッシュ処理優先度」が「高」に設定されている場合には、システム処理部106の動作を制限して、リフレッシュ処理部108を優先的に動作させることもできる。すなわち、優先度制御部110は、リフレッシュ処理部108と、システム処理部106の動作を制御することにより、データの不整合を確実に防止することができる。
【0121】
(4.まとめ)
以上、本実施形態に係る情報処理装置100の詳細について説明した。上述したように、本実施形態に係る情報処理装置100は、リフレッシュ処理部108を備えることにより、システム運用中であっても、定期的にフラッシュメモリ116に対してリフレッシュ処理を実行することができる。また、本実施形態に係る情報処理装置100は、優先度制御部110を備えることにより、システム処理部106による処理と、リフレッシュ処理部108による処理のいずれか一方を優先的に実行させることができる。また、通常はシステム処理部106による処理を優先的に実行させることにより、リフレッシュ処理によりシステム運用に悪影響を与えることを防止することができる。一方で、リフレッシュ処理部108によりデータがフラッシュメモリ116に再書き込みされている場合には、優先度制御部110は、リフレッシュ処理部108による処理を優先的に実行させることができる。これにより、データの不整合が発生することを確実に防止することができる。
【0122】
また、リフレッシュ処理部108は、リフレッシュ処理を実行するに際して、あらかじめ設定された「リフレッシュ期間」の間にリフレッシュ処理が終了するように、「1ブロックリフレッシュ周期時間」を算出してリフレッシュ処理を実行することができる。上述したように、リフレッシュ処理によりデータを再書き込みする際にはシステム処理部106による処理は制限される。したがって、このように、1ブロックリフレッシュ処理を算出した周期時間毎に実行することで、1ブロックリフレッシュ処理が短時間に集中して実行されることを回避することができ、システム運用に悪影響を与えることを防止することができる。
【0123】
このように、本実施形態に係る情報処理装置100は、システム運用中であっても、システムの運用に影響を及ぼすことなく効率よくリフレッシュ処理を行い、フラッシュメモリ116のデータ保持特性を高めることが可能である。また、システム処理部106、リフレッシュ処理部108、優先度制御部110は、CPU上で動作するソフトウェアで実現可能であるため、特別な回路構成や、別途新たなフラッシュメモリなどを搭載する必要もない。
【0124】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【0125】
例えば、上記実施形態において例示した設定値やパラメータは、上記実施形態を説明する上での一例であり、本発明はかかる例に限定されない。情報処理装置のシステム運営者は、このような設定値やパラメータを、例えばROM112などの不揮発性の記憶領域にあらかじめ任意に設定しておくことができ、システムの運用状況に応じて適宜これらの設定値やパラメータを更新することもできる。また、各種処理に応じて一時的に記録される各種情報は、必ずしもRAM114に記録される必要はなく、所定の不揮発性の記憶領域に記録されてもよい。この場合、例えば、情報処理装置の電源が一度切られた場合などにおいても、継続して各種処理を実行することもできる。
【図面の簡単な説明】
【0126】
【図1】本発明の実施形態の1つに係る情報処理装置100の機能構成を示すブロック図である。
【図2】同実施形態に係る情報処理装置100において行われるリフレッシュ処理の全体の処理の流れの一例を示すフロー図である。
【図3】同実施形態において、リフレッシュ処理部108が行うリフレッシュ開始判定処理の流れの一例を示すフロー図である。
【図4】同実施形態において、システム処理部106が行うデータ書き換えの処理の流れの一例を示すフロー図である。
【図5】同実施形態において、リフレッシュ処理部108が行う1ブロックリフレッシュ処理の流れの一例を示すフロー図である。
【図6】同実施形態において、優先度制御部110が行う優先度決定処理フローの流れの一例を示すフロー図である。
【符号の説明】
【0127】
100 情報処理装置
102 装置処理部
104 装置記憶部
106 システム処理部
108 リフレッシュ処理部
110 優先度制御部
112 ROM
114 RAM
116 フラッシュメモリ


【特許請求の範囲】
【請求項1】
データが記録されるフラッシュメモリと、
前記フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、
前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、
前記システム処理部および前記リフレッシュ処理部のいずれか一方を優先的に動作させる優先度制御部と、
を備える情報処理装置。
【請求項2】
前記フラッシュメモリは、データが記録される複数のブロックから構成され、
前記リフレッシュ処理部は、前記フラッシュメモリを構成する複数のブロックのうち、1ブロック毎に順次前記リフレッシュ処理を実行する、請求項1に記載の情報処理装置。
【請求項3】
前記優先度制御部は、前記システム処理部による処理を前記リフレッシュ処理部による処理より優先的に動作させ、
前記リフレッシュ処理部が前記フラッシュメモリにデータを再書き込みしている間のみ、前記リフレッシュ処理部による処理を前記システム処理部による処理より優先的に動作させる、請求項2に記載の情報処理装置。
【請求項4】
前記リフレッシュ処理部は、あらかじめ設定された期間であるリフレッシュ期間内に、前記フラッシュメモリを構成するすべてのブロックに対して前記リフレッシュ処理を実行する、請求項3に記載の情報処理装置。
【請求項5】
前記リフレッシュ処理部は、前記フラッシュメモリを構成するすべてのブロックに対して前記リフレッシュ処理を実行した場合、前記リフレッシュ期間毎に再度前記リフレッシュ処理を実行する、請求項4に記載の情報処理装置。
【請求項6】
前記リフレッシュ処理部は、前記リフレッシュ期間と、前記フラッシュメモリを構成するブロックの総数と、既に前記リフレッシュ処理が行われたブロックの数と、に基づいて、前記リフレッシュ処理が行われていない残りのブロックに対して前記リフレッシュ処理を実行する周期である1ブロックリフレッシュ周期時間を算出し、前記1ブロックリフレッシュ周期時間毎に前記残りのブロックに対して前記リフレッシュ処理を実行する、請求項5に記載の情報処理装置。
【請求項7】
前記リフレッシュ処理部は、前記フラッシュメモリを構成する複数のブロックのうち、1のブロックに対して前記リフレッシュ処理を実行する毎に、前記1ブロックリフレッシュ周期時間を算出する、請求項6に記載の情報処理装置。
【請求項8】
前記リフレッシュ処理部は、前記フラッシュメモリに記録されている所定の情報を読み出し、前記読み出した情報に基づいて前記フラッシュメモリに対して前記リフレッシュ処理が必要か否かを判断し、前記リフレッシュ処理が必要と判断した場合にのみ前記リフレッシュ処理を実行する、請求項7に記載の情報処理装置。
【請求項9】
前記情報処理装置は、所定のデータの読み出しおよび/または書き込みを行うリーダライタ装置である、請求項1〜8に記載の情報処理装置。
【請求項10】
フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、のいずれを優先的に動作させるか判断する優先度判断ステップと、
前記優先度判断ステップにより前記システム制御部を優先的に動作させると判断された場合に行われる、前記システム制御部が前記フラッシュメモリに記録されたデータの読み出し、または前記フラッシュメモリへのデータの書き込みを行うシステム処理ステップと、
前記優先度判断ステップにより前記リフレッシュ処理部を優先的に動作させると判断された場合に行われる、前記リフレッシュ処理部が前記リフレッシュ処理を実行するリフレッシュ処理ステップと、
を含む情報処理方法。
【請求項11】
フラッシュメモリに記録されたデータの読み出し、および前記フラッシュメモリへのデータの書き込みを行うシステム処理部と、前記フラッシュメモリに記録されたデータに対してエラー検出を行い、エラー検出されたデータを訂正した後に、前記フラッシュメモリに再書き込みするリフレッシュ処理を実行するリフレッシュ処理部と、のいずれを優先的に動作させるか判断する優先度判断処理と、
前記優先度判断処理により前記システム制御部を優先的に動作させると判断された場合に実行される、前記システム制御部が前記フラッシュメモリに記録されたデータの読み出し、または前記フラッシュメモリへのデータの書き込みを行うシステム処理と、
前記優先度判断ステップにより前記リフレッシュ処理部を優先的に動作させると判断された場合に行われる、前記リフレッシュ処理部が実行する前記リフレッシュ処理と、
をコンピュータに実行させる情報処理プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2010−67098(P2010−67098A)
【公開日】平成22年3月25日(2010.3.25)
【国際特許分類】
【出願番号】特願2008−234059(P2008−234059)
【出願日】平成20年9月11日(2008.9.11)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】