JP2010067010A - 組み込み機器、不揮発性メモリの自動リフレッシュ方法およびプログラム - Google Patents

Description

本発明は、ファームウェアとして不揮発性メモリに格納されたプログラムを実行する組み込み機器において、その不揮発性メモリの長寿命化を可能とした、不揮発性メモリの自動リフレッシュ技術に関する。

フラッシュＲＯＭ等の不揮発性メモリは、電源を切ってもデータが保存されることから、組み込み機器のファームウェア格納手段として多く利用されている。しかし、不揮発性メモリは、経年変化によってデータ化けが発生することがあり、データ化けが発生すると格納したファームウェアが正常動作しなくなってしまう、という問題がある。

組み込み機器の多くは製品寿命が長く、プログラムの更新頻度も少ないことから、この問題に対する何らかの対策が必要である。
なお、関連する技術として、特許文献１には、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）に格納したプログラムを一時的にＲＡＭ（Random Access Memory）上に転送し、転送後、ＲＡＭ上のプログラムをＥＥＰＲＯＭに再度書き込みを行なうことで、プログラムのリフレッシュを行なう方法が提案されている。

しかし、特許文献１の方法では、ＥＥＰＲＯＭ上のプログラムの格納領域が固定されているために、その領域が物理的特性の経年変化によるデータ化けの可能性が大きくなるという問題がある。また、ＲＡＭ上にあるプログラムをＥＥＰＲＯＭ上に再度書き込みする際に、電源断が発生すると、ＥＥＰＲＯＭ上のプログラムが壊れてしまう、という問題もある。また、ＥＥＰＲＯＭの寿命が考慮されていない点、プログラムを一時的に確保する領域をＲＡＭ上に確保する必要がある点、保守ツールのリフレッシュ指令によってリフレッシュを手動で実行する点、において利便性などに問題がある。
特開平１０−２４１３７９号公報

本発明は、不揮発性メモリに格納されたプログラムを自動でリフレッシュする（自動で書き換える）ことにより、経年変化によるデータ化けを防止し、組み込み機器の長期の製品保証を実現する組み込み機器、不揮発性メモリの自動リフレッシュ方法およびプログラムを提供することを目的とする。

提案する組み込み機器は、ファームウェアとして不揮発性メモリに格納されたプログラム、を実行するものである。この不揮発性メモリは、複数の、リード／ライト可能な固定サイズのブロックに分割され、上記プログラムは格納手段により上記複数のブロックのうちの一つあるいは複数以上にまたがるように分割して格納される。そして、その格納手段により分割して格納された上記プログラムを、上記各ブロックから別のブロックへと移動させることにより、上記不揮発性メモリ内をリフレッシュさせるリフレッシュ実行部、を有する。

上記リフレッシュ実行部は、上記不揮発性メモリの各ブロックに格納されたプログラムに対し、１ブロックのデータを上記不揮発性メモリの空きブロックにコピーするコピー処理部と、上記コピーのコピー元の１ブロックのデータを消去する消去処理部と、を有し、上記プログラムを格納する全てのブロックを、ブロックごとに上記コピー処理部によるコピー処理と上記消去処理部による消去処理を繰り返す。

提案する組み込み機器によれば、プログラムを不揮発性メモリ内でリフレッシュする度にアプリケーション・プログラムを格納するブロック範囲が移動していくので、不揮発性メモリの使用頻度が平滑化でき、不揮発性メモリの経年変化に起因してアプリケーション・プログラムが誤動作する時期を遅らせることができ、不揮発性メモリの寿命を長期化すること（長期の製品保証）が可能となる。

以下図面に基づいて、本発明の実施形態について詳細を説明する。
図１は、本発明の一実施形態に係るブートプログラムおよびアプリケーション・プログラムが格納された組み込み機器の構成例を示すブロック図である。

図１の組み込み機器は、ＣＰＵ（Central Processing Unit）１、ＳＤＲＡＭ（Synchronous Dynamic RAM）４、外部フラッシュＲＯＭ５、ＲＴＣ（Real Time Clock）６、により構成され、ＣＰＵ１は、ＣＰＵ内蔵ＲＡＭ２、ＣＰＵ内蔵フラッシュＲＯＭ３を備える。

このうち、ＣＰＵ内蔵フラッシュＲＯＭ３は、ブートプログラムを格納し、外部フラッシュＲＯＭ５は、リフレッシュ対象のアプリケーション・プログラムを格納する。また、ＳＤＲＡＭ４は、外部フラッシュＲＯＭ５に格納したアプリケーション・プログラムの実行領域である。また、ＲＴＣ６は、現在時刻を書き込む処理を行なう。

なお、ブートプログラムは、外部フラッシュＲＯＭ５に格納したアプリケーション・プログラムをＳＤＲＡＭ４で実行するためのプログラムである。また、アプリケーション・プログラムは、組み込み機器のファームウェアとしての本来の処理の他に、本実施形態のリフレッシュ処理（図９にて後述）、電源断時の再リフレッシュ処理（図１０〜図１２にて後述）を実行するためのプログラムである。

図２は、図１の外部フラッシュＲＯＭのブロック構成を示す図である。
図２に示すように、外部フラッシュＲＯＭ５は、リード／ライト可能な固定サイズの複数のブロックに分割されている。そして、上記アプリケーション・プログラムは、その複数のブロックのうちの１以上のブロックに分割して格納されている。

１ブロックは、定コード１０、リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２、第１のＳＵＭ値１３、プログラム１４、第２のＳＵＭ値１５、によって構成される。
なお、外部フラッシュＲＯＭ５中のブロックには、空きブロック９も存在するが、空きブロックであるかどうかは、以下に述べるように定コード１０の値により判断する。

定コード１０は、アプリケーション・プログラムの先頭、終端および中間ブロックを判別するためのコードである。以下に、定コード１０が取りうる値を示す。
・“ＳＴＡＲＴ”：先頭ブロック
・“ＥＮＤ”：終端ブロック
・ＮＵＬＬ：中間ブロック
・０ｘＦＦ：空きブロック（※０ｘＦＦは、ブロックサイズを規程するものでは無く、未使用である事を指す。一例として、第１のＳＵＭ値１３、第２のＳＵＭ値１５は２バイトで、リフレッシュ実施時刻１２は４バイトだったとしても、以降の説明では未使用の状態としては“０ｘＦＦ”を用いる。）
リフレッシュ状態フラグ１１は、リフレッシュ状態を判別するためのフラグであり、値は例えば「０」または「１」とする。リフレッシュ状態フラグについては、リフレッシュ時にコピー元ブロックと異なる値をコピー先ブロックに書き込むようにする。

リフレッシュ実施時刻１２は、リフレッシュを最後に実施した時刻を示す。
第１のＳＵＭ値１３は、プログラム１４のチェックサム値である。これは、例えば、プログラム１４の各バイトを加算して求める。

プログラム１４は、アプリケーション・プログラムのプログラムを分割したうちの１つである。
第２のＳＵＭ値１５も、第１のＳＵＭ値１３と同様に、例えば、プログラム１４のチェックサム値である。したがって、共に有効な値が設定されている限り、第１のＳＵＭ値１３と第２のＳＵＭ値１５は同値である。

そして、このうち、定コード１０、第１のＳＵＭ値１３、プログラム１４、第２のＳＵＭ値１５は、外部フラッシュＲＯＭ５にアプリケーション・プログラムを格納する際に各ブロックに書き込む。

本実施形態の要点は、不揮発性メモリ（外部フラッシュＲＯＭ５）をリード／ライト可能な固定サイズのブロックに分割し、アプリケーション・プログラムをそれらブロックに連続して格納し、そのアプリケーション・プログラムを外部フラッシュＲＯＭ５内でリフレッシュするものである。

アプリケーション・プログラムが格納された状態で、外部フラッシュＲＯＭ５は１つまたは複数の空きブロックを持つものとする。すなわち、ブロック総数が（ｎ+1）個の場合、プログラムの分割数は最大でもｎ個となる。また、１つのブロックのサイズがｍバイトの場合、定コード１０、リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２、第１のＳＵＭ値１３、第２のＳＵＭ値１５のそれぞれのサイズをｍバイトから引いた残りが、分割したプログラムの最大サイズとなる。

そして、アプリケーション・プログラムを外部フラッシュＲＯＭ５内でリフレッシュするに際しては、そのアプリケーション・プログラムのプログラムを格納する先頭の１ブロックを空きブロックの先頭の１ブロックにコピーし、コピーが完了すると、コピー元の１ブロックを消去する。

アプリケーション・プログラムを格納する先頭のブロックから終端のブロックまでブロックごとにこの処理を繰り返す。この結果、リフレッシュの度にアプリケーション・プログラムを格納するブロック範囲が移動していくので、不揮発性メモリの使用頻度が平滑化できる。これに対して、不揮発性メモリ（外部フラッシュＲＯＭ５）をリフレッシュさせずに放置しておくと、その経年変化に起因してアプリケーション・プログラムが誤動作する時期が早まる。このように、本発明では不揮発性メモリの寿命を長期化すること（長期の製品保証）が可能である。

また、後述するように、リフレッシュ処理がアプリケーション・プログラムの処理の一部となっているため、手動でリフレッシュする必要がなく、メンテナンス性が向上する。また、アプリケーション・プログラムを格納した不揮発性メモリ内でそのアプリケーション・プログラムを１ブロックずつリフレッシュする（コピー先ブロックへコピーし、コピー元ブロックを消去する）ため、ＲＡＭ等の他のメモリにプログラムバックアップ用のワーク領域を確保する必要がなく、リソースの最小化に貢献できる。また、不揮発性メモリ上に空きブロックが最低限１ブロックあれば、本実施形態のリフレッシュ処理を実行できるので、不揮発性メモリの領域を有効に使用することができる。

なお、データのコピーの際には、１ブロックを構成する、定コード１０、リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２、第１のＳＵＭ値１３、プログラム１４、第２のＳＵＭ値１５は、例えば、この順にデータが処理対象ブロックに書き込まれる。

また、１ブロックを消去する際は、定コード１０〜第２のＳＵＭ値１５の値をすべて“０ｘＦＦ”に変更する。
そして、本実施形態では、リフレッシュ中に電源断が発生した場合に、上記した各ブロックが有する、プログラム１４およびプログラム１４以外のデータ部分の値を参照して、電源断がリフレッシュ処理のどの段階で発生したかを判定し、アプリケーション・プログラムを破壊することなく、再リフレッシュを行なうものである。

続いて、リフレッシュ中に電源断が発生した各ケースについて、図３〜図６を参照して説明する。
図３は、ブロックのコピーとコピー元ブロックの消去（空きブロックの生成）が終了したところで電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。

図３の例では、外部フラッシュＲＯＭ５は８ブロックに分割され、そのうちの連続する５ブロックにアプリケーション・プログラムが格納されている。ここでは、説明の都合上、プログラムが格納される各ブロックに対し、プログラムが格納されているブロックをプログラムの先頭から順に、「１」、「２」、・・・、「５」と番号を付ける。また、図３における“SUM”とは、対象の値を足し合わせたいわゆる“ＳＵＭ値”を指すが、ここでは具体的な数値ではなく便宜上“ＳＵＭ”と表している。同様に、リフレッシュ実施時刻１２の値における“−”の表示箇所には時刻情報が格納されているが、便宜上、“−”と表示している。

図３の例では、アプリケーション・プログラムの中間のプログラムの格納領域である「３」のブロックが外部フラッシュＲＯＭ５の物理アドレスの末尾に位置しているので、続く、アプリケーション・プログラムのプログラムの格納領域である「４」のブロックは、外部フラッシュＲＯＭ５の物理アドレスの先頭に来る。アプリケーション・プログラムのプログラムが格納された「４」のブロック２１と、続く「５」のブロック２２の間で、リフレッシュ状態フラグの値が“１”から“０”に変化していることから、「４」のブロック２１へのコピーと、コピー元ブロックの消去（すなわち、空きブロックのうち図の一番右側で、空きブロック２３の生成）が終了したところで電源断が発生したことが判明する。

図４は、ブロックのコピーにおけるリフレッシュ状態フラグコピー完了後の処理実行中に電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。
図４の例では、前の方の「５」のブロック２４と、後の方の「５」のブロック２５の間で、リフレッシュ状態フラグの値が“１”から“０”に変化していて、かつ、前の方の「５」のブロック２４の第２のＳＵＭ値１５の値が“０ｘＦＦ”であることから、後の方の「５」のブロック２５をコピー元として、前の方の「５」のブロック２４にコピー中に、第２のＳＵＭ値１５の処理中に電源断が発生したことが判明する。

図５は、ブロックのコピーにおけるリフレッシュ状態フラグの処理実行中に電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。
図５の例では、前の方の「５」のブロック２６では、リフレッシュ状態フラグの項目以降の値がすべて“０ｘＦＦ”であるのに対して、後の方の「５」のブロック２７では、リフレッシュ状態フラグの値が“０”である。これから、後の方の「５」のブロック２７をコピー元として、前の方の「５」のブロック２６にコピー中に、リフレッシュ状態フラグ１１の処理中に電源断が発生したことが判明する。

図６は、ブロックのコピーが終了したところで電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。
図６の例では、前の方の「５」のブロック２８と、後の方の「５」のブロック２９の間で、リフレッシュ状態フラグの値が“１”から“０”に変化していて、それ以外の項目の値については２つの「５」のブロックで同一となっている。これから、後の方の「５」のブロック２９をコピー元として、前の方の「５」のブロック２８へのコピーが終了した時点で電源断が発生したことが判明する。

図７は、ブートプログラムの実行シーケンスを示すフローチャートである。
なお、外部フラッシュＲＯＭ５内で、定コード＝“ＳＴＡＲＴ”であるブロックは、電源断に起因するデータ化けの場合を除いては１つしかないことがこのフローチャートの処理の前提となっている。

図７のステップＳ１で、ハードウェアおよびソフトウェアの各種初期化が行われる。
続く、ステップＳ２では、外部フラッシュＲＯＭ５に格納されたアプリケーション・プログラムの先頭ブロックが検索される。すなわち、定コード１０＝“ＳＴＡＲＴ”であるブロックが検索される。

なお、検索方法としては、原則として、図２に示す物理アドレスを“０ｘ００００００”→“０ｘＦＦＦＦＦＦ”の方向にインクリメントしていき、“０ｘＦＦＦＦＦＦ”まで達した場合、再度“０ｘ００００００”から検索するようにする。

ステップＳ２に続くステップＳ３では、先頭ブロックがあったかどうかが判定される。
ステップＳ３で先頭ブロックが見つからなかったと判定された場合（ステップＳ３の判定結果がＮｏの場合）、例えばエラーとして、一連の処理を終了する。

ステップＳ３で先頭ブロックが見つかったと判定された場合（ステップＳ３の判定結果がＹｅｓの場合）、ステップＳ４において、上述の通りアドレスの上流側から下流側に向けて検索しても良いが、物理アドレスをインクリメントする方向とデクリメントする方向との双方向に検索しても構わない。これは、先頭ブロックに近い場所に検索対象がある可能性が高いからである。ここで、ステップＳ３で見つかった先頭ブロックの前後に定コード１０＝“ＳＴＡＲＴ”であるもうひとつのブロックがあるかどうか（ステップＳ５）が判定される。

ステップＳ５においてそのもうひとつのブロックがないと判定された場合、ステップＳ７で、ステップＳ３で見つかったブロックを、アプリケーション・プログラムの先頭ブロックとして決定し、ステップＳ８に進む。

ステップＳ５においてそのもうひとつのブロックがあると判定された場合、ステップＳ６で、ステップＳ４で見つかったブロックのリフレッシュ実施時刻と、ステップＳ２で見つかったブロックのリフレッシュ実施時刻とを比較し、時刻が古い方のブロックを、アプリケーション・プログラムの先頭ブロックとして決定し、ステップＳ８に進む。これは、図２のリフレッシュ実施時刻１２以降の項目（第１のＳＵＭ値１３、プログラム１４、第２のＳＵＭ値１５）のいずれかの処理中に電源断が発生した場合に相当する。

なお、ステップＳ６において、ステップＳ４で見つかったブロックのリフレッシュ実施時刻と、ステップＳ２で見つかったブロックのリフレッシュ実施時刻のいずれか一方の値が“０ｘＦＦ”であった場合は、図２のリフレッシュ実施時刻１２以前の項目（リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２）のいずれかの処理において電源断が発生した場合に相当する。この場合、リフレッシュ実施時刻の値が“０ｘＦＦ”であるブロックを時刻が新しい方のブロックとみなす。

ステップＳ６またはステップＳ７から制御を渡されたステップＳ８では、その先頭ブロック内のプログラム１４から算出したＳＵＭ値（チェックサム値）が、その先頭ブロック内の第１のＳＵＭ値１３に一致するかどうか、すなわち、その先頭ブロック内の第１のＳＵＭ値１３が正しいものであるかどうかが判定される。

ステップＳ８においてその先頭ブロック内の第１のＳＵＭ値１３が正しいものではないと判定された場合、プログラムと算出したＳＵＭ値との不整合によるエラーとして一連の処理を終了する。

ステップＳ８においてその先頭ブロック内の第１のＳＵＭ値１３が正しいものであると判定された場合、ステップＳ９において、その先頭ブロックをＳＤＲＡＭ４に転送する。
そして、続くステップＳ１０において、ステップＳ９でＳＤＲＡＭ４に転送したブロックが最終ブロックであるかどうか、すなわち、その転送したブロックの定コードの値が“ＥＮＤ”であるかどうかが判定される。

ステップＳ１０で転送したブロックが最終ブロックであると判定された場合、ステップＳ１２で転送したアプリケーション・プログラムを実行する。すなわち、制御がアプリケーション・プログラムに移る。

ステップＳ１０で転送したブロックが最終ブロックではないと判定された場合、ステップＳ１１で定コード１０＝“ＮＵＬＬ”または定コード１０＝“ＥＮＤ”である次のプログラムの格納ブロックが検索される。

そして、ステップＳ８に戻り、ステップＳ１１で見つかった次のブロックに対し、ステップＳ８以降の処理が繰り返される。
図８は、アプリケーション・プログラムの実行シーケンスを示すフローチャートである。

図８のステップＳ２１で、電源断時の再リフレッシュ処理が実行される。なお、再リフレッシュ処理の詳細については、図１０〜図１２を参照して後述する。
続く、ステップＳ２２では、外部フラッシュＲＯＭ５に格納されたアプリケーション・プログラムの先頭ブロックが検索される。すなわち、定コード１０＝“ＳＴＡＲＴ”であるブロックが検索される。

ステップＳ２２に続くステップＳ２３では、見つかった先頭ブロックのリフレッシュ実施時刻１２の値が取得され、ステップＳ２４でＲＴＣ６により現在時刻が取得される。そして、ステップＳ２５で、ステップＳ２３のリフレッシュ実施時刻１２の値と、ステップＳ２４の現在時刻との差分がとられて、経過時間が算出される。

ステップＳ２５に続くステップＳ２６では、算出された経過時間が予め定められた閾値より大きいかどうかを比較することで、リフレッシュの実行周期に到達したかどうかが判定される。ここで、閾値はどのような値でも設定可能だが、実際の運用に即して、例えば週末／月末／年末などのタイミングや夜間などの負荷状態の低い時間帯になるように設定するのが好ましい。また、アプリケーションプログラムに固定で定義しておいても良いし、専用のファームウェアを用意してユーザが設定し、この値をアプリケーションから読み込めるようにしておいても構わない。

ステップＳ２６でリフレッシュの実行周期に到達したと判定された場合（ステップＳ２６の判定結果がＹｅｓの場合）、ステップＳ２７で、リフレッシュ処理が実行される。なお、このリフレッシュ処理については、図９で説明する。

一方、ステップＳ２６でリフレッシュの実行周期に到達していないと判定された場合（ステップＳ２６の判定結果がＮｏの場合）、ステップＳ２８で、アプリケーション・プログラムの本来のファームウェアとしての処理（製品個別処理）が行われて、ステップＳ２４に戻る。

図９は、図８のリフレッシュ処理の詳細フローチャートである。
図９のステップＳ３１では、外部フラッシュＲＯＭ５に格納されたアプリケーション・プログラムの先頭ブロックが検索される。すなわち、定コード１０＝“ＳＴＡＲＴ”であるブロックが検索される。

続く、ステップＳ３２では、先頭の空きブロックが検索される。すなわち、定コード１０＝“０ｘＦＦ”であるブロックのうちの物理アドレスが最も小さいものが検索される。
ステップＳ３２に続くステップＳ３３では、ステップＳ３１の検索により見つかった（コピー元の）対象ブロック、あるいは、後述のステップＳ３６の検索により見つかった対象ブロックを読み出して、リフレッシュ状態フラグ１１とリフレッシュ実施時刻１２とを更新する。すなわち、リフレッシュ状態フラグ１１の値としてコピー元とは異なる値をコピー先に設定するようにし、ＲＴＣ６により取得された、その読み出しを行った時刻を、リフレッシュ実施時刻１２の値として設定する。そして、ステップＳ３２の検索により見つかった（コピー先の）空きブロック、あるいは、後述のステップＳ３７の検索により見つかった空きブロックに、更新後のリフレッシュ状態フラグ１１とリフレッシュ実施時刻１２とを含むコピー元のブロックのデータを書き込む。

ステップＳ３３に続くステップＳ３４では、（コピー元の）対象ブロックを消去する。すなわち、対象ブロックの定コード１０〜第２のＳＵＭ値１５の値をすべて“０ｘＦＦ”に設定する。

続く、ステップＳ３５では、コピー先のブロックの定コード１０の値が参照されて、そのコピー先のブロックが最終ブロックであるかどうか、すなわち、そのコピー先のブロックの定コード１０＝“ＥＮＤ”であるかどうかが判定される。

ステップＳ３５でコピー先のブロックの定コード１０＝“ＥＮＤ”ではないと判定された場合（ステップＳ３５の判定結果がＮｏの場合、ステップＳ３５が最初に実行されるときは通常このように判定される）、ステップＳ３６において、定コード１０＝“ＮＵＬＬ”または定コード１０＝“ＥＮＤ”である次のプログラムの格納ブロック（リフレッシュ対象のブロック）が検索される。このとき、先のリフレッシュ対象ブロックの位置からインクリメント方向に検索される。続いて、ステップＳ３７において、定コード１０＝“０ｘＦＦ”である次の空ブロックが検索される。このとき、先の空きブロック（この時点では、先のリフレッシュ対象ブロックが書き込まれている）からインクリメント方向に検索される。なお、ステップＳ３６やステップＳ３７において、アドレスの最後までインクリメントしても対象が無いときは、先頭アドレスからインクリメント方向に検索を続ける。また、ここではインクリメント方向としたが、検索方向をデクリメントに統一しても構わない。

そして、ステップＳ３３に戻り、ステップＳ３３以降の処理が、その次のリフレッシュ対象のブロックに対して繰り返される。
一方、ステップＳ３５でコピー先のブロックの定コード１０＝“ＥＮＤ”であると判定された場合（ステップＳ３５の判定結果がＹｅｓの場合）、ステップＳ３８において、自動でリブートする。すなわち、制御がブートプログラムに移り、アプリケーション・プログラムのＳＤＲＡＭへの転送が再度行われる。フラッシュＲＯＭでの実行速度は遅いので、ＳＤＲＡＭへアプリケーション・プログラムを転送して実行する必要があるためである。

図１０、図１１、および図１２は、図８の電源断時の再リフレッシュ処理の詳細フローチャートである。
図１０のステップＳ４１では、外部フラッシュＲＯＭ５上の不完全な空きブロックが検索される。なお、「不完全な空きブロック」とは、空きブロックを作る処理中（コピー元ブロックの消去の処理中）に電源断が発生することで外部フラッシュＲＯＭ５上に生じるブロックである。したがって、「不完全な空きブロック」を判定する条件としては、定コード＝“０ｘＦＦ”であり、以降の項目のいずれか、あるいは以降がすべて“０ｘＦＦ”でないことになるが、処理負荷の軽減（判定処理の簡略化）の意味で、例えば次のような判定条件を採用してもよい。
・定コード１０＝“０ｘＦＦ”であり、プログラム１４≠“０ｘＦＦ”であるブロック
・定コード１０＝“０ｘＦＦ”であり、プログラム１４＝“０ｘＦＦ”であり、第２のＳＵＭ値１５≠“０ｘＦＦ”であるブロック ここでは後者を用い、図１０でも、これを用いて説明している。

続く、ステップＳ４２では、外部フラッシュＲＯＭ５に格納されたアプリケーション・プログラムの先頭ブロックが検索される。すなわち、定コード１０＝“ＳＴＡＲＴ”であるブロックが検索される。また、ステップＳ４２ではさらに、見つかった先頭ブロックに対して、物理アドレスをインクリメントする方向とデクリメントする方向との双方向に検索することで、既に見つかった先頭ブロックの前後に定コード１０＝“ＳＴＡＲＴ”であるもうひとつのブロックがあるかどうかが判定される。

ステップＳ４２に続くステップＳ４３では、同じブロックがないと判定された場合、ステップＳ４６で、ステップＳ４２で見つかったブロックを、アプリケーション・プログラムの先頭ブロックとして決定し、ステップＳ４７に進む。

ステップＳ４３においてそのもうひとつのブロックがあると判定された場合、ステップＳ４４で、ステップＳ４２で見つかった２つのブロックのリフレッシュ実施時刻を比較し、時刻が古い方のブロックを、アプリケーション・プログラムの先頭ブロックとして決定し（いずれか一方のリフレッシュ実施時刻の値が“０ｘＦＦ”であった場合、ステップＳ６と同様に、そのリフレッシュ実施時刻の値が“０ｘＦＦ”である方を時刻が新しいものとする）、ステップＳ４５で、リフレッシュ実施時刻が新しい方のブロックを消去して、ステップＳ４７に進む。

ステップＳ４６またはステップＳ４５から制御を渡された図１１のステップＳ４７では、現在のブロック（ステップＳ４７が最初に実行される場合は、現在のブロック＝先頭ブロック）のリフレッシュ状態フラグ１１の値が取得され、続く、ステップＳ４８では、現在のブロックの次のブロックのリフレッシュ状態フラグ１１の値が取得される。

そして、続くステップＳ４９において、ステップＳ４７で取得した現在のブロックのリフレッシュ状態フラグ１１の値と、ステップＳ４８で取得した現在のブロックの次のブロックのリフレッシュ状態フラグ１１の値とが一致するかどうかが判定される。

ステップＳ４９において現在のブロックのリフレッシュ状態フラグ１１の値と次のブロックのリフレッシュ状態フラグ１１の値とが一致すると判定された場合（ステップＳ４９の判定結果がＹｅｓの場合）、ステップＳ５０において、現在のブロックが１ブロック進められ、ステップＳ５１において、ステップＳ５０で進められた現在のブロックが終端ブロックを超えたかどうかが判定される。

ステップＳ５１で現在のブロックが終端ブロックを超えたと判定された場合（ステップＳ５１の判定結果がＹｅｓの場合）、一連の処理を終了する。
ステップＳ５１で現在のブロックが終端ブロックを超えていないと判定された場合（ステップＳ５１の判定結果がＮｏの場合）、ステップＳ４７に戻り、ステップＳ５０で進められた現在のブロックに対し、ステップＳ４７以降の処理が繰り返される。

一方、ステップＳ４９において現在のブロックのリフレッシュ状態フラグ１１の値と次のブロックのリフレッシュ状態フラグ１１の値とが一致しないと判定された場合（ステップＳ４９の判定結果がＮｏの場合）、ステップＳ５２において、不一致ブロック内でデータの整合性がとれているかどうかが判定される。なお、「不一致ブロック」とは、ステップＳ４９における次のブロック（この次のブロックでは、現在のブロックとリフレッシュ状態フラグ１１の値とが一致しない）のことである。また、ステップＳ５２では、判定処理の簡略化のために、「判定条件：第１のＳＵＭ１３値＝第２のＳＵＭ値１５、かつ、プログラム１４≠“０ｘＦＦ”」を採用しているが、次のブロックにおいて、データが最後まで正常に書き込まれなかったことを検出可能とする任意の条件を採用可能である。

例えば、上述の図３のケースでは、「４」のブロック２１を現在のブロックとし、「５」のブロック２２を次のブロックとしてステップＳ４９の判定を行ったときに、判定結果がＮｏとなり、ステップＳ５２に進む。この場合、「５」のブロック２２では整合性がとれている（データ書き込み中に電源断が発生した痕跡は認められない）ため、ステップＳ５２では整合性がとれていると判定される。

また、上述の図４のケースでは、前の方の「５」のブロック２４を現在のブロックとし、後の方の「５」のブロック２５を次のブロックとしてステップＳ４９の判定を行ったときに、判定結果がＮｏとなり、ステップＳ５２に進む。この場合、後の方の「５」のブロック２５では整合性がとれている（データ書き込み中に電源断が発生した痕跡は認められない）ため、ステップＳ５２では整合性がとれていると判定される。

また、上述の図５のケースでは、「４」のブロック３０を現在のブロックとし、「５」のブロック２６を次のブロックとしてステップＳ４９の判定を行ったときに、判定結果がＮｏとなり、ステップＳ５２に進む。この場合、「５」のブロック２６では整合性がとれていない（データ書き込み中にリフレッシュ状態フラグのところで電源断が発生した）ため、ステップＳ５２では整合性がとれていないと判定される。

フローチャートの説明に戻る。
ステップＳ５２において不一致ブロック内で整合性がとれていると判定された場合（例えば図３や図４のようなケース）、ステップＳ５３において、現在のブロック内で整合がとれているかどうかが判定される。なお、ステップＳ５３においてもステップＳ５２と同様に、判定処理の簡略化のために、「判定条件：第１のＳＵＭ値１３＝第２のＳＵＭ値１５、かつ、プログラム１４≠“０ｘＦＦ”」を採用しているが、現在のブロックにおいて、データが最後まで正常に書き込まれなかったことを検出可能とする任意の条件を採用可能である。

例えば、上述の図３のケースでは、「４」のブロック２１が現在のブロックに相当する。「４」のブロック２１内のデータは整合性がとれているため、ステップＳ５３においても、整合性がとれていると判定される。

また、上述の図４のケースでは、前の方の「５」のブロック２４が現在のブロックに相当する。前の方の「５」のブロック２４内のデータは整合性がとれていない（第２のＳＵＭ値の書き込み中に電源断が発生した）ため、ステップＳ５３においても、整合性がとれていないと判定される。

ステップＳ５３において現在のブロック内で整合がとれていると判定された場合、ステップＳ５５において、両ブロック（すなわち、現在のブロックと次のブロック）のプログラムは同一かどうかが判定される。

ステップＳ５５において両ブロックのプログラムが同一であると判定された場合、ステップＳ５６で、両ブロックにおけるリフレッシュ実施時刻を比較し、時刻が古い方のブロックを消去し、ステップＳ６５に進む。

例えば、上述の図６のケースでは、前の方の「５」のブロック２８が現在のブロックに相当し、後の方の「５」のブロック２９が次のブロックに相当する。そして、前の方の「５」のブロック２８と、後の方の「５」のブロック２９とではプログラムは同一である。この場合、リフレッシュ実施時刻が古い後の方の「５」のブロック２９が消去される。

ステップＳ５５において両ブロックのプログラムが同一ではないと判定された場合、ステップＳ６５に進む。
例えば、上述の図３のケースでは、「４」のブロック２１が現在のブロックに相当し、「５」のブロック２２が次のブロックに相当する。そして、「４」のブロック２１と、「５」のブロック２２とではプログラムは当然のこととして基本的に同一ではない。

上述のステップＳ５２やＳ５３で判定がＮｏの場合、すなわち、ステップＳ５２において不一致ブロック内で整合がとれていないと判定された場合（例えば図５のようなケース）、または、ステップＳ５３において現在のブロック内で整合がとれていないと判定された場合（例えば図４のようなケース）、ステップＳ５４において、その不整合ブロックを消去し、ステップＳ６５に進む。

例えば、図４の場合、前の方の「５」のブロック２４が不整合ブロックであり、図５の場合、「５」のブロック２６が不整合ブロックである。
ステップＳ５４、Ｓ５５、またはＳ５６から制御を渡された図１２のステップＳ６５では、現在のブロックにおいて、定コード１０＝“ＥＮＤ”であるか否かを判定する。

判定がＹｅｓの場合は、ステップＳ６４に進み、自動でリブートする。すなわち、制御がブートプログラムに移り、アプリケーション・プログラムのＳＤＲＡＭへの転送が再度行われる。

例えば、図６の場合、前の方の「５」のブロック２８と、後の方の「５」のブロック２９とではプログラムは同一であり、先のステップＳ５６にて、リフレッシュ実施時刻が古い後の方の「５」のブロック２９が消去されている。これにより、電源断による不整合は解消し、リフレッシュが正常に完了したことになる。

一方で、上述のステップＳ６５で判定がＮｏの場合、ステップＳ５７に進む。
ステップＳ５７では、現在のブロックを基準にして、定コード１０＝“ＮＵＬＬ”または定コード１０＝“ＥＮＤ”である次のプログラムの格納ブロック（リフレッシュ対象のブロック）が検索される。

続く、ステップＳ５８では、先頭の空きブロックが検索される。すなわち、定コード１０＝“０ｘＦＦ”であるブロックのうちの物理アドレスが最も小さいものが検索される。
ステップＳ５８に続くステップＳ５９では、ステップＳ５７の検索により見つかった（コピー元の）対象ブロック、あるいは、後述のステップＳ６２の検索により見つかった対象ブロックを読み出して、リフレッシュ状態フラグ１１とリフレッシュ実施時刻１２とを更新する。すなわち、リフレッシュ状態フラグ１１の値としてコピー元とは異なる値をコピー先に設定するようにし、ＲＴＣ６により取得された、その読み出しを行った時刻を、リフレッシュ実施時刻１２の値として設定する。そして、ステップＳ５８の検索により見つかった（コピー先の）空きブロック、あるいは、後述のステップＳ６３の検索により見つかった空きブロックに、更新後のリフレッシュ状態フラグ１１とリフレッシュ実施時刻１２とを含むコピー元のブロックのデータを書き込む。

ステップＳ５９に続くステップＳ６０では、（コピー元の）対象ブロックを消去する。すなわち、対象ブロックの定コード１０から第２のＳＵＭ値１５までの値をすべて“０ｘＦＦ”に設定する。

続く、ステップＳ６１では、コピー先のブロックの定コード１０の値が参照されて、そのコピー先のブロックが最終ブロックであるかどうか、すなわち、そのコピー先のブロックの定コード１０＝“ＥＮＤ”であるかどうかが判定される。

ステップＳ６１でコピー先のブロックの定コード１０＝“ＥＮＤ”ではないと判定された場合（ステップＳ６１の判定結果がＮｏの場合）、ステップＳ６２において、定コード１０＝“ＮＵＬＬ”または定コード１０＝“ＥＮＤ”である次のプログラムの格納ブロック（リフレッシュ対象のブロック）が検索される。このとき、先のリフレッシュ対象ブロックの位置からインクリメント方向に検索される。続いて、ステップＳ６３において、定コード１０＝“０ｘＦＦ”である次の空ブロックが検索される。このとき、先の空きブロック（この時点では、先のリフレッシュ対象ブロックが書き込まれている）からインクリメント方向に検索される。なお、ステップＳ６２やステップＳ６３において、アドレスの最後までインクリメントしても対象が無いときは、先頭アドレスからインクリメント方向に検索を続ける。また、ここではインクリメント方向としたが、検索方向をデクリメントに統一しても構わない。

そして、ステップＳ５９に戻り、ステップＳ５９以降の処理が、その次のリフレッシュ対象のブロックに対して繰り返される。
一方、ステップＳ６１でコピー先のブロックの定コード１０＝“ＥＮＤ”であると判定された場合（ステップＳ６１の判定結果がＹｅｓの場合）、ステップＳ６４において、自動でリブートする。すなわち、制御がブートプログラムに移り、アプリケーション・プログラムのＳＤＲＡＭへの転送が再度行われる。フラッシュＲＯＭでの実行速度は遅いので、ＳＤＲＡＭへアプリケーション・プログラムを転送して実行する必要があるためである。

なお、以上の説明では、図２において、１ブロックが有する項目を、定コード１０、リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２、第１のＳＵＭ値１３、プログラム１４、第２のＳＵＭ値１５、とした。

しかし、第１のＳＵＭ値１３および第２のＳＵＭ値１５がいずれもプログラム１４のチェックサム値であり、同値であることを考慮すると、第２のＳＵＭ値１５を省略することも可能である。ただし、この場合、例えば、図１１のステップＳ５２やステップＳ５３における「第１のＳＵＭ値１３＝第２のＳＵＭ値１５」という判定部分が「プログラムのチェックサム値＝第１のＳＵＭ値１３」に置き換わる。

要するに、プログラム１４が正しく格納されていることを確認できて、定コード１０、リフレッシュ状態フラグ１１、リフレッシュ実施時刻１２、の各項目を有し、有するそれぞれの項目の無効な値が取り決められている任意のデータ構成を、１ブロックとすることが可能である。このようにすれば、ブロックの各項目に設定された値を参照することで、電源断がリフレッシュ処理のどの段階で発生したかを判定でき、したがって、電源断後の再開時に、判定された電源断の発生タイミングに応じて、どれが不要な消去すべきブロックであるかが判明し、アプリケーション・プログラムを破壊することなく、再リフレッシュ処理を行なうことができる。

本発明の一実施形態に係るブートプログラムおよびアプリケーション・プログラムが格納された組み込み機器の構成例を示すブロック図である。 図１の外部フラッシュＲＯＭ５のブロック構成を示す図である。 ブロックのコピーとコピー元ブロックの消去（空きブロックの生成）が終了したところで電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。 ブロックのコピーにおけるリフレッシュ状態フラグコピー完了後の処理実行中に電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。 ブロックのコピーにおけるリフレッシュ状態フラグの処理実行中に電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。 ブロックのコピーが終了したところで電源断が発生した場合の外部フラッシュＲＯＭ５のデータ例を示す図である。 ブートプログラムの実行シーケンスを示すフローチャートである。 アプリケーション・プログラムの実行シーケンスを示すフローチャートである。 図８のリフレッシュ処理の詳細フローチャートである。 図８の電源断時の再リフレッシュ処理の詳細フローチャートである。 図８の電源断時の再リフレッシュ処理の詳細フローチャート（続きの１）である。 図８の電源断時の再リフレッシュ処理の詳細フローチャート（続きの２）である。

符号の説明

１ ＣＰＵ
２ ＣＰＵ内蔵ＲＡＭ
３ ＣＰＵ内蔵フラッシュＲＯＭ
４ ＳＤＲＡＭ
５ 外部フラッシュＲＯＭ
６ ＲＴＣ
９ 空きブロック
１０ 定コード
１１ リフレッシュ状態フラグ
１２ リフレッシュ実施時刻
１３ 第１のＳＵＭ値
１４ プログラム
１５ 第２のＳＵＭ値
２１、３０ 「４」のブロック
２２ 「５」のブロック
２３ 空きブロック
２４、２６、２８ 前の方の「５」のブロック
２５、２７、２９ 後の方の「５」のブロック

Claims (10)

1. ファームウェアとして不揮発性メモリに格納されたプログラム、を実行する組み込み機器において、
   前記不揮発性メモリを複数の固定サイズのブロックに分割し、前記プログラムを前記ブロックのうちの一つ或いは複数以上にまたがるように分割して格納する格納手段と、
   該格納手段により分割して格納された前記プログラムを、前記各ブロックから別のブロックへと移動させることにより前記不揮発性メモリ内をリフレッシュさせるリフレッシュ実行部と、を有することを特徴とする組み込み機器。
2. 前記リフレッシュ実行部は、
   前記不揮発性メモリの前記各ブロックに格納されたプログラムに対し、１ブロックのデータを前記不揮発性メモリの空きブロックにコピーするコピー処理部と、
   該コピー処理部によりコピーされた、コピー元の１ブロックのデータを消去する消去処理部と、を有し、
   前記プログラムを格納する全てのブロックを、ブロックごとに前記コピー処理部によるコピー処理と前記消去処理部による消去処理を繰り返すことを特徴とする請求項１記載の組み込み機器。
3. 前記格納手段は、前記プログラム以外のデータも格納し、
   リフレッシュ中に電源断が発生した場合に、前記プログラムおよび前記プログラム以外のデータを参照して、該電源断がリフレッシュ処理のどの段階で発生したかを判定し、前記プログラムを破壊することなく、再度リフレッシュを行なう再リフレッシュ実行部、をさらに有することを特徴とする請求項１または２記載の組み込み機器。
4. 前記プログラム以外のデータは、
   プログラムの先頭、終端および中間のいずれのデータがブロックに格納されているかを判別するためのコードと、
   コピー元ブロックとコピー先ブロックとで異なる値に設定されるリフレッシュ状態フラグと、
   リフレッシュを最後に実施した時刻を示すリフレッシュ実施時刻と、
   プログラムが正しく格納されていることを確認するためのチェックデータと、を有し、
   前記再リフレッシュ実行部は、
   前記プログラムが格納されたブロックのうちの１つのブロックと、前記１つのブロックに続き、且つ前記プログラムが格納されている次のブロックとについて、前記リフレッシュ状態フラグの値が一致しなかった場合に、電源断がリフレッシュ処理のどの段階で発生したかを判定する判定処理部と、
   該判定処理部の判定結果を基に、不要なブロックの消去を行なう不要ブロック消去部と、
   を有し、
   前記判定処理部は、
   前記次のブロック内のチェックデータを用いてデータ整合性を判定する第１判定部と、
   前記１つのブロック内のチェックデータを用いてデータ整合性を判定する第２判定部と、
   前記第１判定部と前記第２判定部の判定結果が共に整合性ありの場合に、前記１つのブロックと前記次のブロック内のプログラムが同一であるかどうかを判定する第３判定部と、を有することを特徴とする請求項３記載の組み込み機器。
5. 前記第１判定部が前記次のブロック内でデータ整合性があると判定し、
   前記第２判定部が前記１つのブロック内でデータ整合性があると判定し、
   前記第３判定部が前記１つのブロックと前記次のブロックとでプログラムが同一でないと判定した場合を、前記再リフレッシュ実行部は、前記１つのブロックのコピーと該１つのブロックの消去が終了したところで電源断が発生した場合として特定し、前記次のブロックに対するリフレッシュ処理を行なうことを特徴とする請求項４記載の組み込み機器。
6. 前記第２判定部が前記１つのブロック内でデータ整合性がないと判定し、
   前記不要ブロック消去部が、データ整合性がないと判定された前記１つのブロックを消去した場合を、前記再リフレッシュ実行部は、前記１つのブロックの前記リフレッシュ状態フラグのコピー完了後の処理中に電源断が発生した場合として特定し、前記次のブロックに対するリフレッシュ処理を行なうことを特徴とする請求項４記載の組み込み機器。
7. 前記第１判定部が前記次のブロック内でデータ整合性がないと判定し、
   前記不要ブロック消去部が、データ整合性がないと判定された前記次のブロックを消去した場合を、前記再リフレッシュ実行部は、前記次のブロックの前記リフレッシュ状態フラグの項目のコピー中に電源断が発生した場合として特定し、前記１つのブロックの位置から新たに次のブロックの検索を行なうことを特徴とする請求項４記載の組み込み機器。
8. 前記第１判定部が前記次のブロック内でデータ整合性があると判定し、
   前記第２判定部が前記１つのブロック内でデータ整合性があると判定し、
   前記第３判定部が前記１つのブロックと前記次のブロックとでプログラムデータが同一であると判定し、
   前記不要ブロック消去部が、前記現在のブロックと前記次のブロックのうちで、前記リフレッシュ実施時刻が古い方のブロックを消去した場合を、前記再リフレッシュ実行部は、コピー元ブロックの消去前に電源断が発生した場合として特定し、前記リフレッシュ実施時刻が新しい方のブロックの位置から新たに次のブロックの検索を行なうことを特徴とする請求項４記載の組み込み機器。
9. 不揮発性メモリに格納されたプログラムをリフレッシュする方法において、
   前記不揮発性メモリは、リード／ライト可能な固定サイズの複数のブロックに分割され、前記プログラムは前記複数のブロックのうちの一部に分割して格納され、
   リフレッシュの度に前記プログラムを格納するブロック範囲が移動していくように、前記不揮発性メモリ内でリフレッシュを実行するステップ、を有することを特徴とする不揮発性メモリの自動リフレッシュ方法。
10. 不揮発性メモリに格納されたファームウェアとしての自分自身をコンピュータにリフレッシュさせるプログラムにおいて、
    前記不揮発性メモリは、リード／ライト可能な固定サイズの複数のブロックに分割され、前記プログラムは前記複数のブロックのうちの一部に分割して格納され、
    前記プログラムは、本来のファームウェアとしての処理に関わるステップの他に、
    リフレッシュの度に前記プログラムを格納するブロック範囲が移動していくように、前記不揮発性メモリ内でリフレッシュを実行するステップ、
    を前記コンピュータに実行させることを特徴とする不揮発性メモリの自動リフレッシュ・プログラム。