JP4666369B2 - Ｕｓｂデバイス - Google Patents

Description

本発明は、ＵＳＢホストから受信したコントロール転送のリクエストに対して自動応答を行うＵＳＢデバイスにかかわり、特にそのコントロール転送時に発生した転送エラーによる誤動作を防止したＵＳＢデバイスに関するものである。

まず、ＵＳＢについて簡単に説明する。ＵＳＢで転送されるデータは、トークンパケット、データパケット、ハンドシェークパケットで構成され、これら３つのパケットで構成される１回のデータ転送はトランザクションと呼ばれる。

トークンパケットには、トランザクションの種類を示すＰＩＤ（識別子）やデータ転送の相手方となるＵＳＢデバイスのアドレスおよびエンドポイントが格納されており、このトークンパケットの情報に適合したＵＳＢデバイスとＵＳＢホストとの間でデータ転送が可能になる。データパケットには転送データが格納されている。ハンドシェークパケットにはデータ転送が正常に完了したか否かを示す情報が格納されている。

トランザクションには、ＩＮトランザクション、ＯＵＴトランザクション、ＳＥＴＵＰトランザクションの３種類がある。ＩＮトランザクションではＵＳＢデバイスからＵＳＢホストへデータが転送される。ＯＵＴトランザクションではその反対にＵＳＢホストからＵＳＢデバイスへデータが転送される。ＳＥＴＵＰトランザクションはＵＳＢホストからＵＳＢデバイスに対して規格で規定されたコマンドの転送を行うとき使用される。これら３つのトランザクションで、バルク転送、コントロール転送、アイソクロナス転送、あるいはインタラプト転送と呼ばれる転送が構成される。

バルク転送は非周期的に大量データを扱う転送に用いられ、ＩＮトランザクション、またはＯＵＴトランザクションの繰り返しで行われる。コントロール転送はＵＳＢデバイスの制御などに必要な情報のやりとりについて使用される転送であり、セットアップトランザクション（セットアップステージ）で始まりＩＮトランザクション又はＯＵＴトランザクションからなるデータトランザクション（データステージ）が続き、ステータストランザクション（ステータスステージ）で終わる。ただし、データトランザクションは無い場合がある。アイソクロナス転送は連続的で周期的な通信に使用され、ハンドシェークパケットの無いＩＮトランザクションまたはＯＵＴトランザクションの並びである。インタラプト転送は周期的でバンド幅が低いデータ転送に使用される１つのＩＮトランザクションである。

これらの各種転送は、フレームと呼ばれる一定期間（フルスピードモードでは１ｍｓ、ハイスピードモードでは１２５μｓ）に並べられて、１フレーム単位で転送される。フレームの開始は、ＳＯＦ（Start of Frame）パケットと呼ばれる特殊なパケットで通知される。

図３にＵＳＢシステムの構成を示す。１個のＵＳＢホスト１（パーソナルコンピュータ）に複数のＵＳＢデバイスが接続される。例えば、３台のＵＳＢデバイス２Ａ，２Ｂ，２Ｃが接続された場合では、個々のＵＳＢデバイス２Ａ，２Ｂ，２ＣにはＵＳＢホスト１によりアドレス「１」，「２」，「３」が割り当てられる。そして、各ＵＳＢデバイス２Ａ，２Ｂ，２Ｃは、ＵＳＢホスト１から転送されたトークンパケットに含まれるアドレスを確認し、自己のＵＳＢデバイス宛に送信されたパケットか、他のＵＳＢデバイス宛に送信されたパケットかを判断する。

図４はこの処理の概要を示す図で、ＵＳＢホスト１からＵＳＢデバイス２Ａ→２Ｂ→２Ｃの順にトークンパケットが転送されている場合を示す。例えば、ＵＳＢデバイス２Ａでは、アドレス「１」のトークンパケットに対してはデータDATA_Aを返す。これに対して、ＵＳＢホスト１はハンドシェークパケットＡＣＫを返す。しかし、ＵＳＢデバイス２Ａは他のアドレス「２」，「３」のトークンパケットに対してはデータを返さず、送信されてきたトークンパケットを無視する。また、ＵＳＢデバイス２Ａは、他のＵＳＢデバイス２Ｂ，２ＣからのデータDATA_B、DATA_Cに対してＵＳＢホスト１が返したＡＣＫも無視する。

図５はＵＳＢデバイスへのアドレスの設定の説明図である。個々のＵＳＢデバイスのアドレスの初期値は「０」であり、接続後にコントロール転送のSet_Addressリクエストにより「０」以外のアドレス「１」〜「１２７」のうちの１つ値がセットされる。すなわち、セットアップステージにおいて、ＵＳＢデバイスはＵＳＢホストから送信されたＳＥＴＵＰトークンパケットと８バイトのデータパケットを受信すると、セットアップデータに含まれるアドレス（例えば「１」）を保持する。そして、ＡＣＫハンドシェークパケットをＵＳＢホストに返信する。ＵＳＢホストはＡＣＫハンドシェークパケットを受信すると、次に、ステータスステージにおいて、ＩＮトークンパケットを当該ＵＳＢデバイスに送信する。これを受信した当該ＵＳＢデバイスは、アドレス「１」の正常受信を知らせる長さ０バイトのデータパケットを送信する。これがＵＳＢホストで受信されると、そのＵＳＢホストからＡＣＫハンドシェークパケットがＵＳＢデバイスに返信されるので、これを受信した時点でＵＳＢデバイスはアドレス「１」をセットする。このようにして、ＵＳＢデバイスは、コントロール転送のステータスステージの完了を示すＡＣＫハンドシェークパケットを受信したタイミングでアドレス設定を行う。

図６はＵＳＢデバイス２の構成を示すブロック図である。ＵＳＢデバイス２はＵＳＢデバイスコントローラ２１、ＵＳＢ動作を制御するＭＰＵ２２、データ格納用のメモリ（ＲＡＭ）２３、そのメモリ２３を制御するメモリコントローラ２４、内部バス２５を具備する。

図７は図６に示したＵＳＢデバイスコントローラ２１の内部構成を示すブロック図である。ＵＳＢデバイスコントローラ２１は、パケットの入出力を制御するＵＳＢＰＨＹ２１１、入出力するパケットを制御するパケット制御回路２１２、データ保持用のエンドポイントバッファ２１３、ＤＭＡコントローラ２１４、制御レジスタ２１５を具備する。

ところで、ＵＳＢの規格では、転送エラーが発生した場合に、その後の通信が停止してしまわないようにエラー発生時のプロトコルが定義されている。コントロール転送のSet_Addressリクエストにおいて、ＵＳＢホストがＵＳＢデバイスからデータを受け取るＩＮ転送では図８〜１０の処理が行われる。

図８にケース１を示す。これは、ＵＳＢデバイスが、ＵＳＢホストから返信されるＩＮトークンパケットを正常に受信できなかった場合である。このときは、ＵＳＢデバイスから長さ０バイトのデータパケットの返信がないので、ＵＳＢホストは再度ＩＮトークンパケットをＵＳＢデバイスに対して送信（リトライ）して、ＵＳＢデバイスからの長さ０バイトデータの返信を要求する。この２回目のＩＮトークンパケットを受信したＵＳＢデバイスが長さ０バイトのデータパケットを返信し、このデータパケットを受信したＵＳＢホストがＡＣＫハンドシェークパケットを送信し、これがＵＳＢデバイスで受信されると、その受信のタイミングでＵＳＢデバイス内のアドレスセットが行われる。

図９にケース２を示す。これは、ＵＳＢホストが、ＵＳＢデバイスから返信される０バイトのデータパケットを正常に受信できなかった場合である。データパケットを受信できないため、ＵＳＢホストからＡＣＫハンドシェークパケットが返信されない。そして、ＵＳＢホストは、再度ＩＮトークンパケットをＵＳＢデバイスに対して送信（リトライ）する。ＵＳＢデバイスはこれに応じて同じ０バイトのデータパケットを送信する。この後は、ケース１と同様に、２回目のＩＮトークンパケットを受信したＵＳＢデバイスが長さ０バイトのデータパケットを返信し、このデータパケットを受信したＵＳＢホストがＡＣＫハンドシェークパケットを送信し、これがＵＳＢデバイスで受信されると、その受信のタイミングでＵＳＢデバイス内のアドレスセットが行われる。

ＩＮトークンパケットを用いるコントロール転送のステータスステージで、上記ケース１，２のような転送エラーが発生した場合には、ＵＳＢホストからＩＮトークンパケットを再送信（リトライ）することによってＵＳＢデバイスのアドレスセットが正しく行われ、その後の通信が停止することはない。

ところが、図１０に示すケース３の転送エラーが発生した場合は、ＵＳＢデバイスにアドレスが正しくセットされず、誤動作を起こす。すなわち、図１０のケース３はステータスステージにおいて、ＵＳＢデバイスが、ＵＳＢホストから返信されたＡＣＫハンドシェークパケットを正常に受信できなかった場合である。このとき、ＵＳＢホストは、ＵＳＢデバイスから０バイトのデータパケットを受信済みであるため、ＵＳＢデバイス側でのアドレスセットが正常に行われたと判断して、ＡＣＫハンドシェークパケットを返信し、コントロール転送のステータスステージを終了する。そして、次のセットアップステージにおいては、セット済みのアドレス（図１０においては「１」）を指定したＳＥＴＵＰトークンパケットを送信する。

しかし、ＵＳＢデバイス側では、まだＵＳＢホストからのＡＣＫハンドシェークパケットを受信できていないので、アドレスのセットが行われておらず、アドレスは初期値「０」のままである。このため、ＳＥＴＵＰトークンパケットのアドレス不一致により応答できなくなり、誤動作を起こす。

以上から、接続を再度確立するためには、ＵＳＢホストのファームウエアで再リクエストを行う処理を予め用意しておくか、これが無い場合は人手によるＵＳＢケーブルの抜き差しが必要になってくる。

本発明の目的は、ＵＳＢホストからのコントロール転送時のステータスステージで転送エラーが発生した場合にも、誤動作が発生しないか、もしくは少なくとも、誤動作発生が抑制されたＵＳＢデバイスを提供することである。

上記課題を解決するために、請求項１にかかる発明は、ＵＳＢホストから受信したコントロール転送のリクエストに対して自動応答を行うＵＳＢデバイスであって、前記リクエストの内容により特定されるタイミングで前記リクエストにより要求された設定を行うようにした。
請求項２にかかる発明は、前記リクエストの内容が、前記設定を行った後に前記ＵＳＢホストからＩＮ転送要求のリトライを受信したときに該リトライに対して自動応答を行うことが可能なリクエストである場合に、該リクエストに対して前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが送信する、ＡＣＫ信号の受信を待つことなく設定を行うようにした。
請求項３にかかる発明は、請求項２にかかる発明において、前記リクエストの内容が、前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが送信するＡＣＫ信号の受信を待つことなく設定を行うと、前記ＵＳＢホストからＩＮ転送要求のリトライを受け取ったときに該リトライに対して自動応答を行うことが不可能である場合に、前記ＡＣＫ信号の受信を待ってから前記設定を行うようにした。
請求項４にかかる発明は、請求項１乃至３のいずれかにかかる発明において、前記リクエストに対して前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが前記ＵＳＢデバイスに対してＡＣＫ信号に続いて送信する、次のパケットが特定できる場合に、該特定された次のパケットの受信を待ってから前記設定を行うようにした。
請求項５にかかる発明は、請求項４にかかる発明において、前記コントロール転送のセットアップステージにおいて前記ＵＳＢホストから受信したデータを記憶するセットアップバッファを有するとともに、前記リクエストに対する応答を送信した後に前記ＵＳＢホストから受信したデータを前記セットアップデータバッファに記憶したデータと比較して、前記特定された次のパケットの受信を識別するパケット識別回路を有するようにした。
請求項６にかかる発明は、請求項１、２、３、４又は５にかかる発明において、前記リクエストをデコードし、該リクエストの内容を判断するリクエストデコーダ回路を有するようにした。

本発明のＵＳＢデバイスによれば、ＵＳＢホストから受信したコントロール転送のリクエストの内容により特定されるタイミングでそのリクエストにより要求された設定を行うので、転送エラーが発生しても、誤動作を防止することができる。

全てのＵＳＢデバイスで標準対応が必要で、且つ、Set_Addressリクエストと同じ方式のコントロール転送を使用するリクエストは、他に何種類かある。例えば、Set_Feature、Clear_Feature、Set_Configuration、Set_Interface等である。本発明では、このような各種のコントロール転送のリクエスト内容に応じて特定のタイミングでリクエストにより要求された内容の設定を行い、転送エラーが発生しても誤動作を起こさないようにする。

図１は本発明の１つの実施例のＵＳＢデバイスのデバイスコントローラ２１の構成を示すブロック図である。図示の構成要素の内、セットアップデータバッファ２１６１、リクエストデコード回路２１６２、パケット識別回路２１６３、設定条件生成回路２１６４からなる設定回路２１６が、本実施例のデバイスコントローラ２１において新たに追加したものである。その他は、図７で説明した従来のＵＳＢデバイスコントローラ２１に含まれていた要素である。

図１に示したＵＳＢデバイスコントローラ２１をもつＵＳＢデバイスにおいては、パケット制御回路２１２によって受信されたリクエストに含まれるアドレスデータ等の設定データがセットアップデータバッファ２１６１に記憶される。また、受信されたリクエストは、リクエストデコード回路２１６２に送られ、そのリクエスト内容（種別）が判断される。さらに、パケット識別回路２１６３は、受信したパケットを識別する。そして、リクエストデコード回路２１６２によるデコード結果およびパケット識別回路２１６３によるパケット識別結果に基づいて、設定条件生成回路２１６４が設定タイミングを設定する。この設定結果に基づいた適切なタイミングで、パケット制御回路２１２が受信したパケットに含まれる設定データが制御レジスタ２１５に記憶され、設定が行われる。

本実施例のＵＳＢデバイスでのステータスステップの処理のフローを図２に示す。本実施例では、ステータスステージの転送フローの３箇所に、リクエスト内容により選定される設定(1)〜(3)のステップＳ３，Ｓ５，Ｓ８を設けている。この設定(1)〜(3)の選定はＵＳＢデバイスコントローラ２１のリクエストデコード回路２１６２とパケット識別回路２１６３で行う。ただし、リクエストをＵＳＢデバイスコントローラ２１の外部でその都度判断してレジスタ２１５に書き込むことで切り替えてもよい。

図２において、ステップＳ１はステータスステージで最初にＵＳＢホストから転送されるＩＮトークンパケットの受信の有無を判断する。ステップＳ２では該ＩＮトークンパケットを受信すると対応するデータをＵＳＢホストに対して送信する。ステップＳ４は該対応するデータを受信したＵＳＢホストからのＡＣＫハンドシェークパケットの受信の有無を判断する。ステップＳ６はリトライによりＵＳＢホストから再転送されるＩＮトークンパケットの受信の有無を判断する。ステップＳ７は、ステップＳ２でデータを送信した後に、このデータを受信したＵＳＢホストがＡＣＫハンドシェークパケットに続いて送信する次のパケットの受信の有無を判断する。例えば、ステータスステージに先立つセットアップステージがSet_Addressリクエストであった場合は、セットアップステージで受信されたアドレスデータをセットアップデータバッファ２１６１に保存しておく。そして、ステップＳ７において、ＵＳＢホスト１がそのアドレスヘ次のパケットを送信してきたか否かを判断する。

図２において、ステップＳ３の設定(1)は、設定を行った後に転送エラーが発生した場合でもそのリトライ動作に影響しない（つまり、リトライに対してファームウエアもしくは人手による対応を必要とせず、自動応答を行うことが可能な）リクエストの内容に応じた設定を行う。例えば、Set_ConfigurationリクエストでConfiguration Valueを設定する場合は、設定後にステータスステージのＩＮトークンパケット転送のリトライが発生してもそのリトライ動作に影響しないので、この設定(1)で設定する。これに対して、例えば、Set_FeatureリクエストでTEST_MODEを設定する場合は、設定(1)で設定してしまうとＵＳＢデバイスが別のモードに移行するため、ＩＮトークンパケット転送のリトライが行われてもそれに応答できない。また、Set_Addressリクエストでデバイスアドレスを設定する場合は、設定(1)でアドレスを設定してしまうと、アドレス不一致によりＩＮトークンパケット転送のリトライに応答できない。このようなリクエストの場合には、設定(1)での設定は行われない。

この設定(1)では、リクエストデコード回路２１６２でデコードされたリクエストが当該ステップＳ３の設定(1)で行うべき内容である場合に、ステップＳ１で受信したＩＮトークンパケットをパケット識別回路２１６３で識別した直後に、設定(1)のタイミングを設定条件生成回路２１６４で生成して、その設定を制御レジスタ２１５に対して行う。なお、この設定(1)はステップＳ２のデータ送信と同時又はそれより前であっても良い。

ステップＳ５における設定(2)は、設定(1)で設定を行ってしまうと、転送エラーによるステータスステージのＩＮトークンパケット転送のリトライが発生した場合に、リトライ動作に影響を与えるリクエストである場合に行う。

この設定(2)では、リクエストデコード回路２１６２でデコードされたリクエストが当該ステップＳ３の設定(1)で行うべきではない内容である場合に、ステップＳ４で受信したＡＣＫハンドシェークパケットをパケット識別回路２１６３で識別した直後に、設定(2)のタイミングを設定条件生成回路２１６４で生成して、その設定を制御レジスタ２１５に対して行う。このように設定(2)では、ステップＳ４でＡＣＫハンドシェークパケットの受信があるとき行うので、Set_Addressのリクエストに対して、前記した図５、図８、図９で説明した設定が可能である。しかし、図１０で説明した転送エラーには対応できない。

ステップＳ８における設定(3)は、設定(1)で設定を行ってしまうと、転送エラーによりＩＮトークンパケット転送のリトライが発生した場合にリトライ動作に影響を与えるリクエストであって、且つ、続くパケットが確定（想定）可能なリクエストの場合に実行される。つまり、ＵＳＢの接続手順で次に実行されるリクエストが決まっていることが条件である。例えば、Set_AddressリクエストでＵＳＢデバイスのアドレス設定が行われた場合、次には、Get_Descriptiorリクエストが実行されることが決まっている。

この設定(3)は、まずリクエストデコード回路２１６２でデコードされたリクエストが当該ステップＳ７の設定(3)で行うべき内容であることが条件である。そして、ＡＣＫハンドシェークパケットが受信できず（ステップＳ４）、リトライのＩＮトークンパケットも受信できなかった（ステップＳ６）場合に、受信したパケットが特定の次のパケットであることをパケット識別回路２１６３で識別した（ステップＳ７）直後に、設定(3)のタイミングを設定条件生成回路２１６４で生成して、その設定を制御レジスタ２１５に対して行う。

この設定(3)は、例えば、Set_Addressのリクエストの場合は、具体的には以下のように行われる。まず、リクエストに含まれるセットアップステージのアドレスデータが、セットアップデータバッファ２１６１に記憶される。また、受信されたSet_Addressのリクエストは、リクエストデコード回路２１６２に送られ、その内容が判断される。その後、ステップＳ７において受信したパケットがパケット識別回路２１６３で識別されるとともに、該受信したパケットに含まれるアドレスとセットアップデータバッファ２１６１に記憶したアドレスとが比較される。そして、両アドレスが一致するときに該受信したパケットが特定の次のパケットであることが識別される。そして、リクエストデコード回路２１６２による判断結果がSet_Addressのリクエストであること、およびパケット識別回路２１６３による識別結果がステップＳ７の次パケットであることに基づいて、設定条件生成回路２１６４が設定(3)のタイミングを生成する。このタイミングでセットアップデータバッファ２１６１に記憶されたアドレスデータが制御レジスタ２１５に記憶され、アドレス設定が行われる。この設定(3)により、では前記図１０で説明した転送エラーが発生しても、次のセットアップステージのＳＥＴＵＰトークンパケットの受信によりそのアドレス設定を行うことができる。従って、誤動作発生を防止できる。

本実施例においては、設定(1)、(2)、(3)の３つの設定タイミングを設け、リクエストの内容に応じて、このいずれかのタイミングにおいて設定を行った。これにより、全ての場合に誤動作の発生を防止できるわけではないが、いずれか１つの設定タイミングしか設けなかった場合に比較すると、はるかに誤動作発生の頻度を低減することができる。ただし、これらの３つの設定タイミングの全てを設けることは必ずしも必須ではない。何れか２つの設定タイミングを設け、リクエストの内容に応じていずれかのタイミングにおいて設定を行うことによっても、いずれか１つの設定タイミングしか設けなかった場合に比較すると誤動作発生の頻度を低減することができる。

例えば、設定(1)のタイミングを設けず、設定(2)、(3)の設定タイミングのみを設けることによっても、図１０に示した転送エラーには対応できる。すなわち、Set_Addressリクエストに対する設定を行うためには、設定(1)のタイミングは不要である。この場合、上記の実施例においては設定(1)において設定したSet_ConfigurationリクエストでのConfiguration Value設定も、設定(2)において行う。

本発明の実施例のＵＳＢデバイスのＵＳＢデバイスコントローラの構成のブロック図である。 本発明の実施例のＵＳＢデバイスのステータスステージの処理のフローチャートである。 従来のＵＳＢシステムの構成のブロック図である。 図３のＵＳＢデバイスへのデータ転送のタイミングチャートである。 ＵＳＢデバイスへのアドレス設定のタイミングチャートである。 従来のＵＳＢホストとＵＳＢデバイスの概略構成の説明用のブロック図である。 従来のＵＳＢデバイスコントローラの構成のブロック図である。 ＵＳＢデバイスへのアドレス設定の転送エラーがある場合のケース１のタイミングチャートである。 ＵＳＢデバイスへのアドレス設定の転送エラーがある場合のケース２のタイミングチャートである。 ＵＳＢデバイスへのアドレス設定の転送エラーがある場合のケース３のタイミングチャートである。

符号の説明

１：ＵＳＢホスト
２，２Ａ，２Ｂ，２Ｃ：ＵＳＢデバイス
２１：ＵＳＢデバイスコントローラ、２１１：ＵＳＢＰＨＹ、２１２：パケット制御回路、２１３：エンドポイントバッファ、２１４：ＤＭＡコントローラ、２１５：制御レジスタ、２１６：設定回路
２１６１：セットアップデータバッファ、２１６２：リクエストデコード回路、２１６３：パケット識別回路、２１６４：設定条件生成回路

Claims (6)

1. ＵＳＢホストから受信したコントロール転送のリクエストに対して自動応答を行うＵＳＢデバイスであって、前記リクエストの内容により特定されるタイミングで前記リクエストにより要求された設定を行うことを特徴とするＵＳＢデバイス。
2. 前記リクエストの内容が、前記設定を行った後に前記ＵＳＢホストからＩＮ転送要求のリトライを受信したときに該リトライに対して自動応答を行うことが可能なリクエストである場合に、該リクエストに対して前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが送信する、ＡＣＫ信号の受信を待つことなく設定を行うことを特徴とする請求項１記載のＵＳＢデバイス。
3. 前記リクエストの内容が、前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが送信するＡＣＫ信号の受信を待つことなく設定を行うと、前記ＵＳＢホストからＩＮ転送要求のリトライを受け取ったときに該リトライに対して自動応答を行うことが不可能である場合に、前記ＡＣＫ信号の受信を待ってから前記設定を行うことを特徴とする請求項２に記載のＵＳＢデバイス。
4. 前記リクエストの内容が、前記リクエストに対して前記ＵＳＢデバイスが送信する応答を受信した前記ＵＳＢホストが前記ＵＳＢデバイスに対してＡＣＫ信号に続いて送信する、次のパケットが特定できる場合に、該特定された次のパケットの受信を待ってから前記設定を行うことを特徴とする請求項１乃至３のいずれかに記載のＵＳＢデバイス。
5. 前記コントロール転送のセットアップステージにおいて前記ＵＳＢホストから受信したデータを記憶するセットアップバッファを有するとともに、前記リクエストに対する応答を送信した後に前記ＵＳＢホストから受信したデータを前記セットアップデータバッファに記憶したデータと比較して、前記特定された次のパケットの受信を識別するパケット識別回路を有することを特徴とする請求項４記載のＵＳＢデバイス。
6. 前記リクエストをデコードし、該リクエストの内容を判断するリクエストデコーダ回路を有することを特徴とする請求項１、２、３、４又は５に記載のＵＳＢデバイス。

Images