スキップしてメイン コンテンツへ

 none
USBD_STATUS_NOT_ACCESSEDについて RRS feed

  • 質問

  • 既存のUSB2.0(High Speed)機器を、試しにUSB3.0 PCI-ExpressボードおよびExpress Card(いずれもNEC uPD720200が使用されている)に接続したところ、

    エンドポイント2(Bulk-IN)に対する読み込み時にUSBD_STATUS_NOT_ACCESSEDが返って来て、

    通信できなくなることがありました。

    OSはWindows7 Pro 32bitです。

    下記のような通信を行っています。

    (1) 初回の転送前にRESET_PIPEを実行

    (2) 高速に転送を行うため複数のURBが完了を待たずにMicrosoft Windos USBドライバースタックへ送られる。完了したら完了した数だけURBを送る。

     下記の不具合に該当する状況です。

    http://support.microsoft.com/kb/969238/en-us

    1回の転送サイズは最大512KBで、送信されるパケットにはデータの区切りを表すため、ショートパケットが含まれます。

    (3) 停止する際は既に送ったURBをキャンセルするためABORT_PIPEを呼び出す

    接続直後は動作しているのですが、

    一旦停止するため(3)を行い、

    再度転送を開始すると、

    (2)のところでUSBD_STATUS_NOT_ACCESSEDやUSBD_STATUS_ENDPOINT_HALTEDが返って来て

    通信できなくなります。

    1度発生するとRESET_PIPEを実行しても復帰しません。

    デバイスマネージャーでデバイスを一旦無効にし再度有効に切り替えると

    復帰します。

    また、1回の転送サイズを512KBから256KBに減らしたところ、

    かなり頻度が下がりました(数回に1回から数百回に1回)。

    USB2.0の場合は下記のページに最大転送サイズに関する記述があるのですが、

    USB3.0の場合、情報が見つかりませんでした。

    http://support.microsoft.com/kb/832430/en-us

    USB2.0ポートに接続してしようする限りはこのような不具合は発生しませんでした。

    USBD_STATUS_NOT_ACCESSEDも今まで見たことがなかったのですが、

    USBD_STATUS_NOT_ACCESSEDはどのようなときに取得されるものなのでしょうか?

    どのような対策が有効でしょうか?

    よろしくお願いいたします。

     

    • 移動 Mike Wang (MSCS) 2012年10月2日 12:58 (移動元:Windows デバイスドライバー開発)
    2010年11月18日 5:41

回答

  • メーカーさん、パーマン2号さん、こんにちは。

    UPD720200 のブロック図を見ますと、ホストコントローラー内部に USB2.0 用と USB3.0 用の Root hub をそれぞれ搭載しているようです。このため、USB2.0 対応デバイス接続時には、USB2.0 Root hub が使用されると思います。また、UPD720200 は、Intel XHCI 準拠ですので、今回の問題がハードウェアに起因している可能性があれば、下記 XHCI Spec も併せて確認された方がよいと思います (これまでの経緯からおそらくソフト側の原因とは思いますが)。

    UPD720200 Product Brief
    http://www2.renesas.com/usb/ja/product/upd720200_doc.html

    Extensible Host Controller Interface (xHCI) Specification for USB 3.0
    http://www.intel.com/technology/usb/xhcispec.htm

    ちなみに HM57 は、2 つの USB EHCI ホストコントローラーを搭載 (UHCI, OHCI は搭載されていません) しており、また、各ホストコントローラーに Rate Matching Hub が搭載されています。下記データシートの 5.19 の項を見ますと、こちらの Hub が Low, Full, High Speed の変換を行うようです。RMH サポートの USB ホストコントローラーの場合、デバイスマネージャー上 (表示タイプを接続順) では、EHCI - Root Hub - Generic Hub - [接続する USB デバイス] のように、ハブが 2 段となり、外付け USB ハブを接続しているように表示されると思います。

    Intel® 5 Series Chipset and Intel® 3400 Series Chipset
    http://www.intel.com/Products/Notebook/Chipsets/HM57/HM57-technicaldocuments.htm

    参考になりましたら幸いです。

    2010年11月22日 13:02
  • >256ですよね?
    はい、255 ではなくて 256 です!
    (ちょろい間違えをしてしまって、申し訳ありませんでした。。。恥ずかしい。。。)


    >USB3.0の場合は、High SpeedとSuper Speedは通信に使用されている線が異なり、
    >外付けHUB[USB3.0]を経由しても、High SpeedはHigh Speedのままパソコンへ接続されると思われます。
    (実際に確認したわけではないので、間違っているかもしれませんが。。。)
    USB 3.0 対応の Hub デバイスを使用されているのであれば、
    Hub - Host Controller 間の通信は Super Speed で行われるのでは。。。。と思うのです。

    たとえば、

    [USB 2.0 Client Device] - <A> - [USB 3.0 Hub Device] - <B> - [USB 3.0 Host Controller]

    上記のような接続形態を考えた場合、<A> 間の通信は High Speed で行う必要がありますが、
    <B> 間の通信は同じ USB 3.0 なので Super Speed で行っても問題ないはずだと思うのです。
    メーカーさんが USB 2.0 で確認された「High Speed へ変換されいた」というのも、
    同じ原理だと思います。
    この <B> 間の通信はメーカーさんもご認識されているように、「Hub - Host Controller」間の
    話なので、基本的に Client Device 側のドライバが意識する必要はないはずです。

    ただ、今回のような(おそらく)Hub ドライバに起因する(と思われる)問題を Client Device 側の
    Driver で吸収しようとする場合(本末転倒ですけど。。。)は、<B> 間の転送速度を考慮する必要が
    あると思うのです。
    で、High Spped から Super Speed への変換なのだから、普通に考えれば、
    「<A> 間の転送サイズをもっと大きくすれば良いのでは?」
    と思ったのですが、
    「512 バイトから 256 バイトに変更したら発生頻度が下がった」
    とのことでしたので、
    「それじゃ、Clinet Device Driver 側の最大転送サイズ (MaximumTransferSize) 自体を小さくして、
      最後の URB パケットも必ず 256 バイト境界になるように調整すればいいのでは?」
    と考え、先の返信をさせていただきました。
    (あくまでも推測ですので、間違っていたらごめんなさいです。。。)

    あと、

    [USB 2.0 Client Device] -- [USB 3.0 Hub Device]

    の接続に使っているケーブルは USB 3.0 規格のものでしょうか?
    だとしたら、この間のケーブルを USB 2.0 規格のものに変更して確認してみるのも良いかも。。。
    (ケーブルの規格に違いよる影響の有無が確認できると思います。)

    参考になりましたら幸いです。

    2010年11月22日 5:14

すべての返信

  • メーカーさん、こんにちは。

    >> 高速に転送を行うため複数のURBが完了を待たずにMicrosoft Windos USBドライバースタックへ送られる

    記憶では、USB 3.0 対応の Windows 7 標準ドライバはまだなく、3rd Party 製のドライバが必要になると思われます。メーカーさんは、USB クライアントドライバを開発されていると思いますが、その配下の USB ハブドライバとホストコントローラードライバは USB3.0 PCI-Express/Express Card 用に別途インストールされたのではないでしょうか。その場合、USBD_STATUS_NOT_ACCESSED を返すのはそれらのドライバになりますのでドライバ開発元に確認された方が良いと思われます。

    認識が誤っておりましたらご容赦ください。

    2010年11月18日 15:38
  • Peiriさん、こんにちは。

    回答ありがとうございます。

    >USB ハブドライバとホストコントローラードライバは USB3.0 PCI-Express/Express Card 用に別途インストールされたのではないでしょうか。

    はいそうです。

    いずれもRenesas(NEC)のチップが使用されており、ドライバもRenesasから供給されているものです。

    >USBD_STATUS_NOT_ACCESSED を返すのはそれらのドライバになりますのでドライバ開発元に確認された方が良いと思われます。

    そうですよね。

    後出しになって申し訳ないのですが、

    ここに書き込む前にRenesasに問い合わせたところ

    「ボードメーカーじゃないとわからないので、ボードメーカーに聞いてくれ」という内容の回答しかいただけませんでした。

    そんなはずはないのですが。。。。

    最新のドライバーのバージョンすら教えてもらえませんでした。

    仕方なくだめもとでボードメーカーに聞いたのですが、

    「Renesasから供給されたドライバを使用しているだけなので詳細はわかりません」

    という回答でした。


    2010年11月19日 0:28
  • Renesasのドライバは1.0.17.0(ボード付属), 2.0.4.0(WEBで入手), 2.0.26.0(WEBで入手)を試したのですが、

    結果はいずれも変わりませんでした。

    ABORT_PIPEがきちんと処理されず、異常な状態になることがあるようです。

    ABORT_PIPEは下記のURLに従って行っているのですが。
    http://support.microsoft.com/kb/960958

     

    正常に動作している他社の製品を確認したところ、

    ABORT_PIPEが行われていませんでした。

    エンドポイント2をStallさせることで、

    ABORT_PIPEを回避しているようです。

     

    同様の対処で改善するかどうか試してみます。

     

     

     

     

    2010年11月19日 1:48
  • ご覧になられている記事 (Article ID: 960958) は、Windows 標準ドライバ (usbhub.sys, usbport.sys, usbehci.sys など) を使用することを前提として記載されているように見受けられます。Abort Pipe は、ソフトウェア上のお話しと思いますので、おそらくは pending transfer に対するハンドリングが 3rd party 製ドライバと標準ドライバで異なるのではないでしょうか。ちなみに下記サイトを見ますと、960958 で記載されている URB_FUNCTION_RESET_PIPE は、URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL、URB_FUNCTION_SYNC_RESET_PIPE、URB_FUNCTION_SYNC_CLEAR_STALL に代替されているようです。

    _URB_HEADER Structure
    http://msdn.microsoft.com/en-us/library/ff540409(VS.85).aspx

    参考になりましたら幸いです。

    2010年11月19日 5:46
  • peiriさん、こんばんは。

     

    回答ありがとうございます。

    いろいろ参考になります。

    他社製品を真似してABORT_PIPEを使わないようにしたところ、かなり改善しました。

    転送サイズを512KBのままにしても、199回は発生しませんでした。

    しかし、200回目で通信ができなくなりました。

     

    同じようにしてもだめだったので、

    他社の製品でもだめだろうと思い再度検証したところ、

    検証中にOSが落ちました。

     

    現時点でRenesasから提供されているドライバではどうしようもないような気がしてきました。

    暫定対策をして、ドライバが更新されるのを待った方がよいのかもしれません。

    下記のようなページを見つけました。頻繁にドライバおよびファームウェアが更新されているみたいです。

    http://www.station-drivers.com/page/nec.htm

    2010年11月19日 9:43
  • 横から失礼いたします。
    (相変わらず推測ばっかりですけど。。。)

    今回ご質問されている現象は、Renesas 社製 Hubドライバ側の実装に起因して発生しているような気がします。

    実際に確認した訳ではありませんが、USB 3.0 の場合でも 2.0 の場合と同様に、ダウンストームに Low-Spped /
    Full-Speed / High-Speed (つまり、USB 1.1/2.0)のデバイスが接続された場合の転送速度低下を軽減するために、
    Transaction Translator (TT) をサポートする必要があると思います。

    一般的に TT は、Hub 内でアップストリーム側の転送速度能力に応じたバッファリングを行って、そのバッファ データを
    改めてアップストリーム側の転送スピードで Host Controller に送信することでデータ転送を効率よく行う仕組み。。。
    と理解していますが、TT をサポートする場合、当然ドライバ側の対応も必要になると思います。
    Renesas 社さんでは、USB 3.0 ホスト コントローラ用のドライバと併せて、TT をサポートするために、
    USB 3.0 Hub ドライバも提供しているんだと思います。
    TT では、Host Controller 側にデータを転送する手前でバッファリングを行うわけですけど、Hub 側でバッファリングを
    行っている最中に、Hub デバイスあるいは Hub ドライバが想定しないタイミングで Abort や Stall が起こると
    それに対応できないため、USBD_STATUS_NOT_ACCESSED とかのエラーが返される。。。ということなんだと思います。
    (だから、URB にセットするデータ サイズに影響して、問題現象の発生頻度が変化しているんじゃないかと。)

    もしこの推測が当たっているのであれば、メーカーさんがご認識されているように、Renesas 社製のドライバに起因する
    問題なので、メーカーさんが開発されている USB クライアント デバイス用のファンクション ドライバ側での根本的な
    対応は難しいのかも知れないと思います。

    あと。。。
    メーカーさんが開発されてるドライバは WDK サンプルの BulkUsb あるいは UsbSamp を参考して作られたものでしょうか?
    もしそうであるのならば、MaximumTransferSize にセットする値を USBD_DEFAULT_MAXIMUM_TRANSFER_SIZE よりも小さな値
    (たとえば 4096 とかの 255 の倍数で小さな値)で、かつ上位アプリケーションからのリクエスト データ サイズを
    必ず 255 の倍数になるように調整すれば、さらに問題発生頻度を下げられるのかもしれないと思います。
    (もっとも、根本的な解決策にはなりませんが。。。)

    参考になりましたら幸いです。

    2010年11月20日 8:45
  • パーマン2号様、回答ありがとうございます。


    デバイスマネージャーを見ると

    (1) 「Renesas Electronics USB 3.0 Host Controller」

    (2) 「Renesas Electronics USB 3.0 Root Hub」

    が追加され、

    どちらにもnusb3hub.sysが使用されていました。

     

    TTに関しては、すみません、理解できませんでした。

    USB3.0に限らず、

    USBルートハブの役割が理解できていないです。

     

    USB2.0の場合は、

    外付けのHUB[USB2.0]を経由すると、

    Low,Full SpeedはHigh Speedへ変換されていました。

    USB3.0の場合は、

    High SpeedとSuper Speedは通信に使用されている線が異なり、

    外付けHUB[USB3.0]を経由しても、

    High SpeedはHigh Speedのまま

    パソコンへ接続されると思われます。

    「USBルートハブ」と「ホストコントローラー」間で

    変換が行われるのでしょうか?

     

    > メーカーさんが開発されてるドライバは WDK サンプルの BulkUsb あるいは UsbSamp を参考して作られたものでしょうか?

    私が作ったものではないのですが、

    4~5年くらい前に作成されたものなので、

    その頃のDDKのサンプルが元になっていると思われます。

    > もしそうであるのならば、MaximumTransferSize にセットする値を USBD_DEFAULT_MAXIMUM_TRANSFER_SIZE よりも小さな値
    >(たとえば 4096 とかの 255 の倍数で小さな値)で、かつ上位アプリケーションからのリクエスト データ サイズを
    >必ず 255 の倍数になるように調整すれば、さらに問題発生頻度を下げられるのかもしれないと思います。

    256ですよね?

    試してみます。

    かなり頻度が下がってきて検証が難しくなってきました。

    今までは手作業で行っていたのですが、

    検証用のアプリケーションを作成しようと思います。

    ありがとうございました。

    2010年11月22日 1:40
  • >256ですよね?
    はい、255 ではなくて 256 です!
    (ちょろい間違えをしてしまって、申し訳ありませんでした。。。恥ずかしい。。。)


    >USB3.0の場合は、High SpeedとSuper Speedは通信に使用されている線が異なり、
    >外付けHUB[USB3.0]を経由しても、High SpeedはHigh Speedのままパソコンへ接続されると思われます。
    (実際に確認したわけではないので、間違っているかもしれませんが。。。)
    USB 3.0 対応の Hub デバイスを使用されているのであれば、
    Hub - Host Controller 間の通信は Super Speed で行われるのでは。。。。と思うのです。

    たとえば、

    [USB 2.0 Client Device] - <A> - [USB 3.0 Hub Device] - <B> - [USB 3.0 Host Controller]

    上記のような接続形態を考えた場合、<A> 間の通信は High Speed で行う必要がありますが、
    <B> 間の通信は同じ USB 3.0 なので Super Speed で行っても問題ないはずだと思うのです。
    メーカーさんが USB 2.0 で確認された「High Speed へ変換されいた」というのも、
    同じ原理だと思います。
    この <B> 間の通信はメーカーさんもご認識されているように、「Hub - Host Controller」間の
    話なので、基本的に Client Device 側のドライバが意識する必要はないはずです。

    ただ、今回のような(おそらく)Hub ドライバに起因する(と思われる)問題を Client Device 側の
    Driver で吸収しようとする場合(本末転倒ですけど。。。)は、<B> 間の転送速度を考慮する必要が
    あると思うのです。
    で、High Spped から Super Speed への変換なのだから、普通に考えれば、
    「<A> 間の転送サイズをもっと大きくすれば良いのでは?」
    と思ったのですが、
    「512 バイトから 256 バイトに変更したら発生頻度が下がった」
    とのことでしたので、
    「それじゃ、Clinet Device Driver 側の最大転送サイズ (MaximumTransferSize) 自体を小さくして、
      最後の URB パケットも必ず 256 バイト境界になるように調整すればいいのでは?」
    と考え、先の返信をさせていただきました。
    (あくまでも推測ですので、間違っていたらごめんなさいです。。。)

    あと、

    [USB 2.0 Client Device] -- [USB 3.0 Hub Device]

    の接続に使っているケーブルは USB 3.0 規格のものでしょうか?
    だとしたら、この間のケーブルを USB 2.0 規格のものに変更して確認してみるのも良いかも。。。
    (ケーブルの規格に違いよる影響の有無が確認できると思います。)

    参考になりましたら幸いです。

    2010年11月22日 5:14
  • パーマン2号様、こんにちは。

    回答ありがとうございます。

     

    すみません、誤解を与えてしまったようです。

    今回はHUBは使用しておらず、

    パソコンおよびデバイス間はUSB2.0のケーブルで直結されています。

     

    > USB 3.0 対応の Hub デバイスを使用されているのであれば、
    > Hub - Host Controller 間の通信は Super Speed で行われるのでは。。。。と思うのです。

    USB3.0のハブは、

    USB2.0ハブとSuperSpeed専用のハブが単純に一体化されたものみたいなので、

    変換はされないような気がします。

    USB3.0の仕様書10-2に下記のように記述されていました。

    > A USB 3.0 hub is the logical combination of two hubs;

    >a USB 2.0 hub and a SuperSpeed hub.

    >Each hub operates independently on a separate data bus.

     

    > 「512 バイトから 256 バイトに変更したら発生頻度が下がった」

    512KB から256KB です。。。。

     

    チェック用のアプリケーションを作っている最中に対処法を思いつきました。

    結局のところ「キャンセル」がうまく処理されないようなので、

    「キャンセル」をなくせばよいのではないかと。

    「キャンセル」したい状況になったら、

    デバイス側にダミーのデータを送信させて、

    URBを完了させてしまえば、

    「キャンセル」せずに済みそうです。

    2010年11月22日 6:16
  • > 512KB から256KB です。。。。

    再三の間違い。。。ホントに申し訳ありません。。。

    > USB2.0ハブとSuperSpeed専用のハブが単純に一体化されたものみたいなので、
    > 変換はされないような気がします。

    私の説明不足で誤解があったようなので、補足させてください。
    メーカーさんがお使いになられている USB 3.0 Host Controller カード内には、
    USB 3.0 Root Hub デバイスも実装されていると思います。
    なので、先に返信させていただいた <B> 間の通信は、Host Controller カード内の
    話になるので、[USB 2.0 Client Device - PC] 間に USB アナライザを仕込んだとしても、
    その区間の通信は High Speed で行われ、USB 3.0 Host Controller カード内の
    [Root Hub - Host Controller] 間は Super Speed で行われているのでは?
    と言うことを言いたかったのです。
    (説明が足りず、申し訳ありませんでした。)


    >「キャンセル」したい状況になったら、デバイス側にダミーのデータを送信させて、
    > URBを完了させてしまえば、「キャンセル」せずに済みそうです。

    もし可能であれば、結果をご連絡いただけると、とっても嬉しいです!

    2010年11月22日 7:08
  • パーマン2号様、こんばんは。

    回答ありがとうございます。

    > その区間の通信は High Speed で行われ、USB 3.0 Host Controller カード内の
    > [Root Hub - Host Controller] 間は Super Speed で行われているのでは?
    > と言うことを言いたかったのです。

    すみません、やっぱり難しいです。

    「ホストコントローラー」や「ルートHUB」が何者なのかもよくわかってなく、

    パソコンの中に入った後の通信というのもいまいちピンとこなくて。。。

     

    最近購入したIntelのチップセットHM57が使用されたパソコンのデバイスマネージャーを表示したところ、

    ホストコントローラーはEHCIのみで、

    OHCIやUHCIが表示されませんでした。

    そのためか、

    デバイスマネージャーでは汎用HUBが内蔵されたように見えました。

    LowスピードやFullスピードの機器はそのままではルートHUBには接続できないから、

    汎用HUBが内蔵されているのかと推測していました。

     

    それと同じで、

    「Renesas社から提供されているドライバでは

    ルートHUBでSuperスピードに変換され、

    ホストコントローラーへ接続されているのではないか?」

    ということでしょうか?

     

    >もし可能であれば、結果をご連絡いただけると、とっても嬉しいです!

    まだテスト中(明日の休みの間動かしたままにしておく予定)ですが、

    解決したっぽいです。

    今までいろいろ試して最もよい条件でも最高240回目でNGだったのですが、

    今回は転送サイズも512KBのままですが、23000回を超えても不具合が発生していません。

    また、休み明けにご報告いたします。

    2010年11月22日 9:20
  • とりあえず解決したようで何よりです。


    > デバイスマネージャーでは汎用HUBが内蔵されたように見えました。
    これはおそらく、外付けの USB Hub デバイスを接続されていたためでは。。。と思います。
    あるいは、USB ポートに接続した USB デバイスの内部に、Hub デバイスが実装されていたのかも。
    いずれにしても、PC の USB ポートに Hub デバイスを接続すると、デバイス マネージャ上に
    「汎用 Hub」が表示されることになると思います。


    > LowスピードやFullスピードの機器はそのままではルートHUBには接続できないから、
    > 汎用HUBが内蔵されているのかと推測していました。
    ちょっと誤解されているのかも。。。(あるいは私の認識が間違えているのかも。。。)

    たとえば、USB 2.0 Host Controller に USB 1.1 Client Device を「汎用 Hub」経由で
    接続した場合、その Hub が USB 2.0 対応であるか否かで、デバイス マネージャ上での
    表示も以下のように変化すると思います。

    -------------------------------------------------
    [USB 2.0 対応 Hub を使用した場合]
    <EHCI> - <Root Hub> - <Generic Hub> - <USB 1.1 Clinet Device>

    [USB 1.1 対応 Hub を使用した場合]
    <UHCI/OHCI> - <Root Hub> - <Generic Hub> - <USB 1.1 Clinet Device>
    -------------------------------------------------

    上記の場合、

    <Generic Hub> - <USB 1.1 Clinet Device>

    の間は、Hub デバイスが USB 2.0 をサポートしているか否かにかかわらず、USB 1.1 の規格である
    Low/Full Speed での通信になるはずです。
    で、USB 2.0 対応 Hub の場合は、

    <EHCI> - <Root Hub> - <Generic Hub>

    の間の通信は High Speed で実現できるので、Host Controller は EHCI として動作するはず。
    一方、USB 2.0 未対応 Hub の場合、<Root Hub> - <Generic Hub> 間も Low/Full Speed でしか
    行えないので、結果として、Host Controller は Companion Controller である UHCI/OHCI になる。。。
    というのが私の理解です。

    参考になりましたら幸いです。

    2010年11月22日 11:07
  • メーカーさん、パーマン2号さん、こんにちは。

    UPD720200 のブロック図を見ますと、ホストコントローラー内部に USB2.0 用と USB3.0 用の Root hub をそれぞれ搭載しているようです。このため、USB2.0 対応デバイス接続時には、USB2.0 Root hub が使用されると思います。また、UPD720200 は、Intel XHCI 準拠ですので、今回の問題がハードウェアに起因している可能性があれば、下記 XHCI Spec も併せて確認された方がよいと思います (これまでの経緯からおそらくソフト側の原因とは思いますが)。

    UPD720200 Product Brief
    http://www2.renesas.com/usb/ja/product/upd720200_doc.html

    Extensible Host Controller Interface (xHCI) Specification for USB 3.0
    http://www.intel.com/technology/usb/xhcispec.htm

    ちなみに HM57 は、2 つの USB EHCI ホストコントローラーを搭載 (UHCI, OHCI は搭載されていません) しており、また、各ホストコントローラーに Rate Matching Hub が搭載されています。下記データシートの 5.19 の項を見ますと、こちらの Hub が Low, Full, High Speed の変換を行うようです。RMH サポートの USB ホストコントローラーの場合、デバイスマネージャー上 (表示タイプを接続順) では、EHCI - Root Hub - Generic Hub - [接続する USB デバイス] のように、ハブが 2 段となり、外付け USB ハブを接続しているように表示されると思います。

    Intel® 5 Series Chipset and Intel® 3400 Series Chipset
    http://www.intel.com/Products/Notebook/Chipsets/HM57/HM57-technicaldocuments.htm

    参考になりましたら幸いです。

    2010年11月22日 13:02
  • peiri さん、フォローありがとうございます。

    uPD720200 って、内部に USB 2.0 Root Hub も実装されてたんですね。
    USB 2.0 Client Device を接続しても、Device Manager 上には EHCI ではなく
    Renesas 社製 Host Controller Driver が表示されてたようでしたので、
    てっきり uPD720200 も HM57 のように Rate Matching Hub みたいな機能をサポートしていて、
    [Root Hub - Host Controller] 間は常に Super Speed での転送になっているんだと
    勝手に思い込んでおりました。。。
    (仕様書はちゃんと読まないとダメですね。。。。)

    メーカーさんには、ちゃんと uPD720200 の仕様も確認せずに適当なことを言ってしまい、
    大変申し訳ありませんでした。
    今後ともよろしくお願い申し上げます。

    2010年11月24日 4:44
  • パーマン2号様、peiri様、おはようございます。

     

    ご報告が遅れましたが、

    約30時間程度実行した結果、

    ExpressCardを使用したノートパソコンと、

    PCI-Expressボードを使用したデスクトップパソコン、

    いずれにおいても約90万回、正常に転送開始/停止が行われました。

    根本的な解決策ではありませんが、

    暫定対策としては十分なものになりました。

     

    >外付け USB ハブを接続しているように表示されると思います。

    読む人によってはデータシートからそこまで読み取れるんですね。

    読むための基礎知識が不足しており

    読んでもなかなか理解できないです。

     

    > [Root Hub - Host Controller] 間は常に Super Speed での転送になっているんだと
    > 勝手に思い込んでおりました。。。

    ボードを購入するまでは、

    Low,Full,High Speedに対しては従来のMSから供給されているドライバが使用されるのだと思っていました。

    デバイスマネージャーで確認したところ、

    そうではなさそうだったので、

    自社製品の動作チェックを行ったところ今回のような事態になりました。

    >メーカーさんには、ちゃんと uPD720200 の仕様も確認せずに適当なことを言ってしまい、
    >大変申し訳ありませんでした。

    いえいえ、おかげさまで理解が深まりました。

     

    いろいろ参考になる情報をありがとうございました。

    今後ともよろしくお願いいたします。

    2010年11月25日 0:17
  • 時間が経ってしまいましたが、問題が解決しているようですので回答済としてマークさせて頂きました。
    2012年7月7日 14:18
    モデレータ