JP2004005637A

JP2004005637A - インシステムプログラミングのための方法および構成

Info

Publication number: JP2004005637A
Application number: JP2003130523A
Authority: JP
Inventors: James W Page; ジェームズ・ダブリュ・ページ; Christopher B Brandt; クリストファー・ビィ・ブランド
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2002-05-09
Filing date: 2003-05-08
Publication date: 2004-01-08
Anticipated expiration: 2023-05-08
Also published as: US6795872B2; JP4037317B2; US20030217254A1

Abstract

【課題】ＵＳＢインターフェイスを用いて不揮発性プログラマブル電気的消去可能なメモリをプログラムするための方法および装置を特定する。
【解決手段】方法は、ＵＳＢバス上の第１のハードウェア構成を備えた少なくとも１つのデバイスを列挙するステップと、カスタムプロトコルに従いプログラミングコマンドとプログラムデータとをカプセル化してＵＳＢパケットにするステップと、カプセル化されたプログラミングコマンドとプログラムデータとを含むＵＳＢパケットをＵＳＢバスを介して少なくとも１つのデバイスに送信するステップと、少なくとも１つのデバイスでのプログラミングコマンドとプログラムデータとの受信に応じてデバイスメモリの少なくとも一部をプログラムするステップとを含む。第１のハードウェア構成が定義する少なくとも１つのデバイスの少なくとも部分的な機能は、デバイスメモリがプログラムされる間維持される。
【選択図】　　　　図６

Description

【０００１】
【背景】
この発明は、不揮発性メモリをプログラムすることに関し、より具体的には、ユニバーサルシリアルバス（ＵＳＢ）インターフェイスを用いて電気的消去可能な不揮発性メモリをプログラムするための方法および装置に関する。
【０００２】
ＵＳＢは急速に、低速から中速のパーソナルコンピュータ（ＰＣ）から周辺デバイスへの相互接続のためのデファクトバスインターフェイススタンダードとなっている。ＵＳＢインターフェイスは、高速プリンタ、ＣＤ品質のオーディオプレイバック、および高解像度スキャナをサポートするのに十分なほど速い転送速度を達成する。ＵＳＢ拡張ハブによって、バスが多数のＵＳＢ対応デバイスを同時にサポートすることが可能となる。ＵＳＢの機能および能力に関する詳細な情報は、ユニバーサルシリアルバス仕様書、改訂版２．０（２０００年４月２７日）から見つけられ得る。
【０００３】
ＵＳＢは、いくつかの理由から流行した。まず、たとえＰＣの電源が入っているときでも、ＵＳＢデバイスは、いつでもバスに接続され得、この特徴は、通例、産業界では「プラグアンドプレイ」と呼ばれる。ＵＳＢデバイスが接続されたことがＰＣによって検出されると、ＰＣは自動的にデバイスに対して問合せをしてその能力および要件を知る。この情報を用いて、ＰＣは次に、デバイスのドライバをオペレーティングシステムへと自動的にロードする。後に、デバイスがバスから抜かれると、オペレーティングシステムは自動的にバスからデバイスを「ログオフ」し、そのドライバをシステムからアンロードする。
【０００４】
ＵＳＢインターフェイスの人気が高まりつつある別の理由は、バスに装着されるデバイスを適切に構成するためにＤＩＰスイッチを手作業で設定し、ジャンパを挿入し、または構成プログラムをロードする必要性が、組込まれたプラグアンドプレイ能力によって解消されるためである。また、デバイスを今日の従来のシリアルおよびパラレルＩ／Ｏバスに接続したときに通常起こるハードウェアコンフリクト（たとえば、ＩＲＱ、ＤＭＡ、メモリ、またはＩ／Ｏコンフリクト）が、ＵＳＢに接続されるデバイスによって結果として生じることはない。
【０００５】
ＵＳＢデバイスは、デバイスの動作を制御する、内部に記憶されたソフトウェア（またはファームウェア）を備えて販売される。このファームウェアは、通例、インテル社（Ｉｎｔｅｌ　Ｃｏｒｐｏｒａｔｉｏｎ）によって開発された人気のあるフラッシュメモリ等の不揮発性電気的消去可能なプログラマブルメモリに記憶される。ＵＳＢ対応デバイスを購入したユーザは、場合によっては、このファームウェアを改良バージョンまたはファームウェアパッチを用いてアップグレードする能力を必要とし得、このようなアップグレードはデバイス製造業者から入手可能である。
【０００６】
これらのファームウェアのアップグレードは、いくつかのやり方で行なわれ得る。たとえば、ファームウェアがデバイス内の別個のメモリモジュール上に記憶されている場合、モジュールは、デバイスから除去され、ファームウェアの更新を含んだ新しいメモリモジュールと取換えられ得る。この手作業のアップグレード方法は、実行が困難かつ時間のかかるものであると同時に、アップグレードを行なうためにはデバイスの電源を切ることが通例必要とされるという不利な点を有する。また、この手作業の方法は、ファームウェアがデバイス内の専用メモリモジュール上に記憶されていることを必要とし、これは、デバイス内のメモリが非効率的に用いられることにつながるおそれがある。
【０００７】
周辺デバイスにインストールされたファームウェアをアップグレードするためのより容易でより効率的な方法は、既存のデバイスＩ／Ｏバスを用いてファームウェアコードをアップグレードすることであった。この方法では、全ファームウェアプログラムが、まず消去され、次に新しいファームウェアコードによって上書きされ得るか、または当初インストールされたファームウェアの一部のみが対応のファームウェア「パッチ」で上書きされ得るかのいずれかである。
【０００８】
代替的には、ハードウェアは、ファームウェアパッチが特別に確保されたシステムメモリ部分にインストールされ、次に特定のプログラム条件下で自動的に実行されてファームウェアのアップグレードを行なうことを可能にするように構成され得る。このような構成は、この出願と同じ譲受人に譲渡される「記憶されたプログラムを動的に修正するための方法および装置」（“Ｍｅｔｈｏｄ　ａｎｄ　Ａｐｐａｒａｔｕｓｆｏｒ　Ｄｙｎａｍｉｃａｌｌｙ　Ｍｏｄｉｆｙｉｎｇ　ａ　Ｓｔｏｒｅｄ　Ｐｒｏｇｒａｍ”）と題された同時係属米国特許出願第０９／８９６，７９０号に記載される。
【０００９】
既存のＩ／Ｏバスを用いてデバイスに記憶されたファームウェアコードをアップグレードするためには、ファームウェアアップグレードプロセスを制御および監督する転送プロトコルを開発することがまず必要とされる。一般に、ファームウェアをアップグレードするために用いられる各対応のＩ／Ｏバスタイプに対して、異なる転送プロトコルが開発されなければならない。
【００１０】
ＵＳＢの場合、ＵＳＢ対応デバイス内でファームウェアアップグレードを行なうための転送プロトコルが、ＵＳＢ作成者フォーラム（Ｉｍｐｌｅｍｅｎｔｏｒｓ　Ｆｏｒｕｍ）（ＵＳＢ−ＩＦ）によって提案された。このグループは、「デバイスファームウェアアップグレードのためのユニバーサルシリアルバスデバイスクラス仕様書」（“Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ　Ｄｅｖｉｃｅ　Ｃｌａｓｓ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　ｆｏｒ　Ｄｅｖｉｃｅ　Ｆｉｒｍｗａｒｅ　Ｕｐｇｒａｄｅ”）（バージョン１．０、１９９９年５月１３日）と題された、その提案された転送プロトコルのための文献を発表した。この文献は、グループが提案したデバイスファームウェアアップグレード（ＤＦＵ）機能をサポートできるＵＳＢデバイスを実現するために提案された要件および仕様を記載する。
【００１１】
提案されたＤＦＵ解決策についての欠点は、ＤＦＵ動作と通常のランタイムアクティビティとの両者を並行して実行することは、ＵＳＢデバイス内では可能ではないことである。提案された仕様書は、すべての通常のランタイムアクティビティがいずれのＤＦＵ（アップグレード）動作の持続時間中にも停止しなければならないとしている。したがって、この実現例は、ファームウェアアップグレードを行なうために、デバイスが、再列挙するか、またはその動作モードを変更することを必要とする。たとえば、提案された仕様書によると、ファームウェアアップグレード中は、プリンタはプリンタとして機能しないであろう。代わりに、プリンタは、ＤＦＵ動作中はファームウェアプログラマーとして動作するであろう。これは、ＤＦＵ提案書のもとでは、単一のエンドポイント（またはチャネル）のみがプログラミングホストとＵＳＢデバイスとの間でアクティブであるという事実に少なくとも部分的に起因している。通例、再列挙は、デバイスがＵＳＢバスから物理的に切断されることを必要とする。対照的に、以下で説明される技術は、ホストとＵＳＢデバイスとの間でいくつかのエンドポイントを用いて、たとえデバイスファームウェアがプログラムまたは更新されている間も通常のデバイス動作を維持する。
【００１２】
ＤＦＵ提案書に記載されているメモリプログラミングの種類は、「インサーキット」プログラミングと呼ばれる。メモリは、その回路から取出されなくてもよいが、デバイスは、プログラミング段階中には、その通常モードでは動作しない。インサーキットプログラミングは、インシステムプログラミング（ここで説明される技術の特徴）と対比され、ここでは、デバイスはプログラミングプロセス中も（少なくとも部分的に）その通常動作モードで動作し続ける。デバイスファームウェアをインシステムでプログラムすることについての別の重要な利点は、その動作中にデバイスと通信するために用いられるホストデバイスドライバは、ファームウェアがプログラムされている間アンインストールされなくてもよく、さらにはプログラミングプロセスが終了したときに再インストールされなくてもよいことである。デバイスドライバをアンインストールし、さらには再インストールしなくてもよいことによって、時間およびホストシステムリソースが節約される。
【００１３】
ＵＳＢデバイス内でファームウェアアップグレードを行なうことについての問題は、全く異なった様態でもアプローチされた。たとえば、サイプレス半導体（Ｃｙｐｒｅｓｓ　Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）は「ＥＺ−ＵＳＢ」と呼ばれる解決策を提供し、これは、ＵＳＢデバイス自体の中でのプログラムおよびデータ記憶のための内部マイクロプロセッサおよび内部ランダムアクセスメモリ（ＲＡＭ）を含む。他のＵＳＢデバイス内で用いられる不揮発性メモリではなく、デバイスファームウェアを記憶するために揮発性ＲＡＭを用いることによって、ＥＺ−ＵＳＢ製品は、いわゆる「ソフトソリューション」製品となる。通常の動作中、ＵＳＢホスト（たとえば、ＰＣ）は、デバイス内部のマイクロプロセッサへのプログラム命令のダウンロード、およびＵＳＢバスを介してのデバイス内部のＲＡＭへのデバイス「パーソナリティ」ファームウェアのダウンロードを開始し得る。ダウンロードが完了した後、ＥＺ−ＵＳＢデバイスは、ダウンロードされたパーソナリティファームウェアによって定義された、新しくカスタマイズされたデバイスとしてＰＣに再接続される。
【００１４】
この解決策は、デバイス動作中いつでもＵＳＢインターフェイスを介して新しいファームウェアをダウンロードする能力を実際に提供するが、この解決策にはいくつかの欠点がある。第１に、ある他の形の不揮発性メモリの代わりにＲＡＭ内にファームウェアが記憶されるため、動作中にデバイスへの電力が誤って切断されると、ファームウェアは損失する。ファームウェアの損失は、バスによって電力供給されるデバイスにおいてデバイスがＵＳＢインターフェイスから誤って切断されたときにも起こり得る。第２に、ファームウェアダウンロードがＰＣホストによって開始される度に、ＥＺ−ＵＳＢデバイスはまず、ダウンロードが完了したときにホストから切断されなければならず、次に、アップグレードされたデバイスがその新しい構成で用いられ得る前に、ホストによって再接続（または、いわゆる再列挙）されなければならない。この限界によって、ユーザがファームウェアアップグレード中にデバイスを用いることができなくなる。
【００１５】
【特許文献１】
米国特許出願第０９／８９６，７９０号明細書
【００１６】
【非特許文献１】
ユニバーサルシリアルバス仕様書、改訂版２．０、２０００年４月２７日
【００１７】
【非特許文献２】
「デバイスファームウェアアップグレードのためのユニバーサルシリアルバスデバイスクラス仕様書」、バージョン１．０、ＵＳＢ作成者フォーラム（ＵＳＢ−ＩＦ）、１９９９年５月１３日
【００１８】
【概要】
したがって、ＵＳＢデバイスのメモリ内に記憶されるファームウェアを迅速かつ容易に更新するための解決策が必要とされる。
【００１９】
これらの必要性に対処するために、出願人は、ＵＳＢインターフェイスを用いて不揮発性プログラマブル電気的消去可能なメモリをプログラムするための特定の方法および装置を発明した。１つの局面に従うと、ＵＳＢインターフェイスを用いての不揮発性プログラマブル電気的消去可能なデバイスメモリのインシステムプログラミングのための方法が提供され、この方法は、ＵＳＢバス上の、第１のハードウェア構成を備えた少なくとも１つのデバイスを列挙するステップと、カスタムプロトコルに従ってプログラミングコマンドおよびプログラムデータをカプセル化してＵＳＢパケットにするステップと、カプセル化されたプログラミングコマンドおよびプログラムデータを含むＵＳＢパケットをＵＳＢバスを介して少なくとも１つのデバイスに送信するステップと、少なくとも１つのデバイスでプログラミングコマンドおよびプログラムデータを受信したことに応答して、デバイスメモリの少なくとも一部をプログラムするステップとを含む。第１のハードウェア構成によって定義されるような少なくとも１つのデバイスの少なくとも部分的な機能は、デバイスメモリがプログラムされている間、維持される。
【００２０】
関連の局面に従うと、方法はさらに、少なくとも１つのデバイスで第１のプログラミングコマンドを受信したことに応答して、少なくとも１つのデバイスの第１のハードウェア構成を少なくとも部分的に変更するステップと、デバイスメモリの一部に記憶されたコードモジュールの複数の制御機能のうちの少なくとも１つをＲＡＭにロードするステップと、少なくとも１つのデバイスで受信されるプログラミングコマンドおよびプログラムデータを用いてＲＡＭからの少なくとも１つの制御機能を実行してデバイスメモリをプログラムするステップと、デバイスメモリがプログラムされた後、少なくとも１つのデバイスで第２のプログラミングコマンドを受信したことに応答して、デバイスのハードウェア構成を第１のハードウェア構成へと復元するステップとを含む。
【００２１】
別の関連の局面に従うと、コードモジュールは少なくとも、ＵＳＢバスを介して送信されるプログラミングコマンドの処理を管理するためのメインループ機能と、ＵＳＢパケットをＵＳＢバスを介して転送するためのパケット交換機能と、カスタムプロトコルに従ってプログラミングコマンドおよびプログラムデータをカプセル化してＵＳＢパケットにし、ＵＳＢパケットからプログラミングコマンドおよびプログラムデータを抽出するためのベンダーリクエスト機能と、デバイスメモリの少なくとも一部に記憶された情報を消去するための消去機能と、ベンダーリクエスト機能によってＵＳＢパケットから抽出されたプログラムデータをデバイスメモリの少なくとも一部に書込むための書込機能と、デバイスメモリの少なくとも一部に記憶されたプログラム情報を読出すための読出機能とを含む。
【００２２】
さらなる別の関連の局面に従うと、方法はさらに、第１のプログラミングコマンドを受信したことに応答して第１のハードウェア構成に関連する割込をディセーブルにするステップと、第１のハードウェア構成に関連した割込を処理するための割込ベクトルテーブルをＲＡＭにコピーするステップと、第１のハードウェア構成に関連した割込がＲＡＭから処理されることを可能にするステップとを含む。
【００２３】
さらなる別の関連の局面に従うと、方法はさらに、少なくとも１つのデバイスで第３のプログラミングコマンドを受信したことに応答して、プログラミングステップの前にデバイスメモリの少なくとも一部に記憶された情報を消去するステップを含む。デバイスメモリの少なくとも一部に記憶された情報を消去するステップは、第３のプログラミングコマンド内に含まれる情報から消去されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、デバイスメモリの一部に記憶された消去機能をＲＡＭにロードするステップと、ＲＡＭからの消去機能を実行してデバイスメモリの少なくとも一部に記憶された情報を消去するステップと、デバイスメモリの少なくとも一部に記憶された情報の消去の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む。
【００２４】
さらなる別の関連の局面に従うと、方法はさらに、少なくとも１つのデバイスで第４のプログラミングコマンドを受信したことに応答して、プログラミングステップの後にデバイスメモリの少なくとも一部に記憶された情報を読出すステップを含む。デバイスメモリの少なくとも一部に記憶された情報を読出すステップは、第４のプログラミングコマンド内に含まれる情報から読出されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、デバイスメモリの一部に記憶された読出機能をＲＡＭにロードするステップと、ＲＡＭからの読出機能を実行してデバイスメモリの少なくとも一部に記憶された情報を読出し、読出した情報をＵＳＢバスを介して送信するステップと、デバイスメモリの少なくとも一部に記憶された情報の読出および送信の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む。
【００２５】
さらなる別の関連の局面に従うと、方法はさらに、デバイスメモリの少なくとも一部から読出された情報を検証して情報が適切にデバイスメモリにプログラムされているかを判断するステップと、検証ステップで無効であると判断された情報をデバイスメモリの少なくとも一部へ再プログラムするステップとを含む。デバイスメモリの少なくとも一部をプログラムするステップは、プログラミングコマンド内に含まれる情報からプログラムされるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、ＲＡＭバッファの１つが一杯になり、プログラムデータが受信されなくなるまで、ＵＳＢバスを介してＲＡＭバッファへと送信されるプログラムデータを受信するステップと、デバイスメモリの一部に記憶されたプログラムデータ機能をＲＡＭにロードするステップと、ＲＡＭからのプログラムデータ機能を実行して受信したプログラムデータをデバイスメモリの少なくとも一部に記憶するステップと、ＲＡＭバッファが一杯であり、かつ追加のプログラムデータが依然としてデバイスメモリに記憶されるべきとき、プログラムデータを受信するステップとプログラムデータ機能を実行するステップとを繰返すステップと、デバイスメモリの少なくとも一部へのプログラムデータの記憶の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む。
【００２６】
さらなる別の関連の局面に従うと、方法はさらに、ＵＳＢバス上の、各々がそれぞれの第１のハードウェア構成を備えた多数のＵＳＢデバイスを列挙するステップと、ＵＳＢバス上で列挙されるデバイスの各々へとＵＳＢバスを介して送信されるプログラミングコマンドおよびプログラムデータのフローを制御してそれぞれのデバイスの各々の中に含まれるデバイスメモリの少なくとも一部の同時プログラミングを管理するステップとを含む。
【００２７】
さらなる別の関連の局面に従うと、複数のエンドポイントが用いられて、カスタムプロトコルに従ってカプセル化されてＵＳＢパケットになる情報をＵＳＢバスを介して交換し、エンドポイントは、カプセル化されたプログラミングコマンドを有するＵＳＢパケットを交換するための制御エンドポイントと、カプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスに送信するためのバルクＩＮチャネルとカプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するためのバルクＯＵＴチャネルとを有するバルクエンドポイントと、カプセル化されたステータス情報を有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するための割込ＩＮエンドポイントとを含む。
【００２８】
さらなる別の関連の局面に従うと、カスタムプロトコルに従ってカプセル化されてＵＳＢパケットになり、さらにはＵＳＢバスを介して交換される情報は、リクエストタイプフィールド、リクエスト識別子フィールド、リクエスト値フィールド、データフィールド、データ長フィールド、およびアドレス指標フィールドに記憶される情報を含む。
【００２９】
さらなる別の関連の局面に従うと、リクエストタイプフィールドに記憶される情報は、標準タイプリクエスト、クラスタイプリクエスト、およびベンダータイプリクエストのうちの１つである。リクエストタイプフィールドに記憶される情報がベンダータイプリクエストならば、リクエスト識別子フィールドに記憶される情報は、少なくとも消去リクエスト、デバイスメモリ書込リクエスト、デバイスメモリ読出リクエスト、ｃｈｅｃｋ＿ｉｄリクエスト、ｇｅｔ＿ｄｅｖｉｃｅ＿ｉｎｆｏリクエスト、ＲＡＭ読出リクエスト、ＲＡＭ書込リクエスト、およびジャンプツーファンクションリクエストのうちの１つを含む。
【００３０】
「含む」および「含んでいる」という表現は、この明細書および請求項において用いられるとき、述べられる特徴、ステップ、または構成要素の存在を特定していると解釈されるが、これらの表現を用いることによって、他の１つ以上の特徴、ステップ、構成要素、またはそれらのグループの存在または追加が排除されないことが強調されるべきである。
【００３１】
この発明の上述および他の目的、特徴、および利点は、同じ参照番号が同様または同一の要素を識別する図とともに以下の詳細な説明を参照することにより、より明らかとなるであろう。
【００３２】
［詳細な説明］
この発明の好ましい実施例が、添付の図を参照しながら以下で説明される。以下の説明では、不必要な詳細事項でこの発明を曖昧にしないために、周知の機能および／または構造は詳細に説明されない。さらに、用語「フラッシュ」メモリが詳細な説明全体を通して用いられ得るが、説明される技術は、ＵＳＢインターフェイスを介していずれの種類の不揮発性プログラマブル電気的消去可能なメモリをプログラムすることにも同様に好適であることが理解されるであろう。
【００３３】
好ましい実施例を詳細に説明する前に、ＵＳＢプロトコルに関連したいくつかの基本的な概念をまず定義することが役立つだろう。これらの概念は、以下の通りである。
【００３４】
・列挙（ｅｎｕｍｅｒａｔｉｏｎ）：デバイスが最初にホストＰＣに接続されたときに行なわれる検出および最初の通信である。概念上、列挙は、ＵＳＢデバイスとホストＰＣとの間での発見段階として動作し、この間、どのようにして最適に互いと通信するべきかが判断される。
【００３５】
・デバイスドライバ：ＰＣアプリケーションが外部デバイス（たとえば、ＵＳＢデバイス）と通信することを可能にするホストソフトウェアである。
【００３６】
・構成：ＵＳＢ仕様は、デバイスが多数の構成または「フェース」を有することに備える。これらの構成は、性質上動的であり、デバイスが動作的である間に選択可能である。
【００３７】
・ＮＡＫ／ＡＣＫ：パケット送信ステータスまたはＵＳＢインターフェイスを介して受信されるべき新しいパケットのための利用可能な帯域幅を決定するために用いられるフロー制御トークンである。
【００３８】
・ＤＭＡ：ダイレクトメモリアクセスコントローラである。これは、通例、デバイスの異なるメモリ領域間での迅速なデータ転送を可能にするマイクロコントローラブロックである。
【００３９】
・パケット：ＵＳＢインターフェイスを介してＰＣと目標デバイスとの間で送信されるデータの集合である。
【００４０】
・相対アドレス指定：絶対アドレス指定とは対照的に、相対アドレス指定は、通例（（場所）、オフセット）の形である、可変ポインタを用いて行なわれる指標付けを用いる。
【００４１】
・構造化アセンブラ：アセンブリコードを書込むときにプログラマーが「Ｃ」言語型構造体を用いることを可能にするマクロ言語である。
【００４２】
・ベンダーリクエスト：ユーザがエンドポイントゼロ（ＥＰ０）を介して制御データをデバイスに渡すことを可能にするＵＳＢ標準リクエストバージョンである。再フラッシュ動作中のホストＰＣとデバイスとの間の通信の大部分は、これらのリクエストを用いて起こる。他の種類のＵＳＢリクエストは、標準リクエストとクラスリクエストとの両方を含む。これらのさまざまな種類のリクエストのより詳細な説明については、ＵＳＢ仕様書を参照されたい。
【００４３】
図１は、ＵＳＢインターフェイスを用いてＵＳＢ互換のデバイスのファームウェアをプログラムするための好ましい技術のハイレベル概要を示すフローチャートである。技術は、ステップ１０１で開始し、デバイスは、既に列挙されており、その通常の動作を行なっているものとして示される（たとえば、デバイスは、プリンタ、カメラ、およびマイクロコントローラ等として動作している）。構成変更がステップ１０３で起こり、デバイスがファームウェア「再書込」モードに入らされる。構成変更は、ユーザ、デバイスドライバ、または他の方法による介入の結果として起こり得る。一旦構成が起こると、デバイスとホストＰＣとの間で転送されるデータおよびリクエストを適切に組立てる（フラッシュオーバーＵＳＢまたは「ＦＯＵＳＢ」プロトコルと呼ばれる）ＵＳＢベースのプロトコルを用いてデバイスは書込まれ、読出され得る。
【００４４】
情報のこの流れを管理するために、ステップ１０５で、デバイスは適切な制御プログラムをＲＡＭにロードする。次に、デバイス内のプログラム実行は、ＲＡＭ内の制御プログラムの場所へと「方向付け」され、制御が実行される。次にステップ１０７で、デバイスは、ＦＯＵＳＢプロトコルに従ってホストＰＣから受信されたコマンドを実行する。次に、ホストＰＣからのすべてのコマンドが実行されて所望のタスクが行なわれた後、デバイスは再びステップ１０９で変更構成コマンドを受信する。この第２の変更構成コマンドが用いられて、デバイスに制御プログラムの実行を停止するように指示し、プログラム実行をＲＯＭへと方向付けし直して通常のデバイス動作を再開する。
【００４５】
重要なことに、制御プログラムの実行中、デバイスは、たとえばプリンタ、カメラ、およびマイクロコントローラ等として依然として列挙されたままである。すべてのデバイス機能が制御プログラムの実行中に利用可能であり得るわけではないが、少なくとも基本的なデバイス機能セットが依然として動作したままにされ得る。さらに、ユーザ、デバイスドライバ、または他の方法による制御プログラムの実行中の介入は、ホストＰＣによって検出され得、必要であれば、制御プログラムの実行が停止されて所望のタスクを実行する。
【００４６】
好ましい実施例に従うと、以下の機能リストが、デバイスファームウェアのプログラミングおよび再プログラミングを行なうために少なくとも実現される。
【００４７】
・（デバイス仕様書内で通例定義されている）特定のブロックまたは全メモリブロックの消去と、
・好ましくは１バイトほど小さい単位での全メモリのプログラミングと、
・メモリ内容の読出、および検証のためにそのデータをホストＰＣに戻すことと、
・特に、ファームウェアへの望ましくないアクセスを阻止するための（再び、デバイス仕様書内で通例定義される）ソフトウェアセキュリティ機能と、
・迅速な分析またはデバック能力のための、ＲＡＭ領域の読出および書込のためのサポート機能とが実現される。
【００４８】
特定のユーザ要件に対処するための他の機能が、必要であれば追加されてもよい。これらの機能は、適切な機能のための実行コードをメモリ内におき、ＤＭＡを用いてこれらをＲＡＭに転送して実行することによって、追加され得る。
【００４９】
図２は、ここで説明されるＦＯＵＳＢ技術をサポートするために用いられ得るＲＡＭの例示的なメモリマップを示す。例示的なメモリマップは、再書込ＦＯＵＳＢプロセス中に用いられる変数を記憶するためのゼロページ領域２０１を含む。マップはさらに、フラッシュメモリをプログラムするために必要な機能を実行するＲＡＭメインループ２０３を含む。これらの機能は、以下でより詳細に説明される。メモリマップはさらに、ＵＳＢ機能割込サブルーチン（ＩＳＲ）２０５を含む。このサブルーチンは、ＦＯＵＳＢプロセス中に活動化される種々の割込を処理する。メモリマップはまた、ファームウェアプログラミングプロセスをサポートするために必要とされる種々の機能を行なうためのいくつかの実行コードモジュール２０７を含む。これらの機能のうちのいくつかが、以下でより詳細に説明される。
【００５０】
図２で示されるメモリマップからわかるように、ＦＯＵＳＢプロセスをサポートするためのメモリ使用によって、全ＲＡＭ領域のかなりの部分が必要とされ得る。しかし、ＲＡＭ／ＳＦＲメモリ等の追加のメモリ、チェックＩＤ、および（以下で説明される）入来データバッファ領域２０９を必要とするＦＯＵＳＢ機能の多くは任意であるため、メモリ使用量は減じられ得る。加えて、すべてのＵＳＢプロトコルリクエストが実現され、ＲＡＭに記憶されるというわけでなくてもよい。プログラミングプロセスの開始前に、デバイスは既に列挙されたため、標準ＵＳＢリクエストのうちのいくつかをサポートする追加のオーバーヘッドを加える必要はない。メモリマップの全レイアウトおよびここに含まれる機能の相対的なサイズは、単なる例示にすぎず、この発明の思想から逸脱することなく、マップ構造の変形例が作られ得ることが理解されるであろう。
【００５１】
ここで説明されるインシステムＦＯＵＳＢプログラミング技術に関連した重要な概念は、フラッシュメモリをプログラムする間にＲＡＭ記憶場所へと方向付けする（または実行を切換える）割込の使用である。例示的な実施例に従うと、割込ベクトル化機能をサポートするために、特別なモードレジスタビットが設定される。モードレジスタビットが設定されると、新しい割込ベクトルセットが、元のベクトルテーブルの「後ろ」にあるＲＡＭ領域にコピーおよび転送される。このＲＡＭ領域２１１は、図２で示されるメモリマップの底部に示される。
【００５２】
ＲＡＭ領域２１１は、好ましくは、ベクトルテーブルのコピーを保持するのに十分なほど大きくなるように設計される。ＲＡＭ領域２１１は、データが記憶されるミラーメモリ領域になるようにセットアップされ得る。活動時には、デバイスＲＯＭ内に記憶されるベクトルアドレスを用いるファームウェアではなく、この新しいＲＡＭ領域２１１が、ＲＡＭ内の他の場所（たとえば、適切な制御プログラムが記憶される場所）への新しい割込ポインタ場所の方向付けをサポートする活動中の方向付け領域となる。この様態でＲＡＭ領域２１１を用いることについての有利な点は、実行中にＲＡＭメインループ２０３が特定のＲＯＭ割込ビットをポーリングする必要がないことであり、したがって、ループがペンディングリクエストにより応答することが可能となる。
【００５３】
この発明の例示的な実施例による割込方向付けは、以下のように動作する。通常のデバイスの起動後、元のデバイス割込ベクトルがデバイスＲＯＭ内に置かれる。セットアップ前に生成される第２のテーブルも、ＲＯＭスペースに記憶される。この第２のテーブルは、ＲＡＭからの割込を処理することが望まれる度に、たとえば、特別なモードレジスタビットが設定される度に、一時的なＲＡＭスペース２０９にロードされる。このビットを設定することによって、ＵＳＢインターフェイスを介してプログラムされている間に、デバイス動作中にデバイスによってＲＡＭ領域２１１がアクセスおよび書込まれることが可能となる。一時的なＲＡＭスペース２０９にロードされる第２のテーブルは次に、ＲＡＭ領域２１１に書込まれ、用いられて、プログラミングプロセス中に開始される割込サービスルーチンのために他のＲＡＭ領域へと方向付けし得る。代替的には、特別なモードレジスタビットが設定されているとき、第２のテーブルは直接ＲＡＭ領域２１１に記憶され得る。
【００５４】
説明されるＦＯＵＳＢプロセスの別の重要な局面は、構成を変更するという概念を含む。上述のように、そうすることによって、ＵＳＢケーブルを抜かなくても、またはデバイスを再起動しなくても、その「フェース」（または動作）を流れの中ほどで変更する能力がデバイスに与えられる。デバイスの構成を変更することは、ＵＳＢプロトコル規格で実現される、予め定められた標準リクエストタイプセットの機能である。デバイスの構成を変更するために用いられるリクエストタイプは、“Ｓｅｔ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ”リクエストである。リクエストは、ＥＰ０制御エンドポイント４０１を介してＵＳＢパケットでホストＰＣからデバイスへと伝達される。変更構成コマンドのための標準的なリクエストタイプ定義が、図３に示される。
【００５５】
図３に示される変更構成コマンドのための標準的なリクエストタイプ定義は、すべてのＵＳＢ標準リクエスト、クラスリクエスト、またはベンダータイプリクエストによく見られる。定義はｂｍＲｅｑｕｅｓｔｔｙｐｅフィールド３０１を含み、これは、この場合、１６進値０ｘ００に設定され、リクエストタイプが標準的なＵＳＢリクエストであることを表わす。ｂＲｅｑｕｅｓｔフィールド３０３がさらに、特定のタイプのリクエストを定義する。この例では、特定のリクエストは、デバイスの構成を変更するために用いられる“Ｓｅｔ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ”リクエストである。ｗＶａｌｕｅフィールド３０５を用いて、転送されている特定のリクエストに関連したデバイスまたはホストＰＣが用いる値が記憶され得る。この例では、ｗＶａｌｕｅフィールド３０５は、構成値（Ｃｏｎｆｉｇ　Ｖａｌｕｅ）であって（たとえば、例としてプリンタからスキャナへのデバイス動作の変更を実行するために）デバイスがそれへと変更される構成値（Ｃｏｎｆｉｇ　Ｖａｌｕｅ）を記憶する。ｗＶａｌｕｅフィールド３０５に記憶される値は、転送されている特定のリクエストに応じて、ゼロでもあり得る。
【００５６】
リクエスト定義内の次のフィールドは、ｗＩｎｄｅｘフィールド３０７である。このフィールドを用いて、特定のリクエストを実行するときにデータが読出されるか、または書込まれるべき記憶場所を記憶する。したがって、ｗＩｎｄｅｘフィールド３０７は、転送される特定のリクエストに応じて、読出アドレスまたは書込アドレスのいずれかを記憶する。ｗＬｅｎｇｔｈフィールド３０９が、転送されるべきデータブロックの長さを定義する。この値は、示される例でのように、特定のリクエストに応じてゼロであってもよい。最終的に、リクエスト定義は、リクエストによって転送されているデータのタイプを定義するデータフィールド３１１を含む。このフィールドは、示される例でのように、特定のリクエストを実行するときにデータが交換されない場合には値「なし」を保持し得る。
【００５７】
ＵＳＢ周辺デバイスに関連した識別子テーブル内に変更構成リクエストのための定義を含むことが有利であり得る。これによって、列挙時にデバイスがリクエスト定義をホストＰＣに送信することが可能となる。リクエスト定義は、構成に含まれるべきエンドポイント識別子およびデバイス独自のインターフェイスを含み得る。ホストＰＣは、今後の参照のために列挙時にこれらのリクエスト定義を解釈およびログし得る。これによって、デバイス構成を変更するときにホストＰＣがエンドポイントサイズおよび機能を再び定義することが可能となる。エンドポイント定義および利用については、さらに詳細に説明される。
【００５８】
上述のように、ここで説明されるＦＯＵＳＢ技術を用いてのフラッシュメモリのプログラミングは、いくつかのエンドポイントの使用および／または再構成を採用する。好ましい実施例では、ホストＰＣとＵＳＢデバイスとの間で情報を転送するための３つのエンドポイントが定義される。エンドポイントは、ホストＰＣとＵＳＢ周辺デバイスとの間に存在し得る通信チャネルである。ＵＳＢ規格は、標準的なＵＳＢプロトコルを用いて通信するための５つのエンドポイントを定義する。
【００５９】
図４は、フラッシュプログラミングプロセスに関連した３つのエンドポイントを例示および定義する。第１のエンドポイント４０１は、上述のようなＥＰ０制御エンドポイント４０１である。このエンドポイントを用いて、制御情報（たとえば、変更構成リクエスト）をホストＰＣ４０７とＵＳＢデバイス（図示せず）との間で転送する。第２のエンドポイント４０３を用いて、オンボードフラッシュメモリをプログラムするためのデータが転送される。エンドポイントは、２つのサブエンドポイント、ＢＵＬＫ　ＩＮエンドポイント４０３ＡとＢＵＬＫ　ＯＵＴエンドポイント４０３Ｂとに論理的に分けられる。サブエンドポイントＢＵＬＫ　ＩＮ４０３ＡとＢＵＬＫ　ＯＵＴ４０３Ｂとを用いてそれぞれ、オンボードフラッシュメモリに記憶されたデータを検証のためにＵＳＢデバイスからホストＰＣ４０７へと送信し、データをプログラミングのためにホストＰＣからＵＳＢデバイスへと送信する。割込ＩＮ４０５と呼ばれる第３のエンドポイントを用いて、ＵＳＢデバイスからホストＰＣ４０７へとステータス情報が渡される。
【００６０】
Ｓｅｔ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎリクエストを用いてデバイスの構成が変更されると、ホストＰＣとＵＳＢデバイスとの間の前の転送モード（つまり、エンドポイント定義）が潜在的に変更される。前のインターフェイスに関連したいずれのデータ送信も完了させてから新しい構成のためのエンドポイント定義が確立されることが好まれる。たとえば、デバイスがプリンタとして構成され、Ｓｅｔ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎリクエストが受信されたときにページがプリントされている場合、データ損失を防ぐために、デバイスは、そのエンドポイントを再構成する前に、そのプリント動作を終了すべきである。データの安全保護は、（たとえば、ホストＰＣのそばの）ドライバ側とエンドポイントインターフェイスのデバイス側との両方の上で対処されるべきである。したがって、ＰＣドライバは、構成変更リクエストをデバイスに送信する前に、いずれのペンディングリクエストも終了させる責任があるべきであり、デバイスは、変更リクエストが受信されても、そのエンドポイントを再構成する前にいずれのデータ転送動作も終了させるべきである。デバイス内のエンドポイントサイズおよび構成レジスタへのシンプルな再書込が、通例、エンドポイントインターフェイスの再構成に必要とされるすべてである。
【００６１】
以下の段落では、ＦＯＵＳＢプロセス内に含まれる主な制御機能のうちのいくつかが詳細に説明される。これらの機能は、１）初期化、２）ファームウェア消去、３）ファームウェアプログラミング、４）ファームウェア検証、および５）再構成を含む。ＳＦＲ／ＲＡＭ領域の読出およびセキュリティチェックの実行等の他のサポート機能は、ＦＯＵＳＢプロセス内に含まれ得る。
【００６２】
しかし、主な制御機能を詳細に考察する前に、まずデバイス起動手順を考察することが役立つだろう。ここで説明されるプログラミング技術の重要な特徴は、プログラミングプロセス中、周辺デバイスがその主要な機能として、たとえば、プリンタまたはスキャナとしてＵＳＢコアを使い続けることであることを思い出されたい。したがって、ＵＳＢコアの電源が投入され、プログラミングプロセスを開始する前にデバイスがバス上で列挙されることが必要である。
【００６３】
典型的なデバイス起動シーケンスは、以下のステップを含み得る。
・デバイスリセット−デバイス内のすべての周辺ブロックがディセーブルにされる。
【００６４】
・初期起動−変数が初期化され、レジスタが設定され、他のいずれかの必要な起動手順が実行される。
【００６５】
・ＵＳＢコアのイネーブル−ホストＰＣとデバイスとの両方が安定化され得、エンドポイントが初期化される。
【００６６】
この時点では、割込がデバイス内でイネーブルされる。ＵＳＢケーブルがデバイス間で接続されると、列挙プロセスが始まる。列挙の間、デバイスは、ホストＰＣにその能力および必要とされる転送タイプを知らせる。また、デバイスドライバローディングがホストＰＣ内で起こり、ホストＰＣとデバイスとの間で必要とされるいずれかの初期通信がこの時点で行なわれる。この段階では、デバイスは、その「ベース構成」にあると言われるようなその通常動作を行ない、たとえば、デバイスはプリンタ、スキャナ等として動作する。
【００６７】
一旦そのベース構成内に入ると、デバイスファームウェアは、説明されるＦＯＵＳＢプログラミング手順に従ってＵＳＢインターフェイスを用いてプログラムされるか、またはインシステムで更新され得る。フラッシュメモリのインシステムプログラミングを実行するときの第１の段階は、初期化段階である。初期化において実行されるステップは、図５で示されるフローチャートで詳細に説明される。
【００６８】
初期化プロセスはステップ５０１で始まり、Ｓｅｔ＿ＣｏｎｆｉｇｕｒａｔｉｏｎリクエストがホストＰＣからデバイスへとエンドポイントゼロ４０１を介して送信され、デバイス内でのエンドポイント再構成を要求する。この時点では、現在のエンドポイントインターフェイス上で起こっているいずれのデータ転送も完了され、さらなるデータ転送は停止されて構成変更中の情報損失のおそれを防ぐ。次に、デバイスは、要求された構成変更を実行し、次に、適切なステータスビットを割込ＩＮエンドポイント４０５を介して設定して、ホストＰＣにモード変更がうまく行なわれたことを知らせる。リクエストを完了した後、デバイス内の割込が一時的にディセーブルされる。
【００６９】
次に、ステップ５０３で、デバイスは、ＤＭＡを用いて実行のために既存の機能をＲＯＭからＲＡＭへと転送する機能を実行する。これらの転送の完了時に、初期化プロセスはステップ５０５に進み、ＲＯＭベクトルテーブルのコピーが一時的なＲＡＭ領域２０９にコピーされる。次に、テーブルはＲＡＭ領域２１１にコピーされ、特別なモードレジスタビットが設定されてデータがＲＡＭ領域２１１に書込まれることが可能となり、再び、メモリを再フラッシュする間にデバイスからの割込が再び処理され得る。次に、ステップ５０７で、プログラム実行はＲＡＭメインループ２０３へとジャンプし、ここから、フラッシュメモリのプログラミングを行なうためのすべてのさらなるコード実行が行なわれる。初期化プロセスは、モードレジスタ内に含まれるＣＰＵ再書込ビットの設定とともにステップ５０９で終了する。この段階では、デバイスは、ホストＰＣからコマンドを受入れてそのオンボードメモリをプログラムまたは更新する準備ができている。
【００７０】
オンボードメモリのプログラミングが開始し得る前に、新しいデータでプログラムされるであろうファームウェアメモリのこれらの領域がまず消去されなければならない。例示的な消去動作が図６で示されるフローチャート内で詳細に説明される。プロセスはステップ６０１で始まり、消去コマンドがＥＰ０を介してベンダーリクエストによってデバイスに送信される。典型的には、ユーザまたはデバイスドライバのいずれかが、制御データパケットで渡される制御コードによってどのメモリブロックを消去すべきかを選択する。次に、ステップ６０３で、デバイスは、受信されたベンダーリクエストに基づいて消去されるべきファームウェアメモリ内のこれらのブロックを識別する。消去フラグがセットされ、制御権がＲＡＭメインループ２０３に渡される。ステップ６０５では、ＲＡＭメインループ２０３が、図２に示されるＲＡＭ消去機能２０７を呼出す。次に、ＲＡＭ消去制御機能２０７が、ステップ６０７で実行され、どのメモリブロックが消去されるべきかに基づいて、適切なコマンドを発行する。消去動作の完了後、ステップ６０９で、デバイスは、割込ＩＮエンドポイント４０５を介してホストＰＣにステータス情報を戻す。次に、ステップ６１３で、制御権がＲＡＭメインループ２０３に戻される。
【００７１】
一旦消去されると、オンボードメモリは、新しいファームウェアデータでプログラムされる準備ができている。プログラミング段階は、好ましくは、２つのステッププロセスとして実行され、データが、まずＲＡＭにダウンロードされ、次に適切なファームウェア記憶場所へプログラムされる。この２つのステップのプロセスをサポートするために、図２に示されるメモリマップは、好ましくは、デバイスオンボードメモリへの最終的な転送の前にプログラムデータが記憶されるバッファ領域２０９を含む。
【００７２】
オンボードメモリをプログラムするための例示的なプロセスが、図７のフローチャートで示される。プロセスはステップ７０１で始まり、プログラムコマンドがホストＰＣによって発行される。コマンドは、図３で示される構造と同様のリクエスト定義構造を有するベンダーリクエストでデバイスに伝達される。リクエストを搬送するＵＳＢデータパケットが、ＥＰ０を介してデバイスに送信され、プログラムデータが書込まれるべき開始アドレスと、オンボードメモリにプログラムされるべきデータの量を特定する情報との両方とともに組込まれる。次に、ステップ７０３で、制御権が、デバイス内のデータポインタをリセットするルーチンに渡され、次に、受信されるベンダーリクエストパケット内に含まれる開始アドレスおよびサイズ情報をポインタにロードする。次に、ステップ７０５で、制御権がＲＡＭメインループ２０３に戻され、この時点で、メインループは、データがＢＵＬＫ　ＯＵＴエンドポイント４０３Ｂ上で受信されるのを待つ。
【００７３】
プログラムデータがＢＵＬＫ　ＯＵＴエンドポイント４０３Ｂ上で受信されると、ステップ７０７で、制御権が別のルーチンに渡され、これが、受信されたＵＳＢパケットからデータを抽出する。プログラムデータは、好ましくは、バッファ領域２０９に一時的に記憶され、後にオンボードメモリへとプログラミングされる。ステップ７０９では、バッファ２０９が一杯になるまで、または転送されるべきデータがなくなるまで、データはバッファ２０９にロードされ続ける。
【００７４】
バッファ２０９は一杯ではあるが、さらなるデータが依然としてオンボードメモリにプログラムされるべき場合、ホストＰＣからのさらなるデータ送信は、割込ＩＮエンドポイント４０５を介してＮＡＫフロー制御トークンを送信することにより、デバイスによって一時的に拒否される。追加のプログラムデータを含んだ、受入れられないパケットは損失せず、ホストＰＣはパケットをデバイスに順番に再送信し続け、これは、割込ＩＮエンドポイント４０５を介して送信されるＡＣＫフロー制御トークンによって、デバイスが、成功したデータ受信を再び通知するまで行なわれる。バッファ２０９が一杯になったとき、またはデバイスに転送されるべきプログラムデータが存在しないとき、ステップ７１１において、データ抽出ルーチンは、プログラムフラグをセットして、データがオンボードメモリにプログラムされる準備ができていることを表わし、次に、制御権をＲＡＭメインループ２０３に戻す。
【００７５】
プログラムフラグがセットされたことに応答して、ステップ７１３において、ＲＡＭメインループ２０３は、オンボードメモリをプログラムするためのルーチンを呼出す。ステップ７１５で、プログラムルーチンは、デバイス仕様に従ってデータをオンボードメモリに書込む。書込まれるプログラムデータブロックのサイズおよび開始アドレスを保持するデータポインタが減分され、チェックが行なわれていつプログラミングプロセスが完了するかが判断される。バッファ領域２０９が空になると、プログラム動作は、ステップ７１７またはステップ７１９のいずれかにおいて停止する。ステップ７１９で、プログラムルーチンは、さらなるデータがオンボードメモリにプログラムされるために残っているかを判断する。さらなるデータが残っているならば、ステップ７０５で、制御権はＲＡＭメインループ２０３に戻され、ここで、ループは、さらなるデータがＢＵＬＫ　ＯＵＴエンドポイント４０３Ｂに到着するのを待つ。プロセスステップ７０７から７１１が再び実行されて、バッファが再び一杯になるか、またはプログラムされるべきデータがなくなるまで、ＢＵＬＫ　ＯＵＴエンドポイント４０３Ｂ上で受信されるプログラムデータをバッファ領域２０９に記憶する。上述のように、プログラミングはステップ７１３から７１９において行なわれる。すべてのデータがオンボードメモリにプログラムされると、プログラムルーチンは、割込ＩＮエンドポイント４０５を介してステータス情報をホストＰＣに送信する。
【００７６】
オンボードメモリに記憶されたプログラムデータを読出すための例示的な方法が図８で示される。プロセスはステップ８０１で始まり、デバイスは、ＥＰ０制御エンドポイント４０１を介して搬送されるＵＳＢパケット内の読出コマンドを受信する。再び、読出コマンドは、図３で示されるものと同様の構造を有するベンダーリクエストとして送信される。リクエストは、ｗＶａｌｕｅ値およびｗＬｅｎｇｔｈ値を含み、これらはそれぞれ、プログラムが読出されるべきデバイス内の開始アドレスと、読出されるべきデータブロックのサイズとを定義する。これらの値は、ＵＳＢパケットから抽出され、読出動作を行なうために用いられるデバイス内のポインタをロードするために用いられる。
【００７７】
ポインタがうまくロードされると、ステップ８０３で、読出フラグがセットされ、ＲＡＭメインループ２０３は、プログラムデータを読出すための適切なルーチンを呼出す。ステップ８０５で、読出ルーチンは、ＢＵＬＫ　ＩＮエンドポイント４０３ＡのためのＦＩＦＯレジスタに読出プログラムデータを置き、ホストＰＣに転送し返す。転送が完了すると、適切なステータス情報が割込ＩＮエンドポイント４０５を介してホストＰＣに送信される。次に、ステップ８０７で、制御権がＲＡＭメインループ２０３に戻される。
【００７８】
オンボードメモリにプログラムされたデータを検証するためのいくつかの方法が採用され得る。好ましい実施例に従うと、上述のように、プログラムされたデータがデバイスからホストＰＣへと読出された後、ホストＰＣは、読出されたデータをＰＣ上に記憶されたプログラムデータのイメージと比較する。デバイスではなくホストＰＣに検証を行なわせることによって、検証プロセスが高速化し、簡素化される。読出されたデータ内でエラーが検出された場合、エラーはホストＰＣによってトラップされ、オンボードメモリを再びプログラムしてデータエラーを訂正するなどの訂正動作が行われ得る。
【００７９】
プログラムされたデータが一旦検証されると、デバイスは、プログラミングモードから戻るように再構成され得、その完全な通常動作を再開する。どのようにデバイスがプログラミングモードから戻るのかは、どれほどのオンボードメモリがプログラムされたのかに応じ得る。オンボードメモリのわずかな部分しかプログラムされていない場合、プログラミングモードから戻ることは、他のいずれかの種類の機能呼出から戻ることと同じほど簡素である。関連のステップは、以下を含み得る。すなわち、
・Ｓｅｔ＿ＣｏｎｆｉｇｕｒａｔｉｏｎリクエストをＵＳＢパケットでデバイスに送信し、デバイスがその完全な通常動作に戻ることを要求するステップを含み、受信されたパケットは、パーズされるが、構成はＵＳＢコアに転送されず、代わりに、リクエストがステータスステージで保持され、ステップはさらに、
・一時的にデバイス内の割込をディセーブルにするステップと、
・エンドポイントをそれらの元の構成に戻すステップと、
・デバイス内のＣＰＵ再書込機能をディセーブルにし、オンボードメモリが再びデバイスによって読出されることを可能にするステップと、
・ＲＡＭ割込をディセーブルにし、割込方向付けをＲＡＭから元のベクトルテーブルに戻すステップと、
・制御権をメインプログラムループに戻すようにＲＡＭメインループ２０３に知らせるステップと、
・一旦メインプログラムループ内に入ると、Ｓｅｔ＿ＣｏｎｆｉｇｕｒａｔｉｏｎリクエストがＵＳＢコアに転送されることを可能にし、デバイスが完全な通常動作を再開することを可能にするステップとを含み得る。
【００８０】
プログラミングプロセスによって結果として、全オンボードメモリスペースが再プログラムされるならば、プログラミングモードから戻るときにデバイス内で問題が生じないことを確実にするために、特定の対策がとられるべきである。実行コードがもはや存在しないメモリ内の領域へと、または実行コードが正確ではない領域へとプログラム実行が戻る結果として、問題が起こるおそれがある。この問題に対処するためにいくつかのやり方が存在し、これらは、プログラミングプロセスが完了した後にデバイスをリセットすること、または、ことによると、決して変化しないメモリ内の固有の「立上げ」コード領域を保つことを含む。
【００８１】
ここで説明されるＦＯＵＳＢプログラミング技術は、１度にいくつかのＵＳＢデバイスの並行プログラミングを行うことができるＵＳＢの多デバイス連結性能力と組合せられてもよい。このような構成は、図９で示される。構成は、マルチＦＯＵＳＢプログラムを実行するホストＰＣ９０１を含む。このプログラムは、消去−プログラム−検証コマンドを、上述のようにプログラムされるべきデバイス９０７の各々に送信する。ホストＰＣ９０１は、ＵＳＢホスト９０３に接続されてＦＯＵＳＢコマンドをデバイス９０７に送り得るか、またはＵＳＢホスト機能がホストＰＣ９０１自体の中に含まれ得る。ＵＳＢホスト９０３は、ホストＰＣ９０１とデバイス９０７との間で共有される通信および帯域幅を管理する。シリアルプログラミングプロトコルを採用する従来のマルチプログラマーシステムは、非効率的なことには、プログラムされているデバイスがそれら自身でこれらのタスクを管理することを必要とする。ＵＳＢホスト９０３はさらにＵＳＢハブ９０５に接続され、これは、次に、専用のＵＳＢ接続をプログラムされるべきデバイス９０７の各々に提供する。
【００８２】
デバイス９０７がＵＳＢハブ９０５に接続されると、上述のように、それらは、自動的にホストＰＣ９０１と列挙通信を開始する。一旦新しいデバイス９０７がバス上で活動状態になると、デバイスドライバがホストＰＣ９０１内でロードされ、マルチＦＯＵＳＢプログラムには、新しいデバイスがそのＵＳＢバスに接続されたことが知らされる。次に、プログラムは、消去−プログラム−検証コマンドを新しく接続されたデバイスに送信する。好ましくは、各デバイス内のＵＳＢブートコードは同じである。これによって、ホストＰＣ９０１オペレーティングシステムが同じデバイスドライバに結合され、新しいデバイスが列挙プロセスを開始するたびに、ドライバの別の「インスタンス」を生成する。マルチＦＯＵＳＢプログラムは、「新しいドライバ」が接続されたことが知らされるが、同じデバイスドライバのインスタンスを区別する能力を有する。これによって、プログラムが異なるデバイス間で別々に別個の通信を維持することが可能となり、したがって、多数のデバイスが同じドライバを用いてプログラムされることが効率的に可能となる。
【００８３】
プログラムされている各デバイスは独立してホストＰＣ９０１と通信しているため、多数のチップが一度にプログラムされ得る。通信の性質の結果として、帯域幅はＵＳＢバス上で共有される。バスを介して新しいプログラムデータを受信するデバイスは、バスを介して追加の情報を要求する前に、まずこのデータをそれらのそれぞれのオンボードメモリにプログラムしなければならない。これらのプログラミング時間中、他のデバイスはＵＳＢバスにアクセスできる。ＵＳＢホスト９０３も、バスを介して情報を要求する接続されたデバイスの各々上の帯域幅を均等にタイムシェアすることができる。
【００８４】
上述のように、デバイス９０７はインシステムでプログラムされ得るか、または、別個の多デバイスプログラマー９０９が、デバイス９０７を同時にプログラムするタスクのために特別に設けられ得る。多デバイスプログラマー９０９は、好ましくは、プログラムされるべきデバイス９０７を保持するためのソケット９１１およびＵＳＢハブ９０５の機能を含む。ソケット９１１は、「クラムシェル」タイプであり得、好ましくは、コネクタカバーを閉じたとき、コネクタ内にあるデバイスが自動的にＵＳＢホスト９０３に対して列挙し始めるように、構成される。このような構成でのデバイス９０７は、「インサーキット」でプログラムされているため、デバイス９０７とホストＰＣ９０１との間でのさらなるハードウェアインタラクションは必要とされない。
【００８５】
上述の方法ステップは、好適なプロセッサが実行するソフトウェア、または特定用途向け集積回路（ＡＳＩＣ）等のハードウェアのいずれかによって、容易に実現され得ることが理解されるであろう。
【００８６】
この発明の種々の局面が、いくつかの例示的な実施例に関連して説明されてきた。この発明の理解を促すために、この発明の多くの局面が、コンピュータシステムの要素によって実行され得る動作シーケンスに関連して説明された。たとえば、各実施例において、種々の動作は、特化された回路（たとえば、特化された機能を実行するために相互接続された別個の論理ゲート）によって、１つ以上のプロセッサが実行しているプログラム命令によって、または両方の組合せによって、実行され得ることが理解されるであろう。
【００８７】
さらに、ここで説明される技術をプロセッサに実行させるであろう適切なコンピュータ命令セットを記憶したいずれかの形のコンピュータ読出可能な記憶媒体内に、この発明を全面的に組み入れることもさらに考慮され得る。したがって、この発明の種々の局面が、多くの異なる形で具体化され得、このようなすべての形がこの発明の範囲内にあると企図される。この発明の種々の局面の各々に関して、このような形の実施例のいずれも、説明された動作を「行なうように構成された論理」とここで呼ばれ得るか、または代わりに、説明された動作を「行なう論理」と呼ばれ得る。
【００８８】
出願人の発明の種々の実施例が説明されたが、これらの実施例は単なる例示にすぎず、他の多くの実施例が可能であることが当業者によって理解されるであろう。この発明の意図される範囲は、上の説明ではなく、前掲の請求項によって示され、請求項の範囲内に入るすべての変更例がここに包含されることが意図される。
【図面の簡単な説明】
【図１】ＵＳＢインターフェイスを用いてＵＳＢ互換デバイスのファームウェアをプログラムするための技術のハイレベル概要を示すフローチャートの図である。
【図２】ここで説明されるプログラミング技術をサポートするために用いられ得るＲＡＭの例示的なメモリマップを示す図である。
【図３】すべてのＵＳＢ標準リクエスト、クラスリクエスト、またはベンダータイプリクエストに特有であるとされる変更構成コマンドのための標準的なリクエストタイプ定義を示す図である。
【図４】ここで説明されるフラッシュプログラミング技術に関連した３つのエンドポイントを例示および定義する図である。
【図５】フラッシュメモリのインシステムプログラミングのための説明される技術に関連した初期化段階で実行されるステップを例示するフローチャートの図である。
【図６】説明されるプログラミング技術で用いられる例示的な消去動作を例示するフローチャートの図である。
【図７】オンボードメモリをプログラムするための例示的なプロセスを示したフローチャートの図である。
【図８】オンボードメモリに記憶されたプログラムデータを読出すための例示的な方法を示したフローチャートの図である。
【図９】いくつかのＵＳＢデバイスを一度に並行プログラミングすることに備えた構成を例示する図である。
【符号の説明】
９０１　ＦＯＵＳＢプログラム、９０３　ＵＳＢホスト、９０７　デバイス。

Claims

ＵＳＢインターフェイスを用いた不揮発性プログラマブル電気的消去可能なデバイスメモリのインシステムプログラミングのための方法であって、前記方法は、
ＵＳＢバス上の、第１のハードウェア構成を備えた少なくとも１つのデバイスを列挙するステップと、
カスタムプロトコルに従ってプログラミングコマンドおよびプログラムデータをカプセル化してＵＳＢパケットにするステップと、
カプセル化されたプログラミングコマンドおよびプログラムデータを含むＵＳＢパケットをＵＳＢバスを介して少なくとも１つのデバイスに送信するステップと、
少なくとも１つのデバイスでプログラミングコマンドおよびプログラムデータを受信したことに応答して、デバイスメモリの少なくとも一部をプログラムするステップとを含み、
第１のハードウェア構成によって定義されるような少なくとも１つのデバイスの少なくとも部分的な機能は、デバイスメモリがプログラムされている間、維持される、インシステムプログラミングのための方法。
少なくとも１つのデバイスで第１のプログラミングコマンドを受信したことに応答して、少なくとも１つのデバイスの第１のハードウェア構成を少なくとも部分的に変更するステップと、
デバイスメモリの一部に記憶されたコードモジュールの複数の制御機能のうちの少なくとも１つをＲＡＭにロードするステップと、
少なくとも１つのデバイスで受信されるプログラミングコマンドおよびプログラムデータを用いてＲＡＭからの少なくとも１つの制御機能を実行してデバイスメモリをプログラムするステップと、
デバイスメモリがプログラムされた後、少なくとも１つのデバイスで第２のプログラミングコマンドを受信することに応答して、デバイスのハードウェア構成を第１のハードウェア構成へと復元するステップとを含む、請求項１に記載の方法。
コードモジュールは少なくとも、
ＵＳＢバスを介して送信されるプログラミングコマンドの処理を管理するためのメインループ機能と、
ＵＳＢバスを介してＵＳＢパケットを転送するためのパケット交換機能と、
カスタムプロトコルに従って、プログラミングコマンドおよびプログラムデータをカプセル化してＵＳＢパケットにし、プログラミングコマンドおよびプログラムデータをＵＳＢパケットから抽出するためのベンダーリクエスト機能と、
デバイスメモリの少なくとも一部に記憶された情報を消去するための消去機能と、
ベンダーリクエスト機能によってＵＳＢパケットから抽出されたプログラムデータをデバイスメモリの少なくとも一部に書込むための書込機能と、
デバイスメモリの少なくとも一部に記憶されたプログラム情報を読出すための読出機能とを含む、請求項２に記載の方法。
第１のプログラミングコマンドを受信したことに応答して、第１のハードウェア構成に関連した割込をディセーブルにするステップと、
第１のハードウェア構成に関連した割込を処理するための割込ベクトルテーブルをＲＡＭにコピーするステップと、
第１のハードウェア構成に関連した割込がＲＡＭから処理されることを可能にするステップとをさらに含む、請求項２に記載の方法。
ダイレクトメモリアドレス指定を用いてデバイスメモリの一部に記憶された少なくとも１つの制御機能をＲＡＭにロードする、請求項２に記載の方法。
少なくとも１つのデバイスで第３のプログラミングコマンドを受信したことに応答して、プログラミングステップの前にデバイスメモリの少なくとも一部に記憶された情報を消去するステップをさらに含む、請求項１に記載の方法。
デバイスメモリの少なくとも一部に記憶された情報を消去するステップは、
第３のプログラミングコマンド内に含まれる情報から消去されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、
デバイスメモリの一部に記憶された消去機能をＲＡＭにロードするステップと、
ＲＡＭからの消去機能を実行してデバイスメモリの少なくとも一部に記憶された情報を消去するステップと、
デバイスメモリの少なくとも一部に記憶された情報の消去の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む、請求項６に記載の方法。
少なくとも１つのデバイスで第４のプログラミングコマンドを受信したことに応答してプログラミングステップの後にデバイスメモリの少なくとも一部に記憶された情報を読出すステップをさらに含む、請求項１に記載の方法。
デバイスメモリの少なくとも一部に記憶された情報を読出すステップは、
第４のプログラミングコマンド内に含まれる情報から読出されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、
デバイスメモリの一部に記憶された読出機能をＲＡＭにロードするステップと、
ＲＡＭからの読出機能を実行してデバイスメモリの少なくとも一部に記憶された情報を読出し、読出された情報をＵＳＢバスを介して送信するステップと、
デバイスメモリの少なくとも一部に記憶された情報の読出および送信の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む、請求項８に記載の方法。
デバイスメモリの少なくとも一部から読出された情報を検証して情報がデバイスメモリへと適切にプログラムされているかを判断するステップと、
検証ステップで無効であると判断された情報をデバイスメモリの少なくとも一部へ再プログラムするステップとをさらに含む、請求項８に記載の方法。
デバイスメモリの少なくとも一部をプログラムするステップは、
プログラミングコマンド内に含まれる情報からプログラムされるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断するステップと、
ＲＡＭバッファの１つが一杯になり、プログラムデータが受信されなくなるまで、ＵＳＢバスを介してＲＡＭバッファへと送信されるプログラムデータを受信するステップと、
デバイスメモリの一部に記憶されたプログラムデータ機能をＲＡＭにロードするステップと、
ＲＡＭからのプログラムデータ機能を実行して受信されたプログラムデータをデバイスメモリの少なくとも一部に記憶するステップと、
ＲＡＭバッファが一杯であり、追加のプログラムデータが依然としてデバイスメモリに記憶されるべきとき、プログラムデータを受信するステップとプログラムデータ機能を実行するステップとを繰返すステップと、
デバイスメモリの少なくとも一部に対するプログラムデータの記憶の完了時にＵＳＢバスを介してステータス情報を送信するステップとを含む、請求項１に記載の方法。
ＵＳＢバス上の、各々がそれぞれの第１のハードウェア構成を備えた多数のＵＳＢデバイスを列挙するステップと、
ＵＳＢバス上で列挙されるデバイスの各々へとＵＳＢバスを介して送信されるプログラミングコマンドおよびプログラムデータのフローを制御してそれぞれのデバイスの各々の中に含まれるデバイスメモリの少なくとも一部の同時プログラミングを管理するステップとをさらに含む、請求項１に記載の方法。
複数のエンドポイントを用いて、カスタムプロトコルに従ってカプセル化されてＵＳＢパケットになる情報をＵＳＢバスを介して交換し、エンドポイントは、
カプセル化されたプログラミングコマンドを有するＵＳＢパケットを交換するための制御エンドポイントと、
カプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスに送信するためのバルクＩＮチャネルと、カプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するためのバルクＯＵＴチャネルとを有するバルクエンドポイントと、
カプセル化されたステータス情報を有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するための割込ＩＮエンドポイントとを含む、請求項１に記載の方法。
カスタムプロトコルに従ってカプセル化されてＵＳＢパケットになり、ＵＳＢバスを介して交換される情報は、
リクエストタイプフィールドと、
リクエスト識別子フィールドと、
リクエスト値フィールドと、
データフィールドと、
データ長フィールドと、
アドレス指標フィールドとに記憶される情報を含む、請求項１に記載の方法。
リクエストタイプフィールドに記憶される情報は、標準タイプリクエスト、クラスタイプリクエスト、およびベンダータイプリクエストのうちの１つである、請求項１４に記載の方法。
リクエストタイプフィールドに記憶される情報がベンダータイプリクエストならば、リクエスト識別子フィールドに記憶される情報は、少なくとも消去リクエスト、デバイスメモリ書込リクエスト、デバイスメモリ読出リクエスト、ｃｈｅｃｋ＿ｉｄリクエスト、ｇｅｔ＿ｄｅｖｉｃｅ＿ｉｎｆｏリクエスト、ＲＡＭ読出リクエスト、ＲＡＭ書込リクエスト、およびジャンプツーファンクションリクエストのうちの１つを含む、請求項１５に記載の方法。
ＵＳＢインターフェイスを用いた不揮発性プログラマブル電気的消去可能なデバイスメモリのインシステムプログラミングのための構成であって、前記構成は、
ＵＳＢバスに結合されるホストと、
ＵＳＢバス上で列挙される、第１のハードウェア構成を備えた少なくとも１つのデバイスと、
プログラミングコマンドおよびプログラムデータを生成して少なくとも１つのデバイスのデバイスメモリの少なくとも一部のプログラミングを管理するホスト上で実行されるＦＯＵＳＢプログラムと、
ＦＯＵＳＢプログラムが生成するプログラミングコマンドおよびプログラムデータをカプセル化して、ホストによってＵＳＢバスを介して少なくとも１つのデバイスに送信されるＵＳＢパケットにするためのカスタムプロトコルと、
少なくとも１つのデバイスのメモリの一部に記憶されるコードモジュールとを含み、コードモジュールは複数の制御機能を有し、前記構成はさらに、
ＦＯＵＳＢプログラムが生成するプログラミングコマンドおよびプログラムデータに応答してデバイスメモリの少なくとも一部をプログラムする論理を含み、第１のハードウェア構成が定義するような少なくとも１つのデバイスの少なくとも部分的な機能は、デバイスメモリがプログラムされる間、維持される、インシステムプログラミングのための構成。
少なくとも１つのデバイスで第１のプログラミングコマンドを受信したことに応答して、少なくとも１つのデバイスの第１のハードウェア構成を少なくとも部分的に変更する論理ステップと、
デバイスメモリの一部に記憶された複数の制御機能のうちの少なくとも１つをＲＡＭにロードする論理ステップと、
少なくとも１つのデバイスで受信されるプログラミングコマンドおよびプログラムデータを用いてＲＡＭからの少なくとも１つの制御機能を実行してデバイスメモリをプログラムする論理ステップと、
デバイスメモリがプログラムされた後、少なくとも１つのデバイスで第２のプログラミングコマンドを受信したことに応答してデバイスのハードウェア構成を第１のハードウェア構成へと復元する論理ステップとをさらに含む、請求項１７に記載の構成。
コードモジュールは、少なくとも、
ＵＳＢバスを介して送信されるプログラミングコマンドの処理を管理するためのメインループ機能と、
ＵＳＢパケットをＵＳＢバスを介して転送するためのパケット交換機能と、
カスタムプロトコルに従って、プログラミングコマンドおよびプログラムデータをカプセル化してＵＳＢパケットにし、プログラミングコマンドおよびプログラムデータをＵＳＢパケットから抽出するためのベンダーリクエスト機能と、
デバイスメモリの少なくとも一部に記憶された情報を消去するための消去機能と、
ベンダーリクエスト機能によってＵＳＢパケットから抽出されたプログラムデータをデバイスメモリの少なくとも一部に書込むための書込機能と、
デバイスメモリの少なくとも一部に記憶されたプログラム情報を読出すための読出機能とを含む、請求項１８に記載の構成。
第１のプログラミングコマンドを受信したことに応答して第１のハードウェア構成に関連した割込をディセーブルにする論理と、
第１のハードウェア構成に関連した割込を処理するための割込ベクトルテーブルをＲＡＭにコピーする論理と、
第１のハードウェア構成に関連した割込がＲＡＭから処理されることを可能にする論理とをさらに含む、請求項１８に記載の構成。
デバイスメモリの一部に記憶された少なくとも１つの制御機能をＲＡＭにロードするダイレクトメモリアドレス指定をさらに含む、請求項１８に記載の構成。
少なくとも１つのデバイスで第３のプログラミングコマンドを受信したことに応答してプログラミングステップの前にデバイスメモリの少なくとも一部に記憶された情報を消去する論理をさらに含む、請求項１７に記載の構成。
デバイスメモリの少なくとも一部に記憶された情報を消去する論理は、
第３のプログラミングコマンド内に含まれる情報から消去されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断する論理と、
デバイスメモリの一部に記憶された消去機能をＲＡＭにロードする論理と、
ＲＡＭからの消去機能を実行してデバイスメモリの少なくとも一部に記憶された情報を消去する論理と、
デバイスメモリの少なくとも一部に記憶された情報の消去の完了時にＵＳＢバスを介してステータス情報を送信する論理とを含む、請求項２２に記載の構成。
少なくとも１つのデバイスで第４のプログラミングコマンドを受信したことに応答してプログラミングステップの後にデバイスメモリの少なくとも一部に記憶された情報を読出す論理をさらに含む、請求項１７に記載の構成。
デバイスメモリの少なくとも一部に記憶された情報を読出す論理は、
第４のプログラミングコマンド内に含まれる情報から読出されるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断する論理と、
デバイスメモリの一部に記憶された読出機能をＲＡＭにロードする論理と、
ＲＡＭからの読出機能を実行してデバイスメモリの少なくとも一部に記憶された情報を読出し、読出された情報をＵＳＢバスを介して送信する論理と、
デバイスメモリの少なくとも一部に記憶された情報の読出および送信の完了時にＵＳＢバスを介してステータス情報を送信する論理とを含む、請求項２４に記載の構成。
デバイスメモリの少なくとも一部から読出された情報を検証して情報が適切にデバイスメモリへプログラムされているかを判断する論理と、
検証ステップで無効であると判断された情報をデバイスメモリの少なくとも一部へ再プログラムする論理とをさらに含む、請求項２４に記載の構成。
デバイスメモリの少なくとも一部をプログラムする論理は、
プログラミングコマンド内に含まれる情報からプログラムされるべきデバイスメモリの少なくとも一部のサイズおよび場所を判断する論理と、
ＲＡＭバッファの１つが一杯になり、プログラムデータが受信されなくなるまで、ＵＳＢバスを介してＲＡＭバッファに送信されるプログラムデータを受信する論理と、
デバイスメモリの一部に記憶されたプログラムデータ機能をＲＡＭにロードする論理と、
ＲＡＭからのプログラムデータ機能を実行して受信されたプログラムデータをデバイスメモリの少なくとも一部に記憶する論理と、
ＲＡＭバッファが一杯であり、追加のプログラムデータが依然としてデバイスメモリに記憶されるべきとき、プログラムデータを受信するステップとプログラムデータ機能を実行するステップとを繰返す論理と、
デバイスメモリの少なくとも一部に対するプログラムデータの記憶の完了時にＵＳＢバスを介してステータス情報を送信する論理とを含む、請求項１７に記載の構成。
ＵＳＢバス上で列挙される、各々がそれぞれの第１のハードウェア構成を備えた複数のＵＳＢデバイスと、
ＵＳＢバス上で列挙されるデバイスの各々へとＵＳＢバスを介して送信されるプログラミングコマンドおよびプログラムデータのフローを制御してそれぞれのデバイスの各々の中に含まれるデバイスメモリの少なくとも一部の同時プログラミングを管理する論理とをさらに含む、請求項１７に記載の構成。
ＵＳＢバスを介して送信されるプログラミングコマンドおよびプログラムデータのフローを制御するホストに結合されたＵＳＢホストコントローラと、
第１のＵＳＢリンクによってＵＳＢホストコントローラに結合され、かつそれぞれのＵＳＢリンクによって複数のＵＳＢデバイスの各々に結合されるＵＳＢハブとをさらに含み、ＵＳＢリンクはＵＳＢバスを形成する、請求項２８に記載の構成。
ホストと少なくとも１つのデバイスとの間で結合される複数のエンドポイントをさらに含み、前記エンドポイントは、
カプセル化されたプログラミングコマンドを有するＵＳＢパケットを交換するための制御エンドポイントと、
カプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスに送信するためのバルクＩＮチャネルと、カプセル化されたプログラムデータを有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するためのバルクＯＵＴチャネルとを有するバルクエンドポイントと、
カプセル化されたステータス情報を有するＵＳＢパケットを少なくとも１つのデバイスからＵＳＢバスを介して送信するための割込ＩＮエンドポイントとを含む、請求項１７に記載の構成。
カスタムプロトコルに従ってカプセル化されてＵＳＢパケットになり、ＵＳＢバスを介して交換される情報は、
リクエストタイプフィールドと、
リクエスト識別子フィールドと、
リクエスト値フィールドと、
データフィールドと、
データ長フィールドと、
アドレス指標フィールドとに記憶される情報を含む、請求項１７に記載の構成。
リクエストタイプフィールドに記憶される情報は、標準タイプリクエスト、クラスタイプリクエスト、およびベンダータイプリクエストのうちの１つである、請求項３１に記載の構成。
リクエストタイプフィールドに記憶される情報がベンダータイプリクエストならば、リクエスト識別子フィールドに記憶される情報は、少なくとも消去リクエスト、デバイスメモリ書込リクエスト、デバイスメモリ読出リクエスト、ｃｈｅｃｋ＿ｉｄリクエスト、ｇｅｔ＿ｄｅｖｉｃｅ＿ｉｎｆｏリクエスト、ＲＡＭ読出リクエスト、ＲＡＭ書込リクエスト、およびジャンプツーファンクションリクエストのうちの１つを含む、請求項３２に記載の構成。