JP3864337B2

JP3864337B2 - How to upgrade

Info

Publication number: JP3864337B2
Application number: JP2002380027A
Authority: JP
Inventors: 克彦高橋; 和幸佐藤; 康之大槻; 博加賀; 圭渋谷; 裕輝岩渕
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2002-12-27
Filing date: 2002-12-27
Publication date: 2006-12-27
Anticipated expiration: 2022-12-27
Also published as: JP2004213201A

Description

【０００１】
【発明の属する技術分野】
本発明は、携帯電話機や携帯型情報通信機器（ＰＤＡ；ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）等の移動機の各種機能を実現する為のソフトウェアのバージョンアップを、同一又は類似機種の移動機又はコンピュータから容易に実施できるバージョンアップ方法に関する。
【０００２】
【従来の技術】
携帯電話機等の移動機は、各種の機能を実現する為のソフトウェアをＥＥＰＲＯＭ（ＥｌｅｃｔｒｉａｌｌｙＥｒａｓａｂｌｅａｎｄＰｒｏｇｒａｍｍａｂｌｅＲｅａｄＯｎｌｙＭｅｍｏｒｙ）等の不揮発性メモリに格納した構成を有するものであり、そのソフトウェアのバージョンアップや追加等の必要が生じた時は、バージョンアップ済みのソフトウェアを含む不揮発性メモリ、又は追加ソフトウェアを含む不揮発性メモリを、移動機に内蔵した不揮発性メモリと交換する方法が考えられる。しかし、内蔵メモリの交換は、移動機内部を開くから専門技術者による作業が必要となる問題がある。
【０００３】
そこで、移動機の内蔵の不揮発性メモリに格納されたソフトウェアの書換えや追加ソフトウェアの書込みを、コンピュータから行う方法が知られている。又移動機に対するソフトウェアのダウンロードの専用装置を設けることも考えられる。何れの場合も、移動機を、ダウンロード用のコンピュータ又は専用装置を設置している例えば営業所等に持参することになるが、比較的確実なバージョンアップが可能となる。
【０００４】
又移動機の無線通信機能を利用し、例えば、親機から新ソフトウェアをブロック毎に誤り訂正符号化して、移動通信ネットワークを介して移動機に送信し、移動機は、バージョンアップするソフトウェアを受信し、旧バージョンソフトウェアのメモリの格納領域に、受信した新バージョンソフトウェアを上書して、バージョンアップする方法が知られている（例えば、特許文献１参照）。又ネットワーク制御局から移動機に対して制御チャネルを介してパケット化した新バージョンのソフトウェアを送信し、移動機は、このパケットを制御チャネルを介して受信することにより、新バージョンのソフトウェアをダウンロードする方法が知られている（例えば、特許文献２参照）。
【０００５】
又ダウンロード用の外付け不揮発性メモリを移動機に接続し、ダウンロードプログラムを用いて、移動通信ネットワークを介してバージョンアップするソフトウェアを受信し、受信したソフトウェアを不揮発性メモリに一旦格納し、この新バージョンのソフトウェアの受信格納が完了すると、この不揮発性メモリから移動機の内蔵メモリにソフトウェアを書込むことにより、ソフトウェアのバージョンアップを行う方法も知られている（例えば、特許文献３参照）。
【０００６】
又移動機に於いて保持するメニューのバージョン情報と、受信したバージョン情報とを比較し、相違する場合は、情報センタにメニュー更新を要求し、それによって情報センタからバージョンの差に伴った差分データを移動機に送信し、移動機はこの差分データを受信してメニューを更新する手段も知られている（例えば、特許文献４参照）。このような差分データによりバージョンアップを図る為に、両方のバージョンのプログラムデータを先頭アドレスから比較し、最初に相違したアドレス以降のデータを抽出して差分データを作成し、情報センタには、最新のプログラムの全体データと、差分データとを保存し、端末装置のプログラムのバージョン情報に応じて全体データ或いは差分データを、情報センタから端末装置へ送信して、端末装置のプログラムを更新する手段も知られている（例えば、特許文献５参照）。
【０００７】
【特許文献１】
特開平９−２８４８３９号公報
【特許文献２】
特開平１１−１１０２２１号公報
【特許文献３】
特開２００２−２０７５９９号公報
【特許文献４】
特開平１１−１２０４８７号公報
【特許文献５】
特開２００２−２９７３９０号公報
【０００８】
【発明が解決しようとする課題】
移動機の無線通信機能を利用してソフトウェアのバージョンアップを行う前記特許文献１〜３に示されている方法は、移動機がネットワークを介して親局や制御局との間で無線通信が可能の位置であれば、ソフトウェアのバージョンアップを行うことが可能である。しかし、電波の伝搬状態は比較的大きく変動するから、電波の伝搬状態が良好でない場合は、再送処理を繰り返す必要が生じて、バージョンアップに要する時間が長くなる問題がある。又バージョンアップ用の専用装置は、移動機に対するソフトウェアのバージョンアップを効率良く実施できるが、専用装置は汎用コンピュータ等と相違して高価となり、且つ総ての営業所等に配置するにはコストアップとなる問題がある。
【０００９】
又移動機に対するソフトウェアのバージョンアップ過程に於いて、旧バージョンのソフトウェアが必要とするメモリ容量より、新バージョンアップのソフトウェアが必要とするメモリ容量が多い場合、他の空き容量がなければ、バージョンアップすることができなくなる。又空き容量が存在した時に、バージョンアップするソフトウェアを格納する為に、メモリ内の領域配置の変更の為の書換えの処理が必要となる問題がある。
【００１０】
又バージョンアップ過程に於いて、差分圧縮の技術を適用して、旧バージョンのソフトウェアと新バージョンのソフトウェアとの差分を転送することにより、バージョンアップに要する転送データ量を削減することが前述の特許文献４や特許文献５に示されるように提案されている。しかし、従来は、バージョンアップ過程に於いてエラーが発生すると、バージョンアップするソフトウェアの先頭からバージョンアップ処理を再開するものであった。従って、バージョンアップ過程に於けるエラー発生により、バージョンアップに要する時間が長くなる問題があった。又汎用のコンピュータ等に於けるソフトウェアについては、複数世代にわたる管理が可能となっているが、移動機についてはこのような世代管理は行われていない。その為、前述の差分を転送する場合に、バージョンによって差分が相違することになるが、これに対応することができないものであった。
【００１１】
本発明は、前述の従来の問題点を解決するもので、ソフトウェアのバージョンアップを行う改修移動機に対して、同一機種又は類似機種の移動機又はコンピュータからソフトウェアのバージョンアップを効率良く実施可能とすることを目的とする。
【００１２】
【課題を解決するための手段】
本発明のバージョンアップ方法は、図１を参照して説明すると、バージョンアップする改修移動機１に対して、バージョンアップ用移動機２又はバージョンアップ用コンピュータ３からケーブル４，５を介してソフトウェアのバージョンアップを行うバージョンアップ方法であって、バージョンアップ用移動機２又はバージョンアップ用コンピュータ３は、新版ソフトウェアと旧版ソフトウェアとの差分圧縮データを保持し、改修移動機１のソフトウェアの版数と新版ソフトウェアの版数とを含む管理情報と、ブロック単位の差分圧縮データとをケーブル４，５を介して改修移動機１に転送し、この改修移動機１は、差分圧縮データを解凍して展開し、不揮発性メモリに順次書込む過程を含むものである。
【００１３】
又バージョンアップ用移動機２又はバージョンアップ用コンピュータ３は、改修移動機１とケーブル４，５で接続して、ソフト改修プログラムを転送し、改修移動機１は、バージョンアップ用移動機２又はバージョンアップ用コンピュータ３からのブロック単位の差分圧縮データを順次受信して、ソフト改修プログラムに従って解凍して展開したデータを不揮発性メモリの領域に書込む時に、この領域の旧版データを退避させて書込み、正常書込終了による前記ブロックの番号を記憶し、このブロック単位の差分圧縮データ又は書込過程に於けるエラー発生時に、退避させた旧版データを元に戻して、差分圧縮データの受信を開始し、前記記憶したブロック番号の次のブロック番号のデータから不揮発性メモリに対する書込処理を再開する過程を含むことができる。
【００１４】
又改修移動機１の不揮発性メモリに格納する初期状態の複数のライブラリを、それぞれ空き領域を介在させて格納し、バージョンアップによるライブラリの増分を前記空き領域により吸収することができる。又複数のライブラリのそれぞれのバグ検出数を求め、バグ検出数が少ないライブラリを不揮発性メモリのアドレスの若番側に、且つバグ検出数が多いライブラリを不揮発性メモリのアドレスの老番側に格納する。
【００１５】
又バージョンアップ用移動機２又は前記バージョンアップ用コンピュータ３は、複数世代の旧版ソフトウェアと新版ソフトウェアとのそれぞれの差分圧縮データと、版数情報を含む管理情報とを保持し、且つ差分圧縮データを、改修移動機１に順次転送する為のブロック単位に保持することができる。
【００１６】
【発明の実施の形態】
図１は本発明の原理説明図であり、ソフトウェアのバージョンアップを行う改修移動機１と、最新ソフトウェアを搭載しているバージョンアップ用移動機２との間をシリアル転送用のケーブル４により接続し、バージョンアップ用移動機２から改修移動機１に対して、最新ソフトウェアをシリアル転送して、ソフトウェアのバージョンアップを実施する。この場合のバージョンアップ用移動機２は、改修移動機１と同一機種又は類似機種とするものであり、この移動機２は、図示を省略したソフトウェア作成用のコンピュータ等から最新ソフトウェアを転送して格納した構成とする。従って、ソフトウェアのバージョンアップが必要となった時に、作成した最新バージョンのソフトウェアを格納したバージョンアップ用移動機２を各所に配付することにより、ユーザの移動機１に対するバージョンアップのサービスを容易に実施することができる。
【００１７】
又は改修移動機１と、最新ソフトウェアを搭載しているバージョンアップ用コンピュータ（ＰＣ）３との間をシリアル転送用のケーブル５により接続し、バージョンアップ用コンピュータ３から改修移動機１に対して最新ソフトウェアをシリアル転送して、ソフトウェアのバージョンアップを実施する。
【００１８】
この場合、旧版ソフトウェアと新版ソフトウェアとの差分データを更に圧縮符号化して、ケーブル４を介して改修移動機１に転送し、改修移動機１に於いて解凍及び差分展開を行って、不揮発性メモリ、即ち、ＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄＯｎｌｙＭｅｍｏｒｙ）等の書換え可能の不揮発性メモリに書込むことにより、新版ソフトウェアにバージョンアップするものである。何れの場合も、シリアル転送用のケーブル４，５により接続することにより、安定したバージョンアップ処理を行うことができる。
【００１９】
図２は本発明の第１の実施の形態の説明図であり、１はユーザが所有するソフトウェアのバージョンアップを行う改修移動機、２はＶＵ（バージョンアップ用）移動機、７はバージョンアップ用のソフトウェアを作成して保持するパーソナルコンピュータ（パソコン）、１１はＢｏｏｔ（ブート）プログラム、１２は旧プログラム、１３は新規プログラム、１５はロードモジュール（ＬＭ）、１７はパソコン７の制御処理部、１８は差分圧縮データ、１９は各種プログラム／管理データ、２１はＶＵ移動機２の各種プログラム、２２はプログラムの版数等を含む管理データ、２３は差分圧縮データを示す。又１）〜９）の経路によりバージョンアップの処理経路を示し、改修移動機１の旧プログラム１２と新規プログラム１３及びＶＵ移動機２の各種プログラム２１と管理データ２２と差分圧縮データ２３とは、前述の書換え可能の不揮発性メモリに格納する構成とする。
【００２０】
パソコン７の制御処理部１７により、新規ソフトウェアのロードモジュールＬＭを、１）バイナリ（Ｂｉｎａｒｙ）変換し、旧版ソフトウェアと新版ソフトウェアとについて、２）差分抽出し、抽出した差分を、３）圧縮符号化し、差分圧縮データ１８としてメモリに格納する。そして、新版ソフトウェアのバージョン等について、４）管理情報生成を行い、各種プログラム／管理データ１９としてメモリに格納する。
【００２１】
そして、パソコン７とＶＵ移動機２とをシリアルケーブルで接続し、５）ローダー（Ｌｏａｄｅｒ）により、パソコン７の各種プログラム２１と、管理データ２２と、差分圧縮データ２３とを転送して格納する。このＶＵ移動機２と改修移動機１とを図１について説明したようにシリアルケーブルにより接続し、６）改修移動機１に於いては、７）ブート（Ｂｏｏｔ）展開を行い、差分圧縮データについて、８）解凍と、９）差分展開とを行い、不揮発性メモリ内の旧プログラムを新規プログラムに書換えてバージョンアップを行う。
【００２２】
この場合のＶＵ移動機２から改修移動機１に対して転送する差分圧縮データは、予め設定したブロック単位で転送するものであり、ブロック対応にエラーチェックを行い、エラーを含まない新規プログラムとなるようにバージョンアップ処理を行う。又このブロック単位で不揮発性メモリに対するデータの書込みが正常終了した例えばブロック番号を記憶しておき、バージョンアップ処理過程で異常が発生した場合、正常終了した例えばブロック番号を記憶しているから、バージョンアップ処理再開による不揮発性メモリに対する書込処理は、正常終了したブロックの次から再開する。フラッシュメモリ等の不揮発性メモリは、書込処理時間が比較的長いから、正常終了したブロックの次のブロックから書込処理を再開することにより、エラーが発生した場合でも、バージョンアップに要する時間を短縮することができる。
【００２３】
図３は本発明の第２の実施の形態の説明図であり、１はソフトウェアのバージョンアップを行う改修移動機、３はバージョンアップ用コンピュータ（パソコン）、７はバージョンアップ用のソフトウェアを作成して保持するコンピュータ（パソコン）、１１はＢｏｏｔ（ブート）プログラム、１２は旧プログラム、１３は新規プログラム、１５はロードモジュール（ＬＭ）、１７はパソコン７の制御処理部、１８は差分圧縮データ、１９は各種プログラム／管理データ、３１は制御処理部、３２は書換えＤＬＬ（ＤｙｎａｍｉｃＬｉｎｋＬｉｂｒａｒｙ；ダイナミック・リンク・ライブラリー）、３３は管理データ、３４は差分圧縮データを示す。又１）〜８）はバージョンアップの経路を示す。
【００２４】
バージョンアップ用コンピュータ（パソコン）３は、図２に於けるＶＵ移動機２に対応するもので、このパソコン３と、改修移動機１とをＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）ケーブルで接続して、改修移動機１のソフトウェアのバージョンアップを行う場合を示す。又パソコン７は、図２に於けるパソコン７と同一の構成を有し、制御処理部１７の制御に従って、ソフトウェアの書換え用アプリケーションを実装したパソコン３に対して差分圧縮データを転送する。この差分圧縮データを、パソコン３から改修移動機１へ、図２について説明した場合と同様の処理過程によってバージョンアップ処理を実行する。
【００２５】
図４はメモリの説明図であり、旧版の複数のライブラリＡ．ＬＩＢ（Ｌｉｂｒａｒｙ），Ｂ．ＬＩＢ，Ｃ．ＬＩＢ，Ｄ．ＬＩＢ，・・・がメモリの連続したアドレスに格納されている場合、ライブラリＡ．ＬＩＢの変更により、バージョンアップ処理を行うと、旧版のメモリから、新版のメモリのように、ライブラリＡ．ＬＩＢの変更増分だけ、他のライブラリＢ．ＬＩＢ，Ｃ．ＬＩＢ，Ｄ．ＬＩＢ，・・・の格納アドレスを繰り下げることになる。即ち、ライブラリＡ．ＬＩＢの変更増分に従って、他のライブラリＢ．ＬＩＢ，Ｃ．ＬＩＢ，・・・を順次書換える必要が生じることになる。それにより、書換えに要する時間が増加する。通常フラッシュメモリ等の不揮発性メモリを用いるものであるから、書込みに要する時間が、ランダムアクセスメモリに比較して長く且つ書込電力を必要とすることから、消去した領域に書込むデータ量が多いと、長時間を要し、且つ消費電力が増加する。
【００２６】
そこで、本発明に於いては、図５に於ける旧版として示すように、予め各ライブラリＡ．ＬＩＢ，Ｂ．ＬＩＢ，Ｃ．ＬＩＢ，Ｄ．ＬＩＢ，・・・間に空き領域を形成してメモリに格納する。それにより、例えば、ライブラリＡ．ＬＩＢの変更による増分があっても、新版のメモリのように、空き領域を利用して増分を吸収できるから、メモリの更新量は少なくて済むことになる。
【００２７】
図６は更にメモリの更新量を低減する場合を示し、旧版として示すメモリのように、各ライブラリ間に空き領域を形成し、且つ後述のような処理により、割付順番を変更する。この場合、過去のバグ検出数等によりライブラリの改修の可能性を推測し、改修の可能性の高いライブラリを、メモリのアドレスの老番側に格納する。例えば、ライブラリＤ．ＬＩＢ，Ｃ．ＬＩＢ，Ａ．ＬＩＢ，Ｂ．ＬＩＢ，・・・の順番とした場合を示す。そして、例えば、アドレスの老番側のライブラリＡ．ＬＩＢの改修による変更増分があっても、新版のメモリのように、ライブラリＢ．ＬＩＢを繰り下げるだけで済むから、メモリの更新量は更に少なくなる。即ち、メモリの変更差分については、ライブラリ間に空き領域を形成しない図４が最も大きくなり、次にライブラリ間に空き領域を形成する図５が中程度となる。そして、更新する可能性の高いライブラリの割付けの順番をアドレスの老番側とする図６が最も小さくなる。
【００２８】
図７はメモリ内配置処理のフローチャートを示し、メモリに格納するライブラリ（ＬＩＢ）の数ｎの繰り返し処理を行ったか否か、即ち、ｉ＝１〜ｉ＝ｎまでの繰り返し処理を行ったか否かを判定し（Ａ１）、過去の実績からｉ番目のライブラリ（ＬＩＢ）のバグ検出数をカウントする（Ａ２）。そして、そのライブラリ（ＬＩＢ）が最初（ｉ＝１番目）か否かを判定し（Ａ３）、ｉ＝１番目のライブラリの場合、このライブラリを最若番に配置する（Ａ４）。又ｉ＝１でないライブラリ（ＬＩＢ）は、配置の並べ替え処理を行う（Ａ５）。そして、具体的なステップは図示を省略しているが、前述のステップ（Ａ２）〜（Ａ５）についてｉ＝１〜ｉ＝ｎまで繰り返すことにより、ライブラリ（ＬＩＢ）の配置の並べ替えが終了する。
【００２９】
前述のステップ（Ａ５）のライブラリ（ＬＩＢ）の配置の並べ替え処理は、図８に示すように、格納したライブラリ（ＬＩＢ）数分の繰り返し処理を行ったか否か、この場合、ｊ＝１〜ｊ＝ｉ−１までの繰り返し処理を行ったか否かを判定し（Ｂ１）、今回判定するｉ番目のライブラリのバグ検出数が過去に判定したｊ番目のライブラリのバグ検出数よりも小さいか否かを判定し（Ｂ２）、小さい場合は、ｉ番目のライブラリをｊ番目のライブラリの前に配置する（Ｂ３）。しかし、大きい場合は、配置しない。従って、ステップ（Ｂ２）に於いて、配置済みのライブラリ（ＬＩＢ）のバグ検出数より大きいライブラリ（ＬＩＢ）は、ステップ（Ｂ３）に於いて配置されないで、次の繰り返しによるステップ（Ｂ２）に於いて順番が回ってくると、再度比較される。
【００３０】
そして、ｉ−１番目のライブラリ（ＬＩＢ）まで比較済みか否かを判定し（Ｂ４）、比較済みでない場合は、最初のステップ（Ｂ１）に復帰し、比較済みの場合は、その時のｉ番目のライブラリ（ＬＩＢ）は、ステップ（Ｂ３）に於いて配置処理されたライブラリ（ＬＩＢ）のバグ検出数より大きいバグ検出数を有するライブラリであるから、アドレスの最老番に配置する（Ｂ５）。従って、バグ検出数が少ない順番にライブラリ（ＬＩＢ）が並べ替えられる。
【００３１】
このような処理により、図６に於ける旧版として示すようにライブラリを配置する。即ち、バグ検出数が多いライブラリについては改版する可能性が高いから、メモリのアドレスの最老番側に配置し、改版の可能性が低いと推定されるライブラリは、アドレスの若番側に配置する。それによって、他のライブラリの再配置の可能性が極めて低くなり、バージョンアップに要する時間の短縮に寄与することができる。
【００３２】
図９はロードモジュール変換ツールの説明図であり、４１はロードモジュールＬＭ１（プログラム）を格納したメモリ、４２はロードモジュールＬＭ２（データ）を格納したメモリ、４３は定義ファイル、４４はロードモジュール変換ツール、４５はバイナリ変換部、４６はロードモジュール（ＬＭ）マージ部、４７はバイナリデータを格納したメモリを示す。
【００３３】
先ず、（１）．定義ファイル４３は、変換対象ファイル名、変換対象アドレス範囲、変換除外アドレス範囲、出力ファイル名等を記述したもので、ロードモジュール変換ツール４４は、この定義ファイル４３を読込む。次に、（２）．読込んだ定義ファイル４３により指定されている情報を基に、新旧ロードモジュールファイルをバイナリ変換部４５によりバイナリデータに変換する。次に、（３）．ロードモジュールマージ部４６によりバイナリデータのマージを行う。それにより、メモリ４７に、バイナリデータが格納される。
【００３４】
図１０は差分圧縮ツールの説明図であり、６１は新ロードモジュール（バイナリデータ）を格納したメモリ、６２は旧ロードモジュール（バイナリデータ）を格納したメモリ、６３は差分抽出ツール、６４は分割・差分データを示す。差分抽出ツール６３により、新ロードモジュールと旧ロードモジュールとの差分をバイナリデータとして求め、圧縮処理により、分割・圧縮データ６４を求める。この場合、移動機に搭載し易いように、分割・圧縮データ６４は、例えば、２５６ｋバイト単位で分割することができる。
【００３５】
図１１はＶＵ移動機に対してバージョンアップ用のデータを格納する為の転送データ作成ツールの説明図であり、７１は新版ロードモジュール（ＬＭ）を格納したメモリ、７２はロードモジュール（ＬＭ）作成ツール、７３は複数世代（複数の版数）対応の差分データを、旧版差分１，旧版差分２，・・・として格納したメモリ、７４は定義ファイル、７５はロードモジュール（ＬＭ）作成ツール７２により作成された管理情報ロードモジュール（ＬＭ）、差分実データ１，差分実データ２，・・・を格納したメモリを示す。
【００３６】
この場合、図２に示すように、ＶＵ移動機２から改修移動機１に対するバージョンアップを行う場合の転送データの作成の場合を示し、ロードモジュール（ＬＭ）作成ツール７２は、先ず（１）．変換対象ファイル名，変換対象プログラム版数，変換ファイル数，分割ブロックサイズ等を定義ファイル７４から読込む。そして、（２）．新版ロードモジュール（ＬＭ）（バイナリ形式）をメモリ７１から読込み、ＣＲＣ（ＣｙｃｌｉｃＲｅｄｕｎｄａｎｃｙＣｈｅｃｋ）生成を行い、（３）．メモリ７３から変換対象プログラム版数に従った差分データを読込み、各差分データのサイズを求める。そして、（４）．前述の処理で得られたデータと共に差分転送管理情報，版数対応の差分実データを、ＶＵ移動機２にロード可能の形式で出力してメモリ７５に格納する。
【００３７】
図１２は転送データ作成ツールの説明図であり、８１は新版ロードモジュール（ＬＭ）を格納したメモリ、８２はロードモジュール（ＬＭ）作成ツール、８３は最新版単純圧縮データ，旧版差分１，旧版差分２，・・・を格納したメモリ、８４は定義ファイル、８５は転送データを格納したメモリを示す。
【００３８】
この場合、図３に示すように、パソコン３から改修移動機１に対するバージョンアップを行う場合の転送データの作成の場合を示し、ロードモジュール（ＬＭ）作成ツール８２は、先ず（１）．変換対象ファイル名，変換対象プログラム版数，変換ファイル数，分割ブロックサイズ等を定義ファイル８４から読込み、次に、（２）．メモリ８１から新版ロードモジュール（ＬＭ）（バイナリ形式）を読込み、ＣＲＣを生成し、（３）．メモリ８３から差分データを読込み、各差分データのサイズを求め、（４）．前述の処理で得られたデータと共に差分転送管理情報，最新版ロードモジュール（ＬＭ）単純圧縮ファイル，版数対応の差分実データファイルをバイナリ形式でパソコン３にロードする。
【００３９】
図１３は転送データの説明図であり、図２に示すＶＵ移動機２から改修移動機１に対してバージョンアップする場合の転送データを示し、９１は移動機対応のファイル管理データ，差分管理データを含む管理情報、９２はプログラムの版数対応の差分情報ロードモジュール（ＬＭ）を示す。
【００４０】
図１４，図１５は管理ロードモジュールの説明図であり、図２に示すＶＵ移動機２から改修移動機１に対してバージョンアップする場合の管理情報を示し、格納ファイル数，最新書換えバージョン，最新プログラム版数，差分書込み完了後のＣＲＣ３２データ等を含むと共に、版数対応の差分用旧版プログラム版数，バージョンアップ移動機内の差分管理データ書込先ＲＯＭアドレス，バージョンアップ移動機内の差分実データの書込先ＲＯＭアドレスと、ファイル毎の差分管理データとを含む。このファイル毎の差分管理データは、図１５に示すように、該当ファイル内の差分ブロック数と、差分分割単位（バイト）と、第１番目の転送先ＲＯＭアドレスと、第１番目の差分ブロックサイズと、第１番目の差分を適用後のＣＲＣ３２データとを、差分ブロック数対応に格納する。このような構成により複数世代にわたり管理することができる。
【００４１】
図１６は図３に示すパソコン３から改修移動機１に対してバージョンアップする場合のファイル構成の説明図であり、階層型のディレクトリ構造によるファイル管理を示す。その管理ファイルの一例を図１７に示す。この管理ファイルは、格納ファイル数，最新書換えバージョン，最新プログラム版数，差分書込完了後のＣＲＣ３２データ，ソフト更新プログラムファイルサイズ，ソフト更新プログラムファイル名と、版数対応に、差分旧版プログラム版数と差分データファイル管理情報格納先オフセット値と差分情報ファイル格納ディレクトリ名と、ファイル毎の差分管理データとを含み、ファイル毎の差分管理データは、該当ディレクトリ内の差分ファイル数と、差分分割単位（バイト）と、差分情報ファイル毎の差分情報ファイルサイズと差分情報ファイル名と差分を適用後のＣＲＣ３２データとを含む内容を格納している。
【００４２】
図１８はＶＵ移動機２（図２参照）から改修移動機１に対するバージョンアップ処理を行う場合の追加したシリアルコマンドを示し、「コマンド」を省略して図示している。又Ｐ１，Ｐ２，・・・はパラメータを示す。又方向は、左向き矢印が改修移動機１からＶＵ移動機２方向、右向き矢印がＶＵ移動機２から改修移動機１方向を示す。
【００４３】
移動機版数通知シリアルは、改修移動機１からＶＵ移動機２に対して、ＣＲＣを含むバージョン情報を転送するもので、それにより、ＶＵ移動機２は、改修移動機１の版数を識別し、版数対応のデータを決定する。又新版数通知シリアルは、改修移動機１から受信したバージョン情報により、バージョンアップ対象と判定した時に、ＶＵ移動機２は、改修移動機１に対して最新のソフト版数と書換え版数とを送信する。チェック結果通知シリアルは、改修移動機１からＶＵ移動機２に対してチェック結果を送信する。書込データ送信シリアルは、ＶＵ移動機２から改修移動機１に対して、書込アドレス，書込後のＣＲＣデータ，送信サイズ，書込データを送信する。書込情報送信シリアルは、バージョンアップの全データを送信後、整合性確認の為の全システムエリアのＣＲＣ値を送信する。
【００４４】
全領域チェック結果通知シリアルは、改修移動機１からＶＵ移動機２に対して、チェック結果を送信する。バージョンアップ完了送信シリアルは、ＶＵ移動機２から改修移動機１に対してバージョンアップの終了を通知する。エラー通知シリアルは、改修移動機１とＶＵ移動機２とに於けるエラー発生時に、相手側へエラー通知する。それにより、表示画面にエラー有りを表示する。
【００４５】
図１９，図２０は、改修移動機に対してＶＵ移動機からバージョンアップする場合のシーケンス説明図であり、又図１８のパラメータＰ１を（）内に示す。先ず、ＶＵ移動機に於いて、１）電源投入し、改修移動機との間を、シリアルデータ転送を行う２）ケーブルで接続する。そして、３）改修移動機の電源を投入し、ソフト書込モードを起動し、ＶＵ移動機の４）１キー（テンキーの中の「１」を示すが、他のキーにより指定する方法とすることも可能である）押下を行ってソフト改修プログラム起動要求を行い、５）ソフト改修プログラムを改修移動機に転送する。
【００４６】
改修移動機は、ソフト改修プログラムを受信して、改修処理を起動し、改修移動機の電池電圧が正常動作を保証できる電圧か否かをチェックし、６）プロテクト領域（バージョンアップ対象領域以外の領域）のチェックサムを演算し、モード変更，復旧待ちモードとなり、７）改修移動機からＶＵ移動機に対して現バージョン情報を送出する（８０）。即ち、移動機版数通知シリアルコマンドが実行される。ＶＵ移動機は、改修移動機からのバージョン情報によりバージョンアップ対象か否かを判定し、対象外の移動機の場合は、処理を終了する。又バージョンアップ対象の移動機の場合は、改修移動機に対して８）新バージョン情報を通知する（Ｎ）。即ち、新版数通知シリアルコマンドを実行する。
【００４７】
改修移動機は、新バージョン情報を受信してＶＵ移動機に対してチェック結果を通知する（Ｃ）。即ち、チェック結果通知シリアルコマンドを実行する。ＶＵ移動機は、１０）ブロック毎に差分圧縮データを転送する（Ｗ）。即ち、書込データ送信シリアルコマンドを実行する。この場合、ＶＵ移動機から版数等を含む管理情報も転送する。改修移動機は、ソフト改修プログラムに従ってブロック単位の差分圧縮データを解凍して展開し、１１）ＲＯＭ書込みを行い、対象領域のＣＲＣ演算を行う。そして、１２）受信ＣＲＣ値と演算結果のＣＲＣ値とを比較し、その比較結果を、１３）ＶＵ移動機に通知する（Ｃ）。即ち、チェック結果通知シリアルコマンドを実行する。そして、この１０）〜１３）の処理を、１４）ブロック数だけ繰り返す。
【００４８】
そして、ＶＵ移動機が、最終ブロックのＣＲＣ通知を受信すると、改修移動機に対して、１５）書込状況チェックを送出する（Ｉ）。即ち、書込状況送信シリアルコマンドを実行する。改修移動機は、プロテクト領域（バージョンアップ対象領域以外の領域）についてのチェックサムを再計算し、書込みの前に求めたチェックサムと比較する。比較一致の場合は、バージョンアップによるプロテクト領域が影響を受けていないことが判る。又プログラム領域のチェックサムを求め、ＶＵ移動機から書込状況チェック通知で転送されたチェックサムと比較し、１６）その比較結果をＶＵ移動機へ転送する（Ｐ）。即ち、全領域チェック結果通知シリアルコマンドを実行する。ＶＵ移動機は、比較結果によりエラー無しと判定すると、１７）バージョンアップ終了を改修移動機に通知する（Ｚ）。即ち、バージョンアップ完了送信シリアルコマンドを実行する。１８）改修移動機は、それによって通常モードにモード変更する。
【００４９】
図２１〜図２３はパソコン（ＰＣ）から改修移動機に対してバージョンアップする場合のシーケンス説明図であり、図１８に示すシリアルコマンドに於けるパラメータＰ１を（）内で示す。なお、図１９，図２０に示すシーケンスと同様な処理でバージョンアップを行うものであるが、先ず、パソコンと改修移動機とをＵＳＢケーブルで接続し、バージョンアップ前に、移動機製造番号による機種が正しいか否か、通常モードか復旧待ちモードか否か、復旧書換え要求か否か、復旧書換え要求時は通常モードか否か、又バージョン確認を行った後に、パソコンから改修移動機に開始通知を行う。それ以降は、シリアル情報のパラメータＰ１も併記して示すように、図１９及び図２０に示すバージョンアップ動作シーケンスと同様のシーケンスでバージョンアップが行われるものであるから、重複した説明は省略する。
【００５０】
図２４及び図２５は、ＶＵ移動機から改修移動機に対してバージョンアップを行っている時のエラー発生時の動作シーケンスを示し、（Ｗ），（Ｅ），（Ｃ）は図１８に示すシリアルコマンドのパラメータＰ１を示す。ＶＵ移動機からＮ番目（ブロック単位で先頭からＮ番目のブロック）の差分圧縮データを改修移動機に転送する（Ｗ）。即ち、書込データ送信シリアルコマンドを実行する。改修移動機は、前回の（Ｎ−１）番目の差分圧縮データを正常に不揮発性メモリに書込み、その書込完了位置を‘Ｎ−１’に更新する。そして、差分圧縮データを解凍して展開し、旧データを退避させて、ＲＯＭ（不揮発性メモリ）に対して消去，書込みを行う。即ち、差分圧縮データの転送毎に、（転送回数−１）番目の書込完了位置の更新と、ＲＯＭ書込前に旧データの保存とを行う。例えば、このＲＯＭ書込時に、エラーが発生すると、退避した旧データを元に戻し、エラー発生通知をＶＵ移動機に送出する（Ｅ）。即ち、エラー通知シリアルコマンドを送出する。
【００５１】
ＶＵ移動機は、エラー発生通知により、再度バージョンアップの処理を開始する。即ち、１番目のブロックの差分圧縮データを改修移動機に転送し、改修移動機はＣＲＣ演算のみを行い、ＲＯＭ書込処理は行わない。そして、そのチェック結果をＶＵ移動機に通知し、ＶＵ移動機は、２番目のブロックの差分圧縮データを改修移動機に転送する。これを繰り返して、前回エラーが発生してＲＯＭに書込まれていないＮ番目のブロックの差分圧縮データを改修移動機が受信すると、書込完了位置を‘Ｎ−１’に更新し、差分圧縮データを解凍して展開し、旧データを退避させて、ＲＯＭに対して消去，書込みを行い、ＣＲＣ演算を行って、チェック結果をＶＵ移動機に通知する。そして、書込完了位置を‘Ｎ’とする。又Ｎ＋１番目以降の差分圧縮データについても同様の処理によりＲＯＭに書込む。従って、エラー発生時は、ＶＵ移動機は、パージョンアップの為の差分圧縮データを１番目から順次転送することになるが、改修移動機は、エラー発生時の書込完了位置を記憶しているから、前回の書込完了位置以降のブロックの差分圧縮データを受信する毎にＲＯＭ書込みを行うことになり、先頭からＲＯＭ書込みを繰り返す場合に比較して、所要時間を短縮することができる。
【００５２】
図２６及び図２７は、ＶＵ移動機から改修移動機に対するバージョンアップ時の動作シーケンス説明図であり、ＶＵ移動機の電源投入を行い（１）、それにより、「ＳＥＴＴＥＥＣＡＢＬＥＡＮＤＴＵＲＮＯＮＴＨＥＡＮＯＴＨＥＲＭＳＴＨＥＮＰＵＳＵ１ＫＥＹ」が、ＶＵ移動機の表示画面に表示される。そこで、ＶＵ移動機と改修移動機とを専用ケーブルで接続する（２）。そして、改修移動機の電源投入を行い（３）。それにより、改修移動機の発光ダイオードＬＥＤが一瞬点灯する。
【００５３】
次に、ＶＵ移動機の「１」キーを押下する（４）。その時、改修移動機の表示画面は空白画面となっている。そして、バージョンアップ処理が開始され、ＶＵ移動機の表示画面は、改修移動機の機種やバージョンのチェック画面、チェックＯＫにより差分圧縮データ割合の表示画面、終了画面に移行する。又改修移動機に於いては、発光ダイオードＬＥＤの点灯，消灯によるダウンロード中の状態を示し、表示画面は、最後に終了画面となる。そして、専用ケーブルを外し（５）、ＶＵ移動機と改修移動機とは電源をオフとする（６）。前述のように、ＶＵ移動機と改修移動機との表示画面により、操作手順を表示することができる。
【００５４】
図２８及び図２９は、パソコンから改修移動機に対するバージョンアップ時の動作シーケンス説明図であり、パソコンＰＣと改修移動機とをＵＳＢケーブルで接続し（１）、パソコンＰＣのソフト書換用アプリケーションの実行ボタン押下により、バージョンアップを開始する（２）。改修移動機は、ＬＥＤが２回点滅し、その後、点灯を継続する。又表示画面は空白画面となる。そして、パソコンＰＣからのデータ転送が終了すると、ＬＥＤ消灯となり、次にＬＥＤ点灯し、ＲＯＭに対する書換え処理中を、表示画面に表示し、終了により、「ＣＯＭＰＬＥＴＥＤ」を表示し、ＬＥＤは消灯する。そして、自動リセットにより待受画面となり、ＵＳＢケーブルを取り外して、バージョンアップ処理を終了する（３）。なお、移動機のＬＣＤ（液晶表示）画面と、ＬＥＤ（発光ダイオード）との配置構成の一例を図示しているが、他の配置構成とすることも可能であり、又ユーザインタフェースとしてのＬＥＤの点灯制御や表示画面の表示制御は、前述の実施の形態に限定されるものではない。
【００５５】
図３０はエラー表示の説明図であり、ＶＵ移動機から改修移動機に対してバージョンアップする場合のエラー発生時の表示の一例を示す。例えば、移動機種別の誤りや、チェックサムの比較によるエラー等の表示内容を示す。又他の各種のエラー発生時には、エラー種別が認識できるように表示することができる。
【００５６】
【発明の効果】
以上説明したように、本発明は、改修移動機に対して、バージョンアップ移動機又はパソコンからケーブルを介して、新版ソフトウェアと旧版ソフトウェアとの差分を更に圧縮したデータをブロック単位で転送し、又ソフトウェアの版数情報等を含む管理情報も転送し、改修移動機は、ソフト改修プログラムに従ってブロック単位の差分圧縮データを解凍して展開し、書換え可能の不揮発性メモリに順次書込むもので、又そのブロック単位で正常書込完了を記憶する。又エラー発生時は、正常書込完了のブロックの次のブロックから不揮発性メモリに対する書込みを行うものである。
【００５７】
従って、改修移動機のバージョンアップ処理は、携帯が容易なバージョンアップ移動機を用いることが可能であり、又パソコンからも実行することができるものであるから、柔軟性に富んだバージョンアップが可能となる。又ブロック単位で圧縮符号化して転送するから、転送データ量を削減して、バージョンアップに要する時間を短縮することができる。又エラー発生時に於いても、不揮発性メモリに対する書込みを、エラー発生ブロックから行うことにより、バージョンアップに要する時間を短縮することができる。例えば、同一のソフトウェアについて、従来の方法による場合のバージョンアップに要する時間は、平均的に約２３分を要したものが、本発明の実施の形態によれば、最短３分９秒で済み、平均で４分５９秒であった。
【００５８】
又旧版数対応に新版ソフトウェアとの差分圧縮データを保持して、改修移動機側の版数に対応した差分圧縮データをダウンロードすることが可能であり、１台のバージョンアップ移動機又はバージョンアップ用コンピュータにより、各種の版数の改修移動機に対応することができる。又不揮発性メモリのライブラリ対応の領域間に空きを形成し、更には、バグ検出数の多いライブラリをアドレスの老番側に配置することにより、バージョンアップ時の増分による他のライブラリの書換えが必要となる確率を低減して、バージョンアップに要する時間を短縮することができる利点がある。
【図面の簡単な説明】
【図１】本発明の原理説明図である。
【図２】本発明の第１の実施の形態の説明図である。
【図３】本発明の第２の実施の形態の説明図である。
【図４】メモリの説明図である。
【図５】メモリの説明図である。
【図６】メモリの説明図である。
【図７】メモリ内配置処理のフローチャートである。
【図８】並べ替え処理のフローチャートである。
【図９】ロードモジュール変換ツールの説明図である。
【図１０】差分圧縮ツールの説明図である。
【図１１】転送データ作成ツールの説明図である。
【図１２】転送データ作成ツールの説明図である。
【図１３】転送データの説明図である。
【図１４】管理ロードモジュールの説明図である。
【図１５】管理ロードモジュールの説明図である。
【図１６】ファイル構成の説明図である。
【図１７】管理ファイルの説明図である。
【図１８】追加したシリアルコマンドの説明図である。
【図１９】バージョンアップ動作シーケンス説明図である。
【図２０】バージョンアップ動作シーケンス説明図である。
【図２１】バージョンアップ動作シーケンス説明図である。
【図２２】バージョンアップ動作シーケンス説明図である。
【図２３】バージョンアップ動作シーケンス説明図である。
【図２４】エラー発生時の動作シーケンス説明図である。
【図２５】エラー発生時の動作シーケンス説明図である。
【図２６】バージョンアップ時の動作シーケンス説明図である。
【図２７】バージョンアップ時の動作シーケンス説明図である。
【図２８】バージョンアップ時の動作シーケンス説明図である。
【図２９】バージョンアップ時の動作シーケンス説明図である。
【図３０】エラー表示の説明図である。
【符号の説明】
１改修移動機
２バージョンアップ用移動機（ＶＵ移動機）
３バージョンアップ用コンピュータ（ＰＣ）
４，５ケーブル[0001]
BACKGROUND OF THE INVENTION
The present invention easily upgrades software for realizing various functions of a mobile device such as a mobile phone or a personal digital assistant (PDA) from the same or similar mobile device or computer. It relates to a version upgrade method that can be performed.
[0002]
[Prior art]
Mobile devices such as mobile phones have a configuration in which software for realizing various functions is stored in a nonvolatile memory such as EEPROM (Electrically Erasable and Programmable Read Only Memory), and software upgrades and additions For example, there may be a method of replacing a nonvolatile memory including upgraded software or a nonvolatile memory including additional software with a nonvolatile memory built in the mobile device. However, the replacement of the built-in memory has a problem that requires work by a professional engineer because the mobile unit is opened.
[0003]
Therefore, there is known a method of rewriting software stored in a nonvolatile memory built in a mobile device or writing additional software from a computer. It is also possible to provide a dedicated device for downloading software to the mobile device. In either case, the mobile device is brought to a sales office or the like where a download computer or a dedicated device is installed, but a relatively reliable version upgrade is possible.
[0004]
Also, using the wireless communication function of the mobile device, for example, new software is error-correction-encoded for each block from the parent device and transmitted to the mobile device via the mobile communication network, and the mobile device receives the software to be upgraded. A method is known in which the received new version software is overwritten in the storage area of the memory of the old version software to upgrade the version (see, for example, Patent Document 1). In addition, the network control station transmits a new version of software packetized to the mobile device via the control channel, and the mobile device downloads the new version of software by receiving this packet via the control channel. A method is known (see, for example, Patent Document 2).
[0005]
In addition, an external nonvolatile memory for downloading is connected to the mobile device, and using the download program, the software to be upgraded via the mobile communication network is received, and the received software is temporarily stored in the nonvolatile memory. There is also known a method of upgrading the software version by writing the software from the nonvolatile memory to the built-in memory of the mobile device when reception and storage of the version software is completed (see, for example, Patent Document 3).
[0006]
Also, the version information of the menu held in the mobile device is compared with the received version information, and if they are different, the menu update is requested to the information center, and thereby the difference data accompanying the version difference from the information center. Is also known to update the menu by receiving the difference data (see, for example, Patent Document 4). In order to upgrade the version with such difference data, the program data of both versions are compared from the top address, the data after the first different address is extracted and the difference data is created. Means for storing the whole data of the program and the difference data, transmitting the whole data or the difference data from the information center to the terminal device according to the version information of the program of the terminal device, and updating the program of the terminal device It is known (see, for example, Patent Document 5).
[0007]
[Patent Document 1]
Japanese Patent Laid-Open No. 9-284839
[Patent Document 2]
JP-A-11-110221
[Patent Document 3]
JP 2002-207599 A
[Patent Document 4]
Japanese Patent Laid-Open No. 11-120487
[Patent Document 5]
JP 2002-297390 A
[0008]
[Problems to be solved by the invention]
The methods disclosed in Patent Documents 1 to 3 for performing software upgrade using the wireless communication function of a mobile device enable the mobile device to perform wireless communication with a master station or a control station via a network. It is possible to upgrade the software version at the position. However, since the propagation state of radio waves fluctuates significantly, there is a problem that if the propagation state of radio waves is not good, it is necessary to repeat retransmission processing, and the time required for version upgrade becomes long. In addition, the dedicated device for version upgrade can efficiently upgrade the software for the mobile device, but the dedicated device is expensive unlike general-purpose computers, etc., and it is expensive to install in all sales offices. There is a problem.
[0009]
In the process of upgrading software for mobile devices, if the memory capacity required by the new version upgrade software is larger than the memory capacity required by the old version software, the version upgrade will be performed if there is no other free space. Can not do. In addition, there is a problem that rewriting processing for changing the area arrangement in the memory is required to store software to be upgraded when there is free space.
[0010]
In the version upgrade process, the above-mentioned patent can reduce the amount of transfer data required for version upgrade by applying differential compression technology and transferring the difference between the old version software and the new version software. It has been proposed as shown in Document 4 and Patent Document 5. However, conventionally, when an error occurs in the upgrade process, the upgrade process is restarted from the top of the software to be upgraded. Therefore, there is a problem that the time required for the version upgrade becomes longer due to the occurrence of an error in the version upgrade process. In addition, software for a general-purpose computer or the like can be managed for a plurality of generations, but such generation management is not performed for a mobile device. Therefore, when transferring the above-described difference, the difference differs depending on the version, but this cannot be dealt with.
[0011]
The present invention solves the above-described conventional problems, and it is possible to efficiently upgrade software from a mobile device or a computer of the same model or a similar model to a modified mobile device that performs software upgrade. The purpose is to do.
[0012]
[Means for Solving the Problems]
The version upgrade method of the present invention will be described with reference to FIG. 1. The upgrade mobile device 1 to be upgraded is transferred from the upgrade mobile device 2 or the upgrade computer 3 via the cables 4 and 5 to the software. A version upgrade method for performing version upgrade, wherein the upgrade mobile device 2 or the upgrade computer 3 stores differentially compressed data between the new version software and the old version software, and the software version number and new version of the modified mobile device 1 The management information including the software version number and the differential compressed data in block units are transferred to the modified mobile device 1 through the cables 4 and 5, and the modified mobile device 1 decompresses and decompresses the differential compressed data. And a process of sequentially writing to the nonvolatile memory.
[0013]
The upgrade mobile device 2 or the upgrade computer 3 is connected to the repair mobile device 1 with cables 4 and 5 and transfers the software repair program. The repair mobile device 1 is connected to the upgrade mobile device 2 or version. The block unit differential compressed data is sequentially received from the up computer 3, and when the decompressed and expanded data is written in the nonvolatile memory area according to the software modification program, the old version data in this area is saved and written. Stores the number of the block due to the end of normal writing. When an error occurs in differential compressed data in this block unit or in the writing process, the saved old version data is restored and the reception of the differential compressed data is started. The process of restarting the writing process to the nonvolatile memory from the data of the block number next to the stored block number is resumed. It can contain.
[0014]
Further, a plurality of libraries in the initial state to be stored in the nonvolatile memory of the refurbished mobile device 1 can be respectively stored with an empty area interposed therebetween, and the library increment due to version upgrade can be absorbed by the empty area. In addition, the number of detected bugs of each library is obtained, and the library with a small number of detected bugs is stored on the non-volatile memory address number side, and the library with a large number of bug detected numbers is stored on the non-volatile memory address old number side. To do.
[0015]
Further, the upgrade mobile device 2 or the upgrade computer 3 holds the differential compressed data of the multiple generations of the old version software and the new version software, and management information including version number information, and stores the differential compressed data. The data can be held in block units for sequential transfer to the modified mobile device 1.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a diagram for explaining the principle of the present invention. A refurbished mobile device 1 for upgrading software and a mobile device 2 for upgrading equipped with the latest software are connected by a cable 4 for serial transfer. Then, the latest software is serially transferred from the upgrade mobile device 2 to the modified mobile device 1 to upgrade the software. The upgrade mobile device 2 in this case is of the same model or a similar model as the modified mobile device 1, and the mobile device 2 transfers the latest software from a software creation computer (not shown). The stored configuration. Therefore, when software upgrade is required, the upgrade service for the user's mobile device 1 can be easily implemented by distributing the upgrade mobile device 2 storing the latest version of the created software to various places. can do.
[0017]
Alternatively, the upgrade mobile device 1 and the upgrade computer (PC) 3 loaded with the latest software are connected by the serial transfer cable 5, and the latest upgrade software 3 is updated from the upgrade computer 3 to the upgrade mobile device 1. Serially transfer the software and upgrade the software.
[0018]
In this case, the difference data between the old version software and the new version software is further compressed and encoded, transferred to the modified mobile device 1 via the cable 4, and decompressed and differentially expanded in the modified mobile device 1. In other words, the software is upgraded to a new version by writing to a rewritable nonvolatile memory such as an EEPROM (Electrically Erasable Programmable Read Only Memory). In either case, stable version upgrade processing can be performed by connecting the cables 4 and 5 for serial transfer.
[0019]
FIG. 2 is an explanatory diagram of the first embodiment of the present invention. 1 is a modified mobile device for upgrading the software owned by the user, 2 is a VU (for version upgrade) mobile device, and 7 is for version upgrade. Personal computer (personal computer) 11 for creating and holding software, 11 boot program, 12 old program, 13 new program, 15 load module (LM), 17 control processing unit of personal computer 7, 18 Is the differential compressed data, 19 is the various programs / management data, 21 is the various programs of the VU mobile device 2, 22 is the management data including the version number of the program, and 23 is the differential compressed data. In addition, the processing route of the upgrade is shown by the routes 1) to 9). The old program 12 and the new program 13 of the modified mobile device 1, the various programs 21 of the VU mobile device 2, the management data 22 and the differential compression data 23 are The data is stored in the rewritable nonvolatile memory described above.
[0020]
The control processing unit 17 of the personal computer 7 loads the new software load module LM 1) binary (binary), 2) extracts the difference between the old version software and the new version software, and 3) compresses and encodes the extracted difference. Then, it is stored in the memory as the differential compressed data 18. Then, 4) management information is generated for the version of the new software, etc., and stored in the memory as various programs / management data 19.
[0021]
Then, the personal computer 7 and the VU mobile device 2 are connected by a serial cable, and 5) Various programs 21, management data 22, and differential compression data 23 of the personal computer 7 are transferred and stored by a loader. The VU mobile device 2 and the modified mobile device 1 are connected by a serial cable as described with reference to FIG. 1. 6) In the modified mobile device 1, 7) Boot expansion is performed, and the differential compressed data is 8) Decompression and 9) Differential expansion are performed, and the old program in the non-volatile memory is rewritten with the new program to upgrade the version.
[0022]
In this case, the differentially compressed data transferred from the VU mobile device 2 to the modified mobile device 1 is transferred in units of preset blocks, and an error check is performed in correspondence with the block, resulting in a new program containing no errors. The upgrade process is performed as follows. Also, for example, the block number where data writing to the non-volatile memory was completed normally in block units is stored, and if an abnormality occurred during the version upgrade process, the block number which was normally completed is stored, so the version number is stored. The writing process to the non-volatile memory by resuming the up process is resumed from the block after the normal completion. Non-volatile memory such as flash memory has a relatively long write processing time, so restarting the write processing from the block after the normal end of the block will save time for upgrading even if an error occurs. It can be shortened.
[0023]
FIG. 3 is an explanatory diagram of the second embodiment of the present invention. 1 is a modified mobile device that upgrades software, 3 is a computer for upgrading (PC), and 7 is software for upgrading. Computer (personal computer), 11 is a boot program, 12 is an old program, 13 is a new program, 15 is a load module (LM), 17 is a control processing unit of the personal computer 7, 18 is differentially compressed data, 19 Is a program / management data, 31 is a control processing unit, 32 is a rewritten DLL (Dynamic Link Library), 33 is management data, and 34 is differential compression data. In addition, 1) to 8) indicate upgrade paths.
[0024]
The upgrade computer (personal computer) 3 corresponds to the VU mobile device 2 in FIG. 2, and this personal computer 3 and the modified mobile device 1 are connected by a USB (Universal Serial Bus) cable and refurbished. The case where the software version of the machine 1 is upgraded is shown. The personal computer 7 has the same configuration as the personal computer 7 in FIG. 2, and transfers the differentially compressed data to the personal computer 3 on which a software rewriting application is installed under the control of the control processing unit 17. A version upgrade process is executed on the differentially compressed data from the personal computer 3 to the modified mobile device 1 through the same process as described with reference to FIG.
[0025]
FIG. 4 is an explanatory diagram of the memory. LIB (Library), B.I. LIB, C.I. LIB, D.M. If LIB,... Are stored at consecutive addresses in the memory, the library A. When version upgrade processing is performed by changing the LIB, the library A.1 is changed from the old memory to the new memory. LIB change increments, other libraries B. LIB, C.I. LIB, D.M. The storage address of LIB,. That is, the library A.I. According to the change increment of LIB, other libraries B. LIB, C.I. It becomes necessary to rewrite LIB,. Thereby, the time required for rewriting increases. Since a non-volatile memory such as a flash memory is usually used, the time required for writing is longer than that of a random access memory and requires writing power, so that a large amount of data is written to the erased area. And it takes a long time and the power consumption increases.
[0026]
Therefore, in the present invention, as shown as the old version in FIG. LIB, B.I. LIB, C.I. LIB, D.M. A free area is formed between LIB,... And stored in the memory. Thereby, for example, library A.I. Even if there is an increment due to a change in the LIB, it is possible to absorb the increment using the free area as in the new version of the memory, so that the amount of memory update is small.
[0027]
FIG. 6 shows a case where the memory update amount is further reduced. As in the memory shown as the old version, a free area is formed between the libraries, and the allocation order is changed by processing as described later. In this case, the possibility of library modification is estimated based on the number of detected bugs in the past, and a library with a high possibility of modification is stored in the old number side of the memory address. For example, library D.I. LIB, C.I. LIB, A.M. LIB, B.I. The case where the order of LIB,. For example, the library A. Even if there are incremental changes due to LIB modifications, the library B.I. Since only the LIB needs to be lowered, the amount of memory update is further reduced. That is, with respect to the memory change difference, FIG. 4 in which no free space is formed between libraries is the largest, and FIG. 5 in which free space is next formed between libraries is the middle. Then, FIG. 6 in which the allocation order of the library that is likely to be updated is the oldest address side is the smallest.
[0028]
FIG. 7 shows a flowchart of the in-memory arrangement process. Whether or not the number n of the library (LIB) stored in the memory has been repeated, i.e., whether or not i = 1 to i = n has been repeated. (A1), and the number of bugs detected in the i-th library (LIB) is counted from the past results (A2). Then, it is determined whether or not the library (LIB) is the first (i = 1) (A3). If i = 1, the library is placed at the lowest number (A4). In addition, the library (LIB) where i is not 1 performs rearrangement processing (A5). Although specific steps are not shown, the rearrangement of the arrangement of the library (LIB) is completed by repeating the steps (A2) to (A5) from i = 1 to i = n. .
[0029]
As shown in FIG. 8, the rearrangement processing of the library (LIB) arrangement in step (A5) described above is repeated for the number of stored libraries (LIB). In this case, j = 1 to It is determined whether or not iterative processing up to j = i−1 has been performed (B1), and whether or not the bug detection number of the i-th library determined this time is smaller than the bug detection number of the j-th library determined in the past. If it is smaller, the i-th library is placed in front of the j-th library (B3). However, if it is large, it is not arranged. Therefore, in step (B2), a library (LIB) larger than the number of bugs detected in the already-arranged library (LIB) is not placed in step (B3), and in step (B2) by the next iteration. When the order comes around, they are compared again.
[0030]
Then, it is determined whether or not the comparison has been made up to the (i-1) th library (LIB) (B4). If not compared, the process returns to the first step (B1). Since this library (LIB) has a bug detection number larger than the bug detection number of the library (LIB) arranged in step (B3), it is arranged in the oldest number of addresses (B5). Therefore, the libraries (LIBs) are rearranged in the order of decreasing bug detection number.
[0031]
By such processing, the library is arranged as shown as the old version in FIG. In other words, libraries that have a large number of bug detections are likely to be revised, so they are placed on the oldest address side of the memory address, and libraries that are estimated to be less likely to be revised are placed on the younger address side. To do. As a result, the possibility of rearranging other libraries becomes extremely low, which can contribute to shortening the time required for version upgrade.
[0032]
FIG. 9 is an explanatory diagram of the load module conversion tool, 41 is a memory storing the load module LM1 (program), 42 is a memory storing the load module LM2 (data), 43 is a definition file, and 44 is a load module conversion tool. , 45 is a binary conversion unit, 46 is a load module (LM) merging unit, and 47 is a memory storing binary data.
[0033]
First, (1). The definition file 43 describes a conversion target file name, a conversion target address range, a conversion exclusion address range, an output file name, and the like. The load module conversion tool 44 reads the definition file 43. Next, (2). Based on the information specified by the read definition file 43, the old and new load module files are converted into binary data by the binary conversion unit 45. Next, (3). The load module merge unit 46 merges binary data. Thereby, binary data is stored in the memory 47.
[0034]
FIG. 10 is an explanatory diagram of a differential compression tool, 61 is a memory storing a new load module (binary data), 62 is a memory storing an old load module (binary data), 63 is a difference extraction tool, and 64 is a split / Indicates difference data. The difference extraction tool 63 obtains the difference between the new load module and the old load module as binary data, and obtains the divided / compressed data 64 by compression processing. In this case, the divided / compressed data 64 can be divided, for example, in units of 256 kbytes so as to be easily mounted on the mobile device.
[0035]
FIG. 11 is an explanatory diagram of a transfer data creation tool for storing version upgrade data for a VU mobile device, 71 is a memory storing a new version load module (LM), 72 is a load module (LM) creation Tool 73 is a memory storing differential data corresponding to multiple generations (multiple versions) as old version difference 1, old version difference 2,... 74 is a definition file, 75 is a load module (LM) creation tool 72 A memory storing the created management information load module (LM), differential real data 1, differential real data 2,.
[0036]
In this case, as shown in FIG. 2, a case of creating transfer data in the case where version upgrade from the VU mobile device 2 to the modified mobile device 1 is shown. First, the load module (LM) creation tool 72 performs (1). The conversion target file name, conversion target program version number, conversion file number, divided block size, etc. are read from the definition file 74. And (2). A new version load module (LM) (binary format) is read from the memory 71 and a CRC (Cyclic Redundancy Check) is generated. (3). The difference data according to the conversion target program version number is read from the memory 73, and the size of each difference data is obtained. And (4). The difference transfer management information and the difference actual data corresponding to the version number are output in a format that can be loaded into the VU mobile device 2 and stored in the memory 75 together with the data obtained by the above processing.
[0037]
FIG. 12 is an explanatory diagram of a transfer data creation tool, in which 81 is a memory storing a new version load module (LM), 82 is a load module (LM) creation tool, 83 is the latest simple compressed data, old version difference 1, old version difference 2,... 84, a definition file, and 85, a memory storing transfer data.
[0038]
In this case, as shown in FIG. 3, a case of creating transfer data in the case where version upgrade from the personal computer 3 to the modified mobile device 1 is shown. First, the load module (LM) creation tool 82 is (1). The conversion target file name, conversion target program version number, conversion file number, division block size, etc. are read from the definition file 84, and then (2). Read the new version load module (LM) (binary format) from the memory 81 and generate a CRC, (3). Read the difference data from the memory 83 and obtain the size of each difference data (4). The differential transfer management information, the latest version load module (LM) simple compressed file, and the version-specific differential actual data file are loaded into the personal computer 3 in binary format together with the data obtained by the above processing.
[0039]
FIG. 13 is an explanatory diagram of transfer data, showing transfer data when upgrading from the VU mobile device 2 to the modified mobile device 1 shown in FIG. 2, and 91 is file management data and difference management data corresponding to the mobile device Management information 92 includes a difference information load module (LM) corresponding to the version number of the program.
[0040]
14 and 15 are explanatory diagrams of the management load module, showing management information when upgrading from the VU mobile device 2 to the modified mobile device 1 shown in FIG. 2, and the number of stored files, the latest rewritten version, the latest Including the program version number, CRC32 data after completion of differential writing, etc., the old version program version number for the difference corresponding to the version number, the difference management data write destination ROM address in the upgrade mobile station, and the actual difference data in the upgrade mobile station It includes a write destination ROM address and difference management data for each file. As shown in FIG. 15, the difference management data for each file includes the number of difference blocks in the corresponding file, the difference division unit (bytes), the first transfer destination ROM address, and the first difference block size. And CRC32 data after applying the first difference is stored in correspondence with the number of difference blocks. With such a configuration, management can be performed for a plurality of generations.
[0041]
FIG. 16 is an explanatory diagram of a file structure when the version is upgraded from the personal computer 3 shown in FIG. 3 to the modified mobile device 1, and shows file management based on a hierarchical directory structure. An example of the management file is shown in FIG. This management file includes the number of stored files, the latest rewritten version, the latest program version number, the CRC32 data after completion of differential writing, the software update program file size, the software update program file name, and the version number of the previous version of the program corresponding to the version number. Difference data file management information storage destination offset value, difference information file storage directory name, and difference management data for each file. The difference management data for each file includes the number of difference files in the corresponding directory, the difference division unit ( Byte), a difference information file size for each difference information file, a difference information file name, and CRC32 data after application of the difference are stored.
[0042]
FIG. 18 shows an added serial command when the upgrade process is performed from the VU mobile device 2 (see FIG. 2) to the modified mobile device 1, and “command” is omitted. P1, P2,... Indicate parameters. As for the direction, the left-pointing arrow indicates the direction from the repair mobile unit 1 to the VU mobile unit 2, and the right-pointing arrow indicates the direction from the VU mobile unit 2 to the retrofit mobile unit 1.
[0043]
The mobile device version number notification serial transfers version information including the CRC from the modified mobile device 1 to the VU mobile device 2, whereby the VU mobile device 2 identifies the version number of the modified mobile device 1. The data corresponding to the version number is determined. In addition, when the serial number notification serial is determined to be a version upgrade target based on the version information received from the modified mobile device 1, the VU mobile device 2 indicates the latest software version number and the rewritten version number to the modified mobile device 1. Send. The check result notification serial transmits the check result from the modified mobile device 1 to the VU mobile device 2. The write data transmission serial transmits a write address, CRC data after writing, a transmission size, and write data from the VU mobile device 2 to the modified mobile device 1. The write information transmission serial transmits the CRC values of all system areas for checking the consistency after transmitting all the upgraded data.
[0044]
The all area check result notification serial transmits the check result from the repair mobile 1 to the VU mobile 2. The upgrade completion transmission serial notifies the upgrade mobile device 1 from the VU mobile device 2 of the upgrade completion. The error notification serial notifies an error to the other party when an error occurs in the modified mobile device 1 and the VU mobile device 2. As a result, an error is displayed on the display screen.
[0045]
FIGS. 19 and 20 are sequence explanatory diagrams in the case of upgrading from a VU mobile station to a modified mobile station, and the parameter P1 of FIG. 18 is shown in parentheses. First, in the VU mobile device, 1) the power is turned on, and the modified mobile device is connected by a serial data transfer 2) cable. 3) Turn on the power of the repaired mobile device and activate the soft writing mode. 4) 1 of the VU mobile device (showing “1” in the numeric keypad, but specify with other keys) It is also possible to make a request to start a software refurbishment program, and 5) transfer the software refurbishment program to the remodeling mobile device.
[0046]
The repair mobile device receives the software repair program, starts the repair process, and checks whether the battery voltage of the repair mobile device is a voltage that can guarantee normal operation. 6) Protected area (non-upgrade target area) The area checksum is calculated to enter the mode change / recovery waiting mode, and 7) the current version information is sent from the modified mobile unit to the VU mobile unit (80). That is, the mobile device version number notification serial command is executed. The VU mobile device determines whether or not it is a version upgrade target from the version information from the modified mobile device, and ends the process if the mobile device is not a target. In the case of a mobile device to be upgraded, 8) new version information is notified to the repaired mobile device (N). That is, the new version number notification serial command is executed.
[0047]
The modified mobile device receives the new version information and notifies the check result to the VU mobile device (C). That is, a check result notification serial command is executed. The VU mobile device 10) transfers the differentially compressed data for each block (W). That is, the write data transmission serial command is executed. In this case, management information including the version number is also transferred from the VU mobile device. The modified mobile device decompresses and decompresses the differential compressed data in block units according to the software modified program, and 11) performs ROM writing and performs CRC calculation on the target area. Then, 12) the received CRC value is compared with the CRC value of the calculation result, and the comparison result is notified to the VU mobile station (C). That is, a check result notification serial command is executed. Then, the processes 10) to 13) are repeated 14) for the number of blocks.
[0048]
Then, when the VU mobile station receives the CRC notification of the final block, it sends 15) a writing status check to the modified mobile station (I). That is, the write status transmission serial command is executed. The modified mobile device recalculates the checksum for the protected area (area other than the upgrade target area) and compares it with the checksum obtained before writing. In the case of a comparison match, it can be seen that the protected area due to the version upgrade is not affected. Also, the checksum of the program area is obtained and compared with the checksum transferred from the VU mobile station by the writing status check notification. 16) The comparison result is transferred to the VU mobile station (P). That is, the serial check result notification serial command is executed. If the VU mobile device determines that there is no error based on the comparison result, 17) notifies the upgrade mobile device of the completion of the upgrade (Z). That is, the upgrade completion transmission serial command is executed. 18) The modified mobile device thereby changes the mode to the normal mode.
[0049]
FIG. 21 to FIG. 23 are sequence explanatory diagrams in the case of upgrading from a personal computer (PC) to a modified mobile device, and the parameter P1 in the serial command shown in FIG. 18 is shown in parentheses. 19 and 20, the version is upgraded by the same processing as the sequence shown in FIG. 19 and FIG. 20. First, the personal computer and the modified mobile device are connected with a USB cable, and before the upgrade, the model based on the mobile device serial number is used. Check whether the PC is correct, whether it is normal mode or standby mode, whether it is a restoration rewrite request, whether it is a normal mode when a restoration rewrite request is made, and after confirming the version, start notification from the personal computer to the mobile station I do. After that, as shown in the serial information parameter P1, the version upgrade is performed in the same sequence as the version upgrade operation sequence shown in FIG. 19 and FIG.
[0050]
24 and 25 show an operation sequence at the time of an error when a version upgrade is performed from a VU mobile device to a modified mobile device, and (W), (E), and (C) are shown in FIG. The parameter P1 of the serial command is shown. The Nth (Nth block from the head in block units) differential compressed data is transferred from the VU mobile device to the modified mobile device (W). That is, the write data transmission serial command is executed. The modified mobile device normally writes the previous (N−1) th differential compressed data in the nonvolatile memory and updates the write completion position to “N−1”. Then, the differentially compressed data is decompressed and expanded, the old data is saved, and the ROM (nonvolatile memory) is erased and written. That is, for each transfer of the differentially compressed data, the (transfer count−1) -th writing completion position is updated, and the old data is saved before the ROM writing. For example, if an error occurs during writing to the ROM, the saved old data is restored and an error occurrence notification is sent to the VU mobile device (E). That is, an error notification serial command is transmitted.
[0051]
The VU mobile device starts the version upgrade process again in response to the error occurrence notification. That is, the differential compressed data of the first block is transferred to the modified mobile device, and the modified mobile device performs only the CRC calculation and does not perform the ROM writing process. Then, the check result is notified to the VU mobile device, and the VU mobile device transfers the differential compression data of the second block to the modified mobile device. By repeating this, when the modified mobile unit receives the differential compression data of the Nth block that has not been written to the ROM due to the previous error, the write completion position is updated to 'N-1' and differential compression is performed. The data is decompressed and expanded, the old data is saved, the ROM is erased and written, the CRC operation is performed, and the check result is notified to the VU mobile device. The write completion position is set to “N”. Also, the N + 1th and subsequent differential compressed data are written in the ROM by the same processing. Therefore, when an error occurs, the VU mobile device sequentially transfers the differential compressed data for version up from the first, but the modified mobile device stores the write completion position when the error occurs. Thus, the ROM writing is performed every time the differentially compressed data of the block after the previous writing completion position is received, and the required time can be shortened as compared with the case where the ROM writing is repeated from the head.
[0052]
FIG. 26 and FIG. 27 are explanatory diagrams of an operation sequence at the time of version upgrade from a VU mobile device to a refurbished mobile device. The VU mobile device is turned on (1), thereby “SET TEE CABLE AND TURN ON THE ANOTHER”. “MS THEN PUSU 1 KEY” is displayed on the display screen of the VU mobile device. Therefore, the VU mobile device and the modified mobile device are connected with a dedicated cable (2). Then, the power of the repaired mobile device is turned on (3). Thereby, the light emitting diode LED of the modified mobile device is lit for a moment.
[0053]
Next, the “1” key of the VU mobile device is pressed (4). At that time, the display screen of the modified mobile device is a blank screen. Then, the upgrade process is started, and the display screen of the VU mobile device shifts to a check screen for the model and version of the refurbished mobile device, a display screen for the differential compressed data ratio, and an end screen by checking OK. In the modified mobile device, the light-emitting diode LED is turned on and off to indicate that it is being downloaded, and the display screen is finally the end screen. Then, the dedicated cable is disconnected (5), and the VU mobile device and the modified mobile device are turned off (6). As described above, the operation procedure can be displayed on the display screens of the VU mobile device and the modified mobile device.
[0054]
FIG. 28 and FIG. 29 are explanatory diagrams of an operation sequence at the time of version upgrade from a personal computer to a repaired mobile device. The personal computer PC and the repaired mobile device are connected with a USB cable (1), and the software rewriting application of the personal computer PC is executed. Version upgrade is started by pressing the button (2). In the modified mobile device, the LED blinks twice, and then the lighting continues. The display screen is a blank screen. Then, when the data transfer from the personal computer PC is completed, the LED is turned off, and then the LED is turned on, and the rewriting process for the ROM is displayed on the display screen. Upon completion, “COMPLETED” is displayed, and the LED is turned off. Then, a standby screen is displayed by automatic reset, the USB cable is removed, and the version upgrade process is terminated (3). In addition, although an example of the arrangement configuration of the LCD (liquid crystal display) screen and the LED (light emitting diode) of the mobile device is illustrated, other arrangement configurations are possible, and the LED as a user interface is also possible. The lighting control and display screen display control are not limited to the above-described embodiment.
[0055]
FIG. 30 is an explanatory diagram of an error display, and shows an example of a display when an error occurs when upgrading from a VU mobile device to a modified mobile device. For example, display contents such as an error of a mobile device type and an error due to a checksum comparison are shown. When various other errors occur, the error type can be displayed so that it can be recognized.
[0056]
【The invention's effect】
As described above, the present invention transfers data obtained by further compressing the difference between the new version software and the old version software from the upgraded mobile unit or the personal computer to the modified mobile unit via a cable. Management information including software version information is also transferred, and the repair mobile unit decompresses and decompresses the differential compressed data in block units in accordance with the software repair program, and sequentially writes it into a rewritable nonvolatile memory. The normal writing completion is stored for each block. When an error occurs, writing to the non-volatile memory is performed from the block next to the block in which normal writing is completed.
[0057]
Therefore, the upgrade process of the refurbished mobile device can use a mobile device that is easy to carry, and can also be executed from a personal computer. It becomes. Further, since the data is compressed and encoded in units of blocks, the amount of transfer data can be reduced and the time required for version upgrade can be shortened. Even when an error occurs, the time required for version upgrade can be shortened by writing to the nonvolatile memory from the error occurrence block. For example, for the same software, the time required for version upgrade in the case of the conventional method, on average, took about 23 minutes, but according to the embodiment of the present invention, it can be as short as 3 minutes and 9 seconds. The average was 4 minutes 59 seconds.
[0058]
In addition, it is possible to download the differential compressed data corresponding to the version number of the modified mobile device while holding the differential compressed data with the new version software corresponding to the old version number, for one upgrade mobile device or version upgrade The computer can support various types of modified mobile devices. In addition, a space is created between the areas corresponding to the library of the non-volatile memory, and the library with a large number of bug detections is placed on the old address side of the address. There is an advantage that the time required for version upgrade can be shortened by reducing the probability of the above.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating the principle of the present invention.
FIG. 2 is an explanatory diagram of the first embodiment of the present invention.
FIG. 3 is an explanatory diagram of a second embodiment of the present invention.
FIG. 4 is an explanatory diagram of a memory.
FIG. 5 is an explanatory diagram of a memory.
FIG. 6 is an explanatory diagram of a memory.
FIG. 7 is a flowchart of an in-memory arrangement process.
FIG. 8 is a flowchart of a rearrangement process.
FIG. 9 is an explanatory diagram of a load module conversion tool.
FIG. 10 is an explanatory diagram of a differential compression tool.
FIG. 11 is an explanatory diagram of a transfer data creation tool.
FIG. 12 is an explanatory diagram of a transfer data creation tool.
FIG. 13 is an explanatory diagram of transfer data.
FIG. 14 is an explanatory diagram of a management load module.
FIG. 15 is an explanatory diagram of a management load module.
FIG. 16 is an explanatory diagram of a file configuration.
FIG. 17 is an explanatory diagram of a management file.
FIG. 18 is an explanatory diagram of an added serial command.
FIG. 19 is an explanatory diagram of a version upgrade operation sequence.
FIG. 20 is an explanatory diagram of a version upgrade operation sequence.
FIG. 21 is an explanatory diagram of a version upgrade operation sequence.
FIG. 22 is an explanatory diagram of a version upgrade operation sequence.
FIG. 23 is an explanatory diagram of a version upgrade operation sequence.
FIG. 24 is an explanatory diagram of an operation sequence when an error occurs.
FIG. 25 is an explanatory diagram of an operation sequence when an error occurs.
FIG. 26 is an explanatory diagram of an operation sequence at the time of version upgrade.
FIG. 27 is an explanatory diagram of an operation sequence at the time of version upgrade.
FIG. 28 is an explanatory diagram of an operation sequence at the time of version upgrade.
FIG. 29 is an explanatory diagram of an operation sequence at the time of version upgrade.
FIG. 30 is an explanatory diagram of error display.
[Explanation of symbols]
1 Refurbished mobile equipment
2 Mobile device for version upgrade (VU mobile device)
3 Upgrade computer (PC)
4,5 cable

Claims

In a version upgrade method in which software is upgraded via a cable from a version upgrade mobile device or a version upgrade computer to a modified mobile device to be upgraded.
The upgrade mobile device or the upgrade computer holds differential compressed data between the new version software and the old version software, and includes management information including the version number of the modified mobile unit software and the version number of the new version software, The differential compressed data in block units is transferred to the modified mobile device via the cable, and the modified mobile device interposes a plurality of libraries in an initial state in a nonvolatile memory with free areas for absorbing the increments. The number of detected bugs of the plurality of libraries is obtained, and a library having a small number of detected bugs is assigned to a non-volatile address of the nonvolatile memory, and a library having a large number of detected bugs is stored in the nonvolatile memory. Including a process of storing in the old number side, decompressing and decompressing the differentially compressed data, and sequentially writing to the nonvolatile memory Version upgrade method characterized by

The upgrade mobile device or the upgrade computer is connected to the modified mobile device with the cable and transfers a software repair program. The modified mobile device is the upgrade mobile device or the upgrade mobile device. When the differentially compressed data in units of blocks from the computer is sequentially received and the decompressed and expanded data is written in the non-volatile memory area according to the software modification program, the old version data in the area is saved and written. Stores the block number at the end of writing, and restores the saved old version data when the error occurs in the block-unit differential compressed data or the writing process, and starts receiving the differential compressed data And the non-volatile memory from the data of the block number next to the stored block number Upgrade method of claim 1, characterized in that it comprises a process resumes writing process against.

The upgrade mobile device or the upgrade computer holds differential compressed data of a plurality of generations of old version software and new version software, management information including version information, and stores the differential compressed data. 3. The version upgrade method according to claim 1, wherein the upgrade method is stored in units of blocks for sequential transfer to the modified mobile device .